@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 (https://www.jwz.org/blog/2022/11/mastodon-stampede/ and several others)
it has real implications, over the longer term, for how people group together on instances (or don't)
@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
@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' (https://www.w3.org/TR/activitypub/#shared-inbox-delivery) 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 (https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/) 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.
This is a lovingly run mastodon server. High performance, high love, low bro, no hate, no ads, $0/mo.