Planning for the future - a flaw in the design of Lemmy (and Kbin)
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.
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.
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.
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
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.