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

Lemmy.World Announcements

29084 readers
291 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 2 years 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] 8 points 1 year ago (3 children)

Having sibling communities would be another approach.

Each one is still homed on their instance, but if the instances are federated the posts from the other instances automatically flow into the community. They would still show the originating instance, but content would be comingled.

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

Along those lines, what if communities could suggest other related communities, and clients could (by default, but optionally) also show posts that the communities your subscribe to recommend?

It's a little like soft federation, but on the client side - or, think of it like an automatic way to make multi subs while still allowing users to change it, and giving mods a less nuclear option if they don't like how a community on another instance is going.

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

Wow yes this sounds great, if a community or commune becomes big enough, multiple instances can share the load and carry content for said community, provided that the people running the instance and the people modding the community can come to an agreement, and for private communities, well we'll see further opportunity for access and more vetting procedures etc

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

The biggest problem with this approach is the potential headache for mods, and it might actually make things more confusing for the general public.

But OP's approach has a technical issue with a federated system: when two instances federate and each has a community of the same name, who gets to keep it? There's no central authority for such things--that's the point of decentralization.

So I guess it's just a complicated situation.