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.
I see this suggestion as problematic and recreating a problem reddit had. One group could lay claim to territory and everyone was stuck with however good or bad the culture was in the sub and however good or bad the mods were. There were some places with mods on a powertrip creating an exclusionary or outright toxic environment.
One group could lay claim to territory and everyone was stuck with however good or bad the culture was in the sub
This problem is easily surmountable with a new community name. Its not like it doesn’t happen anyway because for example c/trees isn’t about trees across multiple instances. Also i think ‘syncing’ a community could be optional decision between federated instances. If one instance grows to have values that disagree with your instance community you no longer sync that community and possibly defederate.
There are better solutions to the problem. For example, letting communities follow other communities. It’s simple and flexible.
Take a look at the discussion here https://github.com/LemmyNet/lemmy/issues/3071#issuecomment-1595303910 or my diagram of one proposed solution.
What if a post is acceptable by the rules/mods at instance b but the post breaks the rules at instance a?
Options:
- Instantly stop syncing? Seems dramatic
- Mods align rules? Utopia
- Mods keep rules misaligned and users seek out preferred instance? Most likely outcome but this would still create a weird multi-tonal vibe in ‘mixed’ communities at the user level experience unless instances can find a way to express themselves with a localised ‘style’.
Unless I’ve misunderstood something, community names are already globally unique and multiple identically named communities cannot exist, you’re just not looking at the full name.
Memes@lemmy.ml and Memes@sopuli.xyz are different names, for example.
Sometimes we ignore the part of the name after the @ if it’s unambiguous, but it’s still there.
tl;dr: I agree with OP that the ability to have multiple, identically named, disconnected communities on different instances will be a severe detriment to the adoption of the Fediverse by the general public.
community names are already globally unique and multiple identically named communities cannot exist, you’re just not looking at the full name.
That’s part of the problem. The simplest UI generally exposes the community name without the instance, !memes for example, but the backend is really !memes@lemmy.ml which is an entirely different community from !memes@sopuli.xyz. Now, that’s not really a problem - memes are memes. But what about a community for Edinburgh, UK? There are already two - !Edinburgh@sh.itjust.works and !Edinburgh@feddit.uk. That’s going to be an issue because if you choose one to participate in, you’ll miss all of the content in the other. If you’re a member of, say sopuli.xyz, you won’t even know that either exist because their community search doesn’t actually search all instances and might start a third. The whole idea of the Fediverse is to have a federation of instances which share information, and there is already talk of the biggest instances potentially creating a problem with the democratic ideals of the system (6 days into the reddit migration and three of the largest instances have defederated from one another). To have a thousand instances each with their own !Photography or !ManchesterUnited community dilutes the content and interaction.
I agree with OP ( I actually don’t know how to link to a profile yet or I’d tag @TerryMatthews) that there should be some cross-linked mechanism to merge identically named communities across instances. There could still be detached instances - defederated content would not have their content propagated - but the content for each unique community would be co-mingled.
I would expect that moderators would be limited in scope to their own communities. So a mod from feddit.uk could block a non-instance post or user on their instance but it would be present on other instances. They could also block a local post on their instance and it would not be propagated at all. Pinned posts get a little more hairy - would every mod have a separate set of local instance pins? I would think that would need to be the case. The issue of sidebars is also an issue.
The ability to create multis could solve that. I could make a local Edinburgh multi, sub to both of the communities, and view them together in one feed for example.
That would definitely fix the reading side of things. As would a reader/aggregator app which allows browsing (and discovery) of all the Fediverse instances as a unified feed. It still leaves the challenge of propagating information though communities without either leaving large swaths of the community in the dark or risking multiple posts (for people who do multi./aggregate). The last programming language I can claim to have studied is Fortran (77, no less), so my hope is only that someone competent shares my concern.
The “two Edinburghs” situation already existed on Reddit. You’d get slightly different “competing” subreddits. They’d have to differentiate their names a bit but it still happened.
To flip it round - there was an issue in Reddit that whoever first set up a subreddit with a given name then owned it forever. Let’s say I got there first for /r/london but then I’m a twat and either create a community of horrible people or fail to build a community at all. Everyone in London who wants a city subreddit is worse off, and at best someone has to come along and make a different subreddit with a different name to fulfill the same person. Not having this single namespace with “first mover” advantage is good and democratic. And all we have to do is pay attention to the bit after the @ sign.
That’s fair. Sometimes there are competing/unfriendly communities on the same topic (EliteDangerous and Elite_Dangerous sub mods hate each other with a fiery passion for…reasons). Since writing my post I’ve stumbled upon another poster suggesting a fix may be on the user side (a fediverse aggregating reader) rather than attempting to somehow weave communities together on the server end. That does mostly what’s needed (imho) without requiring any additional overhead on the instance ends.
I agree. I think people come here believing their vision of the fediverse has to be the vision and anything else is a bug, but that’s not necessarily right.
Imo that’s kind of the beauty. It’s whatever the people want it to be. You can curate your own experience on your end and the users sort themselves out. So as time goes, your experience naturally becomes what you want it to be. It’s confusing at first, but I think it’s actually a good practice in the long term, and even a good way to practice mindfulness in regards to your content consumption.
I’m one of those USENET greybeards and I think this would probably be a mistake. If you let a name be uniquely claimed by an instance, how do you decide which instance gets to be “in charge” of that?
Better IMO would be to update the various interfaces to be much more explicit about including the instance name along with the user/community name. So that it’s always clear that a user or community is at a particular instance.
We do still need better migration tools for moving users and communities around, though.
Reading this just gave me an interesting idea, when you start to post a link that’s already been posted in another linked instance, it will start to show you that it’s been posted elsewhere to different communities in other instances (on Lemmy, I don’t know about Kbin). This clearly shows there’s functionality there to look around when posting links, so I wonder if similar could be implemented when creating communities.
If the interface told you ahead of time that the community you were about to create has already been created in other instances, you wouldn’t be prevented from going ahead & creating your own version, but you’d be more readily aware. Honestly a win-win approach imo, considering it would help you find a community you may have been looking for but didn’t think existed, and it doesn’t keep you from trying to make your own anyway.
It’s not about allowing a single instance to own the name. The name would belong to the federation in a global namespace.
A possible scenario is to define multiple namespaces. Each namespace can be local to a single instance, or shared between many. Within each namespace, a single community name is unique.
In this model, each instance would have a namespace that it owns, and the ability to participate in many others.
The trick is in how we name the namespaces and communities. We could do this the USENET way and do something like <namespace>.<community>, so beehaw.gaming vs. global.gaming. There are other models that could work too.
I’m not sure how that would be different from what we’ve already got.
IMO the main feature kbin/Lemmy are missing is an equivalent to “multireddits.” That would allow multiple communities to be seamlessly aggregated for a user, they’d see all the content blended together as if they were one. I remember seeing a Codeberg issue over on the kbin repo discussing how to implement that, and I’m sure Lemmy’s devs are working on it too, so that feature will probably come along fairly soon. Then it shouldn’t matter much if the same subject has had multiple instances set up communities.
