It feels like they’re two different roles. It might be better to have user-orientated servers that prioritise federation of content and only have a couple of meta-style communities, and other servers which prioritise being the go-to place for discussion on a particular topic and less a place that manages a large number of user accounts.
It just seems like two really distinct roles all servers are trying to do at the same time, and it’s leading to larger sites with a lot of users duplicating all the same subs, rather than there being any particular spot for certain types of discussion.
It also means the server hosting a particular type of discussion might defed certain instances to prevent trolling when it’s a sensitive topic, but it wouldn’t affect a large userbase who have that as their home server, it would only be moderating the discussion for the content areas they specialise in.
Thoughts?
This conversation is the exact opposite of that. This is “how can we better optimize federation”.
It kinda is though, maybe not so much “be like reddit” but it’s definitely “change how federation works”. Separating accounts and communities would make the concept of instance even less tangible and it’d change them from a place where you “live” to just a collection of communities with no real attachment to you.
If the design behind fediverse is a bunch of instances that self-govern and manage their own users but can communicate with other instances that they want to, then removing the “users belong to that instance” is a huge change at the very core of a fediverse. It has nothing to do with “optimization”.
Yes, it would be changing how federation works and I would actually oppose a change that says a “user instance” and “content instance” can’t be the same server. It’s a perfectly normal architecture though to have a management, worker, and database service use any combination of 1, 2, or 3 servers. This just seems like a decoupling from a monolith into microservices.
I agree with you.
The future is going to be different than one monolithic website and I think ultimately everyone just needs to relax for 6 months or a year and just get a feel for how all of this settles over time.
Part of the federated future is that we are going to lose content from time to time. Maybe someday someone solves that but this is what a link aggregation ecosystem with no central leadership looks like, and that’s ok.
yeah I wouldn’t be in favour of making that change to the software itself… I think the features are good the way they are. I’m just thinking in terms of organising services, and the best way to do it - it’s lots of servers run by volunteers and the structure is hazy so I think it’s good to have these conversations.
I’m new to lemmy so I might be wrong on this, but say if we have one big community for a certain hobby/interest and the moderators get power trippy or there are other problems, people into that hobby essentially have nowhere to go right? Having lots of smaller places and subscribing to them all makes it easier to cut one out and be less reliant on a specific group of people.
That’s true, but by separating communities and accounts you haven’t really solved this. It will be solved if/when we get proper migration tools to easily transfer accounts from one instance to another though.
Separating the two sounds like it would make the problem a lot worse. Nobody would have a reason to create smaller duplicate communities anymore so things would end up centralised and easier to abuse, like what happened with Reddit. You could hop your account to a new instance, but doing so means nothing if there’s only one instance of the community.
Oh yeah that’s true, I thought you’re implying that separating would make it more resistant to power trippy admins so it’d be worth it. I do like the smaller decentralized instances and feeling a sense of “community” when joining each (even though I’m kind of a hypocrite for saying that since kbin.social is relatively speaking pretty big for fediverse) but it does need more work until we get there properly, both in mindsets and in technical support.