For now. They’re still in their growth phase. If they ever become dominant and they need to make money, they’ll turn into a walled garden like every other. Everyone seems to forget that Twitter, Reddit and Facebook were also all about openness at the start
Lemmy and Mastodon as well for me. With a little bit of discord and matrix for my projects’ realtime chat
You can actually run it in async model without pictrs safety and just have it scan your newly uploaded images directly from storage. It just doesn’t prevent upload this way, just deletes them.
You don’t get public traffic redirected. It’s not how it works
It stops doing checks. Iirc you can configure it yes
https://github.com/db0/fedi-safety and the companion app https://github.com/db0/pictrs-safety which can be installed as part of your lemmy deployment in the docker-compose (or with a var in your ansible)
Not all web traffic, just the images to check. With any decent bandwidth, it shouldn’t be an issue for most. It also setup in such a way as to not cause a downtime if the checker goes down.
The software is setup in such a way that you can run it on your pc if you have a local gpu. It only needs like 2 gb vram
Upgraded. All went pretty smooth. Good job peeps!
Very nice
I suspect some misconfiguration on their pictrs.
[email protected] if you’re a tactics freak. It like fucking crack to me.
Well, the technical term people use for someone not left and not right, is “centrist” :D
I’m getting a 404
Ye I really don’t understand how the same post in mastodon is possible to appear in two different groups, but not in lemmy. I am not familiar enough with the internals.
I’m guessing lemmy is not capable of crossposting the same thing to two different communities in general, the same way it’s not possible via lemmy itself.
I’m not sure how it chooses which community to post to when there’s multiple. I would assume it would pick the first one? If it’s not, that, maybe it’s random?
[…]Looping through the list you’ve been given, and making extra queries adds complexity and delay, when the expectation from the user is that this list should appear pretty quickly.[…]
While you’re correct about this, this could be handled dynamically. Simply fetch the list of posts quickly as usual, and then start polling for crossposts in the background and if any two appear in the current frontpage the user is seeing, merge them.
My counter to that, would be that if you aren’t using the API in the way the developers expected, your app has ceased to be frontend, and is instead its own program that’s scraping data from it.
Not at all. That’s not what scraping means.
I just completely disagree with the idea that a frontend should stick to what the backend design is, especially for a FOSS project.
Frontends generate the main feed by querying api/v3/post/list. This doesn’t provide any crosspost info - for that you have to go into the post itself by querying api/v3/post. As such, frontends would have to do a fair bit of extra work to wrangle the required information for a main feed that combined crossposts.
Most frontends already display available crossposts so you’re not wasting anything more than grabbing all the comment sections as well.
I’d argue that you have a problem as soon as you start saying ‘frontends need to do some extra work’ - it breaks the dynamic between backends and frontends. Backends should be big, complicated things, worked on by people familiar with the project, to provide all the logic, whereas frontends should be light, relatively easy to write, runnable on devices with limited resources, and mostly focused on how the information provided to them should be displayed. They should store the user’s preferences, and login details, and that’s it - everything else should come from the backend.
I don’t agree at all. There’s space for complex frontends which attempt to adjust the feed according to their own logic, as well as minimalistic frontends which follow the backend’s design explicitly.
Tech journalists never learn anything from history. No Vc-funded social media is good