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:

1. 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.
2. 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.