DEV Community: Entency

A Fresh Node Finds Its First Peers — Inside a Controlled Lab

Entency — Thu, 01 Oct 2026 22:00:00 +0000

A fresh node found its first peers in a controlled bootstrap lab. The result came with clear limits.

In The Hard Part Begins, we described a gap that a working network stack could not solve on its own: a fresh node still needed somewhere to begin. The local baseline reported NO_BOOTSTRAP_KNOWLEDGE, even though connection handling, authentication and diagnostics already existed.

The next documented step was a controlled bootstrap experiment. The result recorded on September 21, 2026 was PASS_WITH_LIMITATIONS.

Giving the node a starting point

For this experiment, the node received a lab-scoped bootstrap descriptor: a bounded description of where an initial peer could be found, together with identity constraints. That supplied the first-contact knowledge missing from the empty baseline.

This was an explicit laboratory input. The experiment did not show that a publicly distributed installation could already discover production infrastructure without configuration.

The descriptor also did not create a trusted connection by itself. Candidates still had to pass through the existing connection pipeline and identity-bearing hello. Discovery supplied a place to try; the connection checks determined whether entry was accepted.

What the lab recorded

The acceptance summary reported six observations, two authenticated entries and two independent sources. It also recorded two learned peers and one learned provider.

That moved the experiment beyond simply reading a descriptor. The fresh node acquired additional network knowledge, and the controlled run observed source failure and recovery with alternative sources available. A descriptor for the wrong chain was rejected.

The useful result was a sequence: initial knowledge, accepted entry, additional knowledge and controlled recovery.

The acceptance validator evaluated the captured observations offline. It did not create connectivity or perform the network experiment itself. The dated result document records the physical local/LAN run; it is the evidence for the outcome described here.

Why the limitations remain

The lab used controlled infrastructure and lab descriptors. Production bootstrap infrastructure was still pending, and the result retained limitations around production-grade cache and restart evidence.

Learned knowledge also has to remain separate from current trust. A remembered peer can become a candidate after restart, but persistence must not silently turn it into an authenticated or connected peer. That boundary matters when addresses become stale or machines disappear.

The integrated Internet zero-configuration acceptance level was explicitly outside this result. Reaching it requires evidence from independent network conditions, not just a successful controlled setup.

The next boundary

This experiment gave us a concrete answer to the first laboratory question: with valid starting knowledge, could a fresh node enter, learn and recover through the intended machinery? The recorded result supports that bounded claim.

The next question concerned the path itself. A node might know where to connect while still being unable to reach that address from another network. That became the focus of the Internet-edge test.

Built in Public. Documented as we build.

The Hard Part Begins: Taking ENTENCY GNS Beyond Localhost

Entency — Tue, 29 Sep 2026 13:41:28 +0000

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.

ENTENCY — The Story So Far

Entency — Tue, 29 Sep 2026 13:04:25 +0000

From an idea to a working distributed technology stack.

In the first Built in Blog post, we introduced what this journal is about: documenting ENTENCY as it is being built. But that leaves an obvious question: What has actually been built so far?

ENTENCY did not begin with a finished architecture, a polished product, or a predefined list of features. It grew from a much simpler idea:

What would computing look like if applications, communication, storage and execution did not have to revolve around traditional centralized infrastructure?

That question eventually became two connected systems: ENTENCY UP — the user-facing environment — and ENTENCY GNS — the distributed infrastructure underneath it.

And getting from the original idea to where the project stands today has involved a lot more than drawing an architecture diagram.

Building the user layer: ENTENCY UP

The first visible part of the system became ENTENCY UP — the Unified Protocol Browser and Workstation Runtime. UP is designed as more than a traditional browser.

The Browser provides the navigation layer, while the Workstation provides a managed execution environment where applications can interact with capabilities such as identity, communication, storage, streaming and other system services. The goal is to provide one environment where traditional web content and ENTENCY-native applications can coexist.

Over time, this moved from concept to a functioning desktop environment with application spaces, runtime services, permission handling and integration with the network underneath it.

But a user interface alone was never the goal. For UP to operate as part of a distributed system, it needed infrastructure behind it. That became ENTENCY GNS.

Building the network underneath: ENTENCY GNS

ENTENCY GNS — the Global Neural System — became the distributed foundation of the project. Its role is to allow participating nodes to discover each other, communicate and coordinate network services without treating a traditional central server as the foundation of the architecture.

The system has gradually gained foundations for areas including:

Node communication and authenticated transport
Identity and delegated capabilities
Content-addressed storage
Distributed communication and streaming
Compute coordination
Hosting infrastructure
Reputation and accounting
Network state and diagnostics

Many of these started as isolated subsystems. The important step was getting them to operate as parts of the same network.

Then there were two nodes

One of the early milestones sounds almost trivial: two GNS nodes connected to each other. But for a distributed system, that changes everything.

Instead of testing components only inside a single process, we could observe actual communication between independent nodes. Nodes could connect. Network state could be observed. ENTENCY UP could interact with the GNS runtime. Applications could begin using network-backed services.

From there, the project stopped being only an architecture and started behaving like a network. And that exposed the next class of problems.

The easy network disappeared

Connecting two nodes in a controlled environment is one thing. Connecting machines across real networks is something else entirely.

Routers exist. NAT exists. Firewalls exist. Addresses change. Devices disappear and return. A node may know another node exists while having no usable path to reach it.

So a significant part of development shifted toward a less glamorous but essential question: How does a fresh ENTENCY node actually find and reach the network?

That led to work on transport authentication, bootstrap discovery, endpoint management and NAT traversal.

Transport identities were introduced so nodes could prove who they are during connection establishment. Bootstrap knowledge became bounded, persistent and diagnosable rather than simply assuming that a known peer would always be available.

Endpoint management began distinguishing between addresses that were merely observed and endpoints whose reachability had stronger evidence. UPnP mapping gained lifecycle handling, renewal and cleanup.

Diagnostics were added because a distributed network cannot simply say connection failed. It needs to explain why.

From “it doesn't connect” to evidence

One principle gradually became increasingly important during development: network behaviour should be observable.

If bootstrap fails, we want to know why. If an endpoint cannot be used, we want to know its verification state. If a node requires a relay path, that should be visible. If network knowledge is missing, stale or rejected, that should be diagnosable.

This led to tools such as GNS diagnostics, the GNS Shell, Doctor checks and bootstrap acceptance validation.

Instead of treating networking as a black box, ENTENCY increasingly records evidence about what the node actually knows and what it has actually verified. That distinction matters. Especially when leaving localhost.

Leaving the desktop

Another major experiment was taking the GNS runtime beyond the Windows development environment. A native ARM64 GNS daemon was brought onto a physical Android device as part of the ENTENCY GNS Mobile Node work.

That introduced an entirely different class of runtime and networking behaviour. Some things worked immediately. Others very much did not. And that is exactly why physical testing matters.

A system can pass unit tests, integration tests and controlled multi-node tests while still revealing completely different behaviour when placed on another operating system, another network stack or a mobile connection.

Those failures are not separate from the development process. They are the development process.

Where ENTENCY stands today

Today, ENTENCY is no longer just an idea represented by diagrams.

ENTENCY UP exists as a working Browser and Workstation environment. ENTENCY GNS has a functioning multi-node foundation and implemented subsystems for network communication, state, storage, compute and other distributed services.

Transport authentication, bootstrap knowledge propagation and persistence, NAT traversal foundations, endpoint verification and network diagnostics have all become part of the system.

But there is an important distinction: a working distributed architecture is not the same thing as a globally operating network.

The next challenge is moving further beyond controlled environments. Fresh nodes need reliable ways to discover the network. Independent network paths need to be tested. Bootstrap infrastructure needs to work outside the development environment. Different devices and real internet connections need to behave as expected.

And eventually, the system needs to demonstrate that all of these pieces continue working when the comfortable assumptions of a local development network are removed. That is where we are now.

Why the Built in Blog starts here

A lot happened before this blog existed. That is why this post is called The Story So Far.

From here, we can go deeper. We can revisit individual development milestones, architecture decisions, experiments and failures. We can show the network evolving instead of only describing the finished result afterward.

Some posts will be technical. Some will document experiments. Some will show things working. And some will document things that absolutely refused to work. All of them are part of the same story.

This is where ENTENCY stands today. The foundations are in place. The next challenge is taking the network beyond controlled environments and into real-world distributed operation.

From here on, we'll document that process as it happens.

Built in Public. Documented as we build.

Welcome to ENTENCY — Built in Blog

Entency — Tue, 29 Sep 2026 08:50:16 +0000

ENTENCY is being built in public.

Until now, much of our development progress has been shared through social media — milestones, experiments, screenshots, technical progress and the occasional battle with infrastructure. We wanted these updates to have a permanent home.

Built in Blog is the development journal of ENTENCY.

Here we’ll document the evolution of ENTENCY UP, our Unified Protocol Browser and Workstation Runtime, and ENTENCY GNS, the Global Neural System providing the distributed infrastructure underneath it.

Expect development updates, technical deep dives, experiments, architecture decisions, release notes and behind-the-scenes looks at what we are building — including the things that don’t work on the first try.

ENTENCY is still under active development, and that is exactly the point of this blog. We’re not documenting a finished product. We’re documenting the process of building it.

Welcome to Built in Blog.

Built in Public. Documented as we build.

— ENTENCY