The mesh routes work to an identity, never an address, and selects among proven transports instead of implementing NAT traversal

202. The mesh routes work to an identity, never an address, and selects among proven transports instead of implementing NAT traversal

Kontext

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'.

Rozhodnutí

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.

Zamítnuté alternativy

• 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

Důsledky

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#4
• chatgpt-majordomus:c279#2
• chatgpt-majordomus:c279#4
• chatgpt-majordomus:c279#7
• chatgpt-majordomus:c279#10
• chatgpt-majordomus:c282#3
• chatgpt-majordomus:c282#5