tl;dr: to reduce federation api calls and to reduce issues with defederation, maybe some instances should only be for communities with no user signups, and some instances should be only for user signups with no communities (you would have to make a post or PM to request the admin to make a community for you)
cross-posted from: https://fanaticus.social/post/265339
DRAFT Work in Progress - Updates will be noted in the comments.
I find I have been a bit repetitive in different threads talking about Lemmy / Kbin (collectively, the Threadiverse), so I thought I would put my thoughts together in one place where I can cover it in detail, and revise my thoughts as they evolve. So, here it is…
The Problems
Why can’t we merge / sync all the communities with the same name?
This illustrates a fundamental misunderstanding of how Lemmy and ActivityPub work. It implies that local communities are somehow better than federated communities, and that synchronizing different communities would somehow be better / more efficient than just subscribing to the federated community. That’s just plain wrong.
Once a community is federated, accessing and interacting with the community is exactly the same as for a local community. The content is exactly the same, and changes are automatically shared among subscribing servers.
The real problem is every instance wanting to be the instance for Reddit knock-off communities. I won’t deny that there are significant financial and ego reasons why admins want to accomplish this end. However, this is not the best approach for Lemmy.
The admins of my instance are doing bad things!
Folks, admins need to admin. Each instance is going to have its own policies driven by their personal values and by the legalities of where the server is hosted.
I want to host an instance, but the storage & network requirements are too high
This is a genuine concern - there are two things fundamental to Lemmy that cause this:
- Each instance needs to keep a complete copy of every community that any user on the instance subscribes to. The storage overhead per user is especially high on instances with not a lot of users.
- Each community has to share its changes with every instance that has subscribed to it. So when a user on instance A makes a post to a community on instance B, A sends that info to B, then B must send a copy of that post to every other instance with subscribers.
The Solution
Communities
Communities should be spread out across multiple instances, with a small number of like-minded communities on each instance. An example of something like this this would be Discord servers with multiple channels.
- Users on community focused instances should be limited to admins and mods. These should not be primary browsing accounts.
- Community instances can be much more restrictive with their login & firewall policies, making these more secure. Improved remote moderation could limit logins to admins, so the UI itself could be firewalled.
- Businesses, News Media, Celebrities, etc., should host their own community instances so that they can protect their brand and not be subject to third party content policies. Further, instances which are not compatible with the brand’s image can be defederated without disrupting the brand’s online presence.
Users
Users should congregate on user focused instances.
- Local communities on user instances should be limited to meta topics and possibly a few broad general interest communities.
- User instances can serve as a cache for the distributed network of communities, limiting the duplication of content.
- User instances can be hardened for user facing security
How does this address the problems
Storage & Network Requirements
Having users concentrate on user instances reduces the storage overhead per user, because if multiple users on an instance subscribe to the same communities, there is still only one copy of the community for the instance.
On the network side of things, this reduces the amount of redistribution required by the community instance, because there would be fewer user instances to host subscribers.
In summary, the approach of split user & community instances is really optimal for ActivityPub, because user instances effectively become cacheing servers for communities. This greatly reduces the cost to host community instances.
randomly found this post, curious what other people think about this approach
this is exactly what I do with https://lemmy.mods4ever.com/
only my admin user is on there and it isn’t subscribed to any remote communities, Lemmy is barely using any resources on my server it’s basically free
I’ve actually thought about running 2 separate instances like lemmyusers.mods4ever.com and lemmycommunities.mods4ever.com or something like that
originally posted by @[email protected] aka @[email protected] aka @[email protected] (according to their profile)
That’s not a great idea. I understand where OP is coming from, but this could make the admins of the user account servers very powerful , as they would be in control of who would get access to what.
How would they be more powerful than in the current situation?
I’m not sure what you mean, don’t they already have that power?
No, because I can now create an account at - as a fictitious example - Lemmypoop, and see their content and everyone else’s, something that could be prevented when I only can create an account on poop-disliking Lemmy.clean. At the very best, it would end up in a huge amount of little bubble islands, where accounts and content are bound together.
Why am making such a gross example btw
so basically you’re saying that it might be difficult to find an instance for your account that federates with the community you want instead of just signup up on the same instance as the community you want? that does make sense
although you could look at the posts on the front page of the instances community and see what instances those users are from, or the instance sidebar could have some suggested instances for creating an account
but yea it could be a little awkward