Comment on Why are peole hating on .world?
OpenStars@discuss.online 2 months agoPeople are doing that here though - e.g. the user Blaze made accounts on basically every instance, and subscribed to every community. This gets around the limitation where at least one user of an instance must subscribe to a community before it will even so much as show up for others to also subscribe. Really the developers should have made better automation so that this was not necessary, but… anyway it works, for now:-).
can@sh.itjust.works 2 months ago
OpenStars@discuss.online 2 months ago
That’s nice! ☺️
lvxferre@mander.xyz 2 months ago
I feel like ActivityPub implemented federation in a really weird way, and that’s what causes problems like @linearchaos@lemmy.world is reporting, or the issue that Blaze is addressing through multi-accounting. Perhaps we shouldn’t be sharing content across instances but only credentials.
For example. If you’re registered to instance A, and B federates with A, then B would let you post from your A account as if you were registered to B. Then let the retrieval of the content of different instances up to the front-end, instead of mirroring it.
OpenStars@discuss.online 2 months ago
No, the whole point for the federation is to share the content. For one, it allows redundancy so that if a rogue mod or admin decided to delete a bunch of stuff, then every other instance still retains copies of what came from it.
But that said, having to keep everything up to the second, in batches of a single action, is extremely limiting. If I downvote someone with an accidental button press, then undownvote them, then upvote - that could have been just one net interaction to send, but instead it is three.
lvxferre@mander.xyz 2 months ago
Redundancy is better handled through specialised mirrors, similar in spirit to reveddit. That would be even more transparent than the current system - as the mirrors could translate actions like content removal into content highlighting, so you’d see what was removed within the original context. This would also throw the burden associated with redundancy (transmission, storage, removal of clearly illegal content) into a few machines, instead of the whole network.
I’m aware that it’s a weaker form of federation than the current one but, as long as the front-end handles simultaneous multi-account and merges the feeds of the instances that you’re registered to, it’s already addressing the main needs:
- users can see content from multiple places without registering individually to each
- users don’t need to see what they don’t want to
- content is still spread out, so no instance controls the whole
- admins still have control over who accesses their own instance (through defederation + banning).
OpenStars@discuss.online 2 months ago
At a wild guess, it could literally be the communism?
No really, I’m serious: what you are describing sounds to me like there is a sense of “ownership”, as in an instance owns a community, whereupon everything else is lesser than the owner with respect to that particular content - e.g. the others “mirror” the content that is “owned” by the instance that the community is on. A master/slave relationship, in computer science terminology.
In contrast, ActivityPub sounds to me (caveat: I’ve never read the source) like everyone is equal, hence why every action is shared equally by all. A distributed burden. Except without the major traditional benefits of it being distributed - i.e. Aussie.Zone cannot simply connect to some other server instance with less physical distance between it and Lemmy.World, no it must go straight to the source, even when that results in a 7-day delay (and even that cutoff is only because things older than that simply get deleted).
On the other hand, there’s nothing stopping someone from not respecting the deletion requests, and instead highlighting that content, in the current Lemmy framework. It would definitely be a deviation from the standard codebase though. And therefore every time there’s an update or patch, there would have to be a merge event to keep that feature functional.
I wonder if the reason your idea is not done is bc it relies too much on “trusting” the client for security reasons? Although… tbf I’m not certain how much that would differ from how things are now.
Blaze@sopuli.xyz 2 months ago
Ease discovery of federated communities has been funded: join-lemmy.org/…/2024-09-11_-_New_NLnet_funding_f…
lvxferre@mander.xyz 2 months ago
Ease discovery of federated communities has been funded: join-lemmy.org/…/2024-09-11_-_New_NLnet_funding_f…
That’s some great news! It’s great to see that the issues are being ironed out.
Dark_Arc@social.packetloss.gg 2 months ago
That’s actually really terrible for federation performance, particularly because lemmy doesn’t do batch synchronization. So basically every comment, post, like, and community is being sent to all Lemmy servers as individual sequential requests. That’s a lot to handle.
OpenStars@discuss.online 2 months ago
Supposedly that will change with v0.19.6 (A recent discussion about that here: feddit.org/post/3524876), but yeah it’s causing smaller instances such as Aussie.Zone to have delays of over 7 days.
I also expressed disbelief that this info would not be bundled somehow - at least put together a package for everything that happened across the entire instance in one second, or one minute could be far better, for servers that can’t handle the per-second traffic?
Dark_Arc@social.packetloss.gg 2 months ago
Well that’s good!
And right, I had the exact same thought… It seems like the lemmy devs are not highly experienced web developers, at least not that have worked on anything at the scale lemmy became after the Reddit exodus.
OpenStars@discuss.online 2 months ago
I thought at first that everything was simply slow to develop bc of using the Rust programming language.
Now I hold great excitement for the upcoming projects like Sublinks, Piefed, Mbin, and Tesseract (that one is more a front-end UI for whatever backend protocol). But Lemmy still has all the effort put into it in the past so it is ahead for that reason at least.