Building a distributed system is one thing. Making independent nodes find each other across the real internet is another.
In our previous post, ENTENCY — The Story So Far, we reached the point where ENTENCY UP and ENTENCY GNS had grown from an idea into working systems. Multiple GNS nodes could communicate, network state could be observed, and UP could interact with the infrastructure underneath it.
That was an important milestone. It was also where the comfortable part ended.
Localhost is not the Internet
Running multiple nodes on one machine is useful. Running them across a local network is better. But neither environment represents what a distributed network eventually has to survive.
The real internet introduces NAT, routers, changing addresses, firewalls, unreachable endpoints, temporary connections and machines that may disappear without warning. More importantly, a completely fresh node starts with a fundamental problem: how does it find the network in the first place?
During development we could provide a known bootstrap peer manually. That works for testing, but it is not the destination. A globally usable network cannot depend on every new installation already knowing the address of another running node.
So the problem changed from:
Can two GNS nodes communicate?
to:
Can a fresh GNS node discover a trustworthy path into the network without development shortcuts?
Building the path outward
Solving that required several layers rather than one feature.
GNS gained persistent Ed25519 transport identities and authenticated connection establishment, allowing nodes to prove possession of their transport identity instead of simply claiming one. Bootstrap seeds gained health tracking and retry behaviour. Endpoint management began collecting and classifying possible network paths instead of assuming that every discovered address was actually reachable.
NAT traversal became another part of that work. UPnP discovery and mapping were introduced together with mapping lifecycle management, renewal, expiry and cleanup. An externally observed address alone is not treated as proof that an endpoint can accept incoming connections.
That distinction became increasingly important:
knowing an address is not the same as proving reachability.
The same principle was applied to bootstrap knowledge. Information learned from another node has provenance, freshness and boundedness. Malformed or conflicting information cannot simply become trusted network state because a peer supplied it.
Piece by piece, the network began learning not only what it knows, but also why it believes it.
Then we tested a fresh node
Eventually we needed a test that ignored the development environment and asked a much simpler question.
Start fresh.
What does this node actually know?
The bootstrap acceptance validator was built to answer exactly that. Instead of assuming that bootstrap discovery works because individual components pass their tests, it evaluates the evidence available to a fresh node.
And the baseline result was:
NO_BOOTSTRAP_KNOWLEDGE
That result is useful precisely because it is not hidden behind a green status indicator.
The node can start. The networking components exist. Authentication works. Bootstrap knowledge can be propagated and persisted. Diagnostics can inspect the state.
But in the local baseline, the fresh node still has no independent external bootstrap knowledge from which it can discover the wider network.
That is the gap between a functioning distributed architecture and a network that can bootstrap itself in the real world.
This is where we are now
The next stage of ENTENCY GNS development is about closing that gap.
A fresh installation should eventually be able to start with no manually configured development peer, discover valid bootstrap information, authenticate the nodes it reaches, learn additional network knowledge through the canonical GNS pipeline and build usable paths into the network.
And all of that needs to happen without turning discovery into an implicit trust mechanism.
Discovery tells a node where it may try to connect.
Authentication and verification determine what it should trust.
Keeping those responsibilities separate is becoming one of the important architectural principles of the GNS networking layer.
The next steps will move bootstrap discovery beyond the current local environment and toward externally available, independently reachable network entry points. Those steps will be tested the same way the previous ones were: with diagnostics, evidence and explicit acceptance criteria.
Because the goal is not to make the status screen say connected.
The goal is to know why it is connected.
The next test
The next milestone is easy to describe:
Start a fresh ENTENCY GNS node on a machine that knows nothing about the network — and let it find its way in.
No manually configured peer.
No development shortcut.
No localhost assumption.
Just a fresh node and the network.
Whether the first attempt passes or fails, we'll document what happens next.
Built in Public. Documented as we build.
Top comments (0)