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.
Top comments (0)