202. The mesh routes work to an identity, never an address, and selects among proven transports instead of implementing NAT traversal
Context
Between 10-12 and 10-18 the owner asked four times to make discovery work across NAT, with 'fast-flux', mothership, hole punching, STUN/TURN and WebRTC ideas. Master has multicast and directly-reachable rendezvous hubs and states 'no NAT traversal'.
Decision
A peer is a stable cryptographic identity; endpoint candidates are expiring observations with source and confidence; DNS is a discovery projection, never identity. The logical network (identity, capability, intent) is separate from the physical (address, NAT, relay). Majordomus owns the contracts and the choice: it integrates proven transports and relays, chooses by measured success among authenticated candidates with hysteresis, starts relay-first and upgrades to direct, and never re-implements ICE. Rendezvous, relay and gateway are roles a trusted peer holds, not fixed servers. The phrase 'fast flux' names nothing in code or docs. DHT, coordinator election and custom consensus wait for a measured need.
Alternatives rejected
- Literal DNS fast-flux or double-flux
- A custom NAT traversal stack or own ICE
- Address-based task dispatch
- A fixed mothership server
- DHT first
Consequences
mesh-connectivity (I3187..I3190); deferred past v1.0.0-alpha.1 by Operation Convergence.
Sources
Promoted on 2026-10-18 from the owner's ChatGPT project (workspace chatgpt-majordomus, issue I3100). The owner has not accepted it; it is proposed for the owner's decision.
chatgpt-majordomus:c237#4chatgpt-majordomus:c279#2chatgpt-majordomus:c279#4chatgpt-majordomus:c279#7chatgpt-majordomus:c279#10chatgpt-majordomus:c282#3chatgpt-majordomus:c282#5