Architecture decisions

Short records of the decisions that shaped this project, and the evidence behind them. Each is one page: context, decision, consequences, and what would change our mind.

Most of these rest on research that would otherwise be lost — measured throughput figures, NAT prevalence data, source-level findings in nwaku. Where a number appears, its source is named.

#DecisionStatus
001WireGuard for the data plane, not libp2p streamsaccepted
002Userspace WireGuard, not the kernel moduleaccepted
003Waku as rendezvous, not a live control planeaccepted
004The public logos.dev fleet, not our own clusteraccepted
005Overlay addresses derived from keys, no IPAMaccepted
006Rotating rendezvous topics on a stable shardaccepted
007Separate device and WireGuard keysaccepted
008A bearer network key for v1accepted, temporary
009Probe candidates before setting a WireGuard endpointaccepted
010Ship a container image, not a binaryaccepted
011No mixnet in the data pathaccepted
012Who runs the relay (you may not need a VPS)accepted
013Name resolution: hosts file now, DNS server nextaccepted
014Relay discovery: a flag on the announce, not a separate messageaccepted
015Multiple meshes in one daemonaccepted
016Android reuses the Go coreaccepted
017Invite tokensaccepted, built
018Credentials instead of a shared keyaccepted, mostly built
019An address per serviceproposed; the name router is built
020Membership is a seamaccepted
021A synthetic IPv4 address per peeraccepted; translator built
022A Keycard for the admin keyproposed; seam built, card blocked on a key-type decision
023Announcing servicesaccepted; built
024Ask the router for a way inaccepted; built and proven
025Control from a desktop appaccepted; settings built, admission deliberately not
026Announce what is bound to the mesh addressaccepted; built, off by default
027Punch through the relay we already haveproposed; every part exists except the coordination
028When the fleet turns on RLNproposed; nothing to build yet, two questions to ask