Network patterns

How P2P apps connect — the shapes we reuse everywhere.

1. Derived, versioned topics

Rendezvous points are hashes anyone can derive:
hash('myapp:board:v1:' + name)
(discovery chapter). Version them; a protocol
break moves to :v2: instead of confusing old peers. Secret names give
unlisted rooms for free (Baby Rooms 1).

2. Gossip pointers, replicate content

Never gossip content — gossip keys (author pubkeys, drive keys) and let
verified replication move the bytes. Fake pointers are harmless (their
content self-verifies or fails); fake content is impossible if it is never
accepted outside signed logs. p2pbuilders' announce channel spreads author
keys transitively: one connection bootstraps the whole board's roster.

3. Validate on ingest — the admit hook

Every byte crossing from network to state passes one gate that checks
everything: signature over canonical encoding, signer == claimed author,
storage-key/field consistency, app policy (PoW, size caps). The engine keeps
one seam (validate) so policy stays app-side
(how the web port kept its engine generic). Scattered
"we check later" is how
transport-authority bugs happen.

4. Enforce at the index, not the transport

Replication stays promiscuous and cheap; indexing is where policy bites
(refuse un-worked ops, rate-limit keys, apply blocklists). Peers disagreeing
about policy still interoperate — each just shows a different view
(why).

5. Relay pinning as a cache tier

Always-on dumb storage keeps data alive through author downtime
(HiveRelay): seed yourself and everyone you track,
verify durability with proof not acceptances, pin the full object graph
(blobs incident) — and keep the app fully functional
with zero relays reachable.

6. Design for churn

Peers vanish mid-anything. Every handler must survive a socket dying between
two lines; every sync must be resumable from any length. The test: kill
either peer at a random moment, restart, converge. If that test scares you,
the design is not done.