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.
A big piece of this is that it’s really a messaging platform first, which makes sense. It makes me wonder if a protocol that wasn’t the web, but that handled the way content was distributed differently (but would likely require more centralization) would work better specifically as a Twitter replacement?
@adamhjk I’m curious about the assumptions you are making that seem unstated but lead you to this conclusion. Forgoing the notion that centralization may/may not be desirable, are there others you can point out?
@IPmonger sure. I don’t care so much about decentralized or not. But I’ve done a lot of reading about distributed gossip systems, and the delivery part of this feels like it would be much better designed as one (even if it used http for transport). The cost per interaction will go up as the network grows, unless we condense to super nodes.
@adamhjk @IPmonger Can you share a link or info to the distributed gossip systems you think would be useful? Sounds interesting
@giuliano_b @adamhjk if you just want info about a gossip implementation in general, this is a good paper
https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/SWIM.pdf