Adam JacobActivityPub spec is a marvelous bit of tech writing. It’s also a pretty amazing example of HTTP’s enduring resilience as a protocol - tons of relatively simple things exposed as objects, with a well written spec for each. I’m glad I read it, because it really reframed what we’re actually doing here (basically posting json to our webserver, and getting copies of each others shit dropped off to shared inboxes across our federated server list). It’s an elegant design.
All that said, it’s going to dramatically fall down if it gets anywhere close to twitters scale - unless it recentralizes very quickly. Basically a small number of super-servers will have to appear, because the infrastructure to run the protocol will require it. Huge amounts of storage, duplication everywhere, it’s going to get crazy quickly. I don’t think that’s unique to activitypub, tho.
Giuliano Barberi 
@adamhjk why is storage an issue? Each server should in theory need to store "only" the posts from external people/hashtags that are followed by someone on that instance. There's definitely a lot of duplication but that also works as a form of read replicas. Now it would certainly be an interesting thesis for someone to figure out some numbers. I don't understand the bandwidth though bc it seems instances send all posts as long as one person from that instance is followed?
@giuliano_b the bandwidth is because it’s going to parallelize the push - you publish, and it takes every server in the follow list, dedups it, and sends it along. If there is other content (media) attached, then it’ll also trigger fetches for that, I expect. Hachyderm is over 25k accounts - it could become cumbersome quickly.
@adamhjk Does hachyderm send all posts to all instances that there is at least 1 follower or is it smart enough to only send to the instances of the poster's followers (if that makes sense)? I think it's the former because of how I've read the federated timeline works but that seems to be much less efficient than the latter