@Ciantic @andrew it sounds like that's how it works - the server hosting George Takei has to do all of that fanout work every time someone replies to him

Follow

@simon that's exactly how it works (unless the target inboxes are all on the same instance, then it's an instance-dependent detail how they are delivered or how the work is batched)

cf. all the commentary from jwz about exactly this kind of communication (jwz.org/blog/2022/11/mastodon- and several others)

it has real implications, over the longer term, for how people group together on instances (or don't)

· · Web · 3 · 0 · 3

@simon in the meantime it'd be really helpful if, instead of reporting total number of (new) users, the big instances gave out some information on (say) the number of cross-instance follow relationships their users have, or what their outbound and inbound request traffic looks like

@simon @arthegall it sounds like a similar problem to email mailing lists distribution

@sxpert exactly -- a problem that email, notably, never solved

@arthegall @simon so if there are like 7,000 Mastodon instances or whatever then Takai's server will have to make at most 7,000 requests each time he posts?

@rick @simon yeah, but also if you have 7000 followers and they're all on a single instance that's different from yours. The spec doesn't mandate, or provide any support for -- batching requests between instances.

It flows from the "LD" part of "JSON-LD" that a lot of the core data models are based on.

@rick there's additionally a notion of 'shared inbox' (w3.org/TR/activitypub/#shared-) but it's for more broadcast-like messages. And it wouldn't resolve the problem jwz highlighted, which is essentially the messaging _back to your instance_ that results from follows, likes, retoots, etc.

@rick None of this is rocket-science .. it's all pretty standard stuff. In chapter 1 of Martin Kleppman's book (oreilly.com/library/view/desig) he describes (under 'Describing Load') an "Approach 1" and "Approach 2" for scaling a Twitter-like service.

Activitypub is a straight-down the middle implementation of "Approach 2"

But in the very next sentence (!) he talks about problems with "Approach 2" that come from highly-skewed follower lists, and he points to a straightforward solution.

Sign in to participate in the conversation
mastodon.roundpond.net

This is a lovingly run mastodon server. High performance, high love, low bro, no hate, no ads, $0/mo.