I’ve been working for several weeks on a design for Groups in #ActivityPub
, and the more I work on it, the more impressed I am with the way they solved essentially the same problem in #Matrix
The problem with groups
The problem of groups centers around message delivery. Whenever you send a post/reply/like, that message needs to get sent to all members of the group. If members send that message to the group’s server, you run into a problem of scale:
A group with 50,000 members who send one message per day will require the server to deliver 2.5 billion
messages per day. The “centralized delivery” model is O(n^2). It has the advantage of simplicity, but simply isn’t sustainable.
Your options at this point are to either (a) centralize as many accounts as possible onto a single server (lots of optimizations, but ultimately bad for a federated system), or (b) break up message delivery so that as much delivery as possible is handled by each users’ server. This leaves each server with O(n) messages to deliver, a solution that scales indefinitely.
Of course Matrix went with option (b). It adds complexity, since each user’s server needs to host some (but not all) of the messages of the entire group, but it’s also the only solution that can actually scale. It’s the same solution used by other venerable federated systems like email, DNS, and the web.
If you want to scale, you need to federate.