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
@relistan @giuliano_b the swim paper is a classic. Here is the docs for habitats gossip model, which has links to the newscast and swim papers: https://docs.chef.io/habitat/sup_design/ - it’s a good example of how customized things get, compared to the academic research
Supervisor Design

This section will dive into the implementation details of important Chef Habitat components. These topics are for advanced users. It is not necessary to learn these concepts in order to use Chef Habitat.

@adamhjk @giuliano_b yeah indeed. I built https://github.com/NinesStack/sidecar gossip-based service discovery on top of customized SWIM for better propagation. Have run it since 2015 in prod, longest at Community.com for the last four. Originally used vanilla memberlist but needed more rapid propagation.
GitHub - NinesStack/sidecar: Gossip-based service discovery. Docker native, but supports non-container discovery, too.

Gossip-based service discovery. Docker native, but supports non-container discovery, too. - GitHub - NinesStack/sidecar: Gossip-based service discovery. Docker native, but supports non-container di...

GitHub