this post was submitted on 17 Jun 2023
151 points (83.0% liked)

Lemmy.World Announcements

28914 readers
1 users here now

This Community is intended for posts about the Lemmy.world server by the admins.

Follow us for server news ๐Ÿ˜

Outages ๐Ÿ”ฅ

https://status.lemmy.world

For support with issues at Lemmy.world, go to the Lemmy.world Support community.

Support e-mail

Any support requests are best sent to [email protected] e-mail.

Report contact

Donations ๐Ÿ’—

If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.

If you can, please use / switch to Ko-Fi, it has the lowest fees for us

Ko-Fi (Donate)

Bunq (Donate)

Open Collective backers and sponsors

Patreon

Join the team

founded 1 year ago
MODERATORS
 

Hey all, so I've been trying to embrace the fediverse life. My background - I've been on the internet since pre-WWW, so I've seen it all.

I think there's a structural issue in the design of Lemmy, that's still correctable now but won't be if it gets much bigger. In short, I think we're federating the wrong data.

For those of you who used USENET back in the early days, when your ISP maintained a local copy of it, I think you'll pick up where I'm going with this fairly quickly. But I know there aren't a ton of us graybeards so I'll try to explain in detail.

As it's currently implemented, the Fediverse allows for multiple identically named communities to exist. I believe this is a mistake. The fediverse should have one uniquely named community instance, and part of the atomic data exchanged through the federation should include the instance that "owns" the community and a list of moderators. Each member server of the Fediverse should maintain an identical list of communities, based on server federation. Just like USENET of yore.

This could also be the gateway into instance transference. If the instances are more in-sync, it will be easier to transfer either a user account or a community.

This would eliminate the largest pain point/learning curve that Lemmy has vs Reddit.

Open to thought. And I'll admit this isn't fully fleshed out, it was just something I was thinking about as I was driving home from work tonight

Lemmy is good, but it could be great.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 3 points 1 year ago (1 children)

This could also be the gateway into instance transference. If the instances are more in-sync, it will be easier to transfer either a user account or a community.

Indeed, does it not make sense in a fediverse where you can forward or change your account to another instance a community, be it called magazine or lemmy can change instance as well.

It would also be a protection.
Already now we are seeing some instances of lemmy's / magazines growing larger than others e.g. selfhosted on lemmy.world vs lemmy.ml

Image in a year time if the largest of the communities would suddenly drop out (database corruption, server takedown, admin issue) again all the knowledge / posts are again lost and difficult to recover.

Or does it already work that way and I'm still not really grasping this hole fediverse thing?

[โ€“] [email protected] 4 points 1 year ago (1 children)

My understanding is that if an instance suddenly dies, all the federated instances that subscribe to its communities will still have the text content because they store copies locally. So knowledge should not just go away. Media is a different story though.

I think new posts/comments in those communities would then not federate at all anymore since the host instance would not acknowledge them. So the communities turn into isolated local ones.

If the host instance comes back and the communities are re-created, theyโ€™ll be empty on the host instance but I think other instances wonโ€™t delete the old content unless explicitly requested.

[โ€“] [email protected] 1 points 1 year ago

How is this scalable and sustainable? If every instance caches every other instance then it'll blow disk usage out of the water.