ActivityPub 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.
@adamhjk Although obviously the decentralized-and-replicating approach isn't efficient (when compared to a centralized approach)... wouldn't that just bring us back to the USENET days ? That wasn't so bad, was it ? Or am I being overly romantic about the past ?
@johanvc @adamhjk it wasn't so bad, until you wanted to host the alt.binary hierarchies. Those required a lot of space, even when expiring the posts quickly, 3-5 days, the amount of disk space needed was huge, by the standards of the time.
@webhat @adamhjk yup, but at least with Mastodon I don't think we'll have that specific issue (abusing the message system as a binary distribution platform) ? And even more intensive ActivityPub apps like PeerTube seem to keep the blob storage distributed (I think, not sure) ?