LNS and BRIDGE: Why a Web4 Name System and a Web4 Browser Have to Ship Together

Two LINKSPREED projects are in beta right now, and neither makes full sense without the other. LNS, the Linkspreed Name Service, is the naming layer. It decides what a Web4 address means and who owns it. BRIDGE is the browser that reads those addresses and opens them. A name that nobody can open is only a label. A browser with nothing native to open is only an empty window.

This article explains what each one is, how they work together, why both are needed, and why we are keeping them in beta until they can do the whole job.

Key takeaways

LNS is the address book. It replaces the rented, registrar-based model of DNS with names that are owned and anchored to a UIID, with no recurring registrar fees.
BRIDGE is the door. It is a browser built for web4:// addresses and for resolving LNS names natively.
They are two halves of one system. LNS without BRIDGE has no way to be used. BRIDGE without LNS has nothing of its own to resolve.
UIID is the thread between them. The same identity that owns a name is the one that signs in.
Both are in beta, on purpose. We are holding the LNS registry launch until BRIDGE and our operating system layer, W4OS, can resolve names natively.

The current web rents out addresses

Every website address sits inside a hierarchy. At the top is the root, below it are the registries that run endings such as .com or .org, and below those are the registrars that sell names to the public. A person or a company does not own a domain name in this system. They lease it, usually year by year, under rules set by parties they never chose.

The yearly fee is the visible part. The less visible part is dependence. A name can be suspended, its price can change at renewal, and a brand that wants its own ending has to enter a formal process. ICANN’s current round for new top-level domains is a good example of how formal that process is. The application window ran from 30 April to 12 August 2026, and on 7 October 2026 ICANN published a list of 1,615 applications, including 333 from brands.

That route makes sense for large organisations that need a global, ICANN-recognised ending. It does not make sense for a sports club, a neighbourhood forum, a school class or a team of twenty people who want a name of their own. This is the gap LNS is built for.

LNS gives names to owners instead of tenants

LNS stands for Linkspreed Name Service. LINKSPREED describes it as a decentralized replacement for DNS in which the holder has full ownership of the domain, the identity and the personal data, with no middlemen and no recurring registrar fees.

Four ideas define it.

Names are anchored to a UIID

In our own words, LNS turns domain naming into ownership that is anchored to UIID. UIID is the identity layer of Web4. It splits an identity into a protected Core ID and context-specific Aliases, keeps the secret on the user’s own device, and signs in with biometrics and cryptography instead of passwords. When a name is tied to that kind of identity, ownership stops being an account at a company. It becomes something the holder can prove with the same device and the same biometric check used for everything else.

Names are free for life

LINKSPREED has described LNS Web4 domains as free lifetime domains with biometric security. The point is not a discount. The point is to remove the renewal cycle that makes a name a subscription.

Endings are open

The FreeTLDs initiative extends this to the part of the name that DNS controls most tightly. Through LNS, custom and unrestricted top-level domains are possible. The BRIDGE demo on web4.one shows what this looks like with sample names such as pizza.box, salad.bowl, hive.cluster and radio.mesh. The same demo labels the root as an LNS root with zero ICANN involvement.

LNS is a registry, not a browser

This matters for everything that follows. LNS holds names and answers the question “who owns this and where does it live?” It does not display a page. On its own, it is a phone book that no phone can read.

BRIDGE is the browser that makes those names real

BRIDGE is the LINKSPREED browser for Web4. LINKSPREED describes it as a browser that uses Web4 and LNS to give permanent digital ownership with zero recurring fees and no centralized gatekeepers. On the Web4 stack, it belongs to Layer 4, which we call HELION. HELION covers intelligent network routing, sovereign domain resolution and distributed server hosting. BRIDGE and the LNS domain engine sit there next to the HIVE server mesh.

Three jobs make BRIDGE different from a regular browser.

It understands web4://. A normal browser hands a web address to DNS. BRIDGE recognises the web4:// scheme and sends it down a different path.
It resolves LNS names natively. Names from the LNS root, including endings that do not exist in DNS, are meant to open directly in the browser, without a workaround.
It carries the UIID with it. Because the identity layer and the browser come from the same ecosystem, signing in with a UIID is a native action rather than a bolt-on.

The web4.one landing page shows BRIDGE as a native Web4 runtime at version 1.2 in its demo. One version of the stack page still marks the layer as coming soon, which fits where the product is today: real and testable, not finished.

Why a name system and a browser must exist together

This is the central point, and we made it plainly in a recent post. We are holding the LNS registry launch until BRIDGE and W4OS reach full native resolution, because handing out a domain without a browser that can resolve it is like giving someone the deed to a house with no road leading to it.

The dependency runs in both directions.

Question	LNS	BRIDGE
What is it?	A name service and registry	A browser and runtime
What does it answer?	Who owns this name, and where does it live?	How is this name opened and shown?
What does the user see?	A name they own	A page that loads
What happens without the other?	Names exist but resolve nowhere	The browser has no Web4 names of its own to open
Where does it connect to UIID?	Ownership of the name	Sign-in and identity in the session

There is also a technical reason. Names from an alternative root are invisible to ordinary software. A normal browser asks DNS, and DNS knows nothing about a name that lives only in the LNS root. Something on the user’s device has to know about the LNS root. BRIDGE is that something today, and W4OS is the operating-system version of the same idea.

This is why we refuse to separate the two in the beta. A registry that opened to the public before the resolver was ready would hand out names that cannot be reached. That would damage trust in the whole idea.

How they work together, step by step

The following walk-through is simplified. It follows the idea shown in the public BRIDGE demo and does not describe every internal detail.

A person types a Web4 address. For example web4://pizza.box. The web4:// prefix tells BRIDGE this is not a DNS request.
BRIDGE asks LNS. It looks the name up in the LNS root instead of the DNS root. LNS answers with who owns the name and where it is hosted.
BRIDGE connects to a host. In the demo this is a node in the HIVE server mesh. The demo shows a sample Frankfurt node with an encrypted connection and a latency of 11 ms. This is an illustration, not a benchmark.
The page loads. The site is shown like any other page, but the address behind it was resolved through an owned name.
The visitor signs in with a UIID. No password is typed. The check happens on the device, with the same biometric key used elsewhere in the ecosystem.

The owner’s side is the mirror image. In concept, a person or organisation holds a name with a UIID, points it at a host, and BRIDGE makes it reachable for anyone who has a browser that knows the LNS root.

UIID is the third piece

LNS and BRIDGE are the naming and browsing layers. UIID is what connects them.

In LNS, UIID answers who owns the name.
In BRIDGE, UIID answers who is visiting and, when needed, who is signed in.
Since version 2.8, UIID supports six entity types, including organisations, devices and AI agents. That means the same ownership model can in principle cover more than individuals. A company can hold a name as an organisation. A device or an agent can have an identity of its own.

This is also why the three pieces work better together than apart. A name service with its own account system would need a second login. A browser with its own identity system would not share it with anything else. Using UIID for both keeps one identity, one key and one place where ownership is proven.

Why both are in beta, and what that means

We call LNS and BRIDGE a beta, and we mean it literally.

The LNS registry has not launched to the public. We have said openly that we are holding it until BRIDGE and W4OS can resolve names natively.
BRIDGE is moving fast. The public demo shows version 1.2 of the native runtime, and HELION is still in progress.
Details can change. Names, endings, resolution behaviour and the user interface may all shift before a general release.

For testers, this has practical consequences. Any early name should be treated as part of the test, not as a permanent asset. Production sites should not depend on Web4 names yet. Problems are expected, and reporting them is the point of a beta.

The Web4 paper from July 2026 and the reference implementation are linked from web4.one. LINKSPREED also runs a Trusted Tester Program for early access to new UIID features, which is a way to follow the ecosystem as it develops.

Open questions we expect testers to ask

A new naming system raises hard questions. Better to name them than to wait for others to do it.

Who runs the root, and how is it governed? An alternative root needs clear rules, or it only moves trust from one operator to another.
What about name collisions? A root outside DNS can contain endings that also exist in DNS. How the two worlds coexist needs to be clear for everyone.
What about lookalike names and abuse? Free names and open endings make impersonation easier. A system with no middlemen still needs a way to deal with fraud.
What happens when a device is lost? If ownership is bound to a biometric key, recovery has to be safe without becoming a weak point.
How does the existing web fit in? Most of what people read still lives on ordinary DNS names. A new browser has to work with that reality.
Who hosts the content? A name is only an address. Hosting through the HIVE mesh, self-hosting or other options all raise their own questions about reliability.

None of these are reasons to stop. They are the reasons the work is in beta and not on a launch page.

Who should try it

Community builders. Anyone running a small network on ATRIUM or web4.community who wants a name that belongs to the community.
Developers. Teams that want to test web4:// resolution and UIID sign-in together.
Privacy-minded users. People who want a browser where sign-in and ownership do not depend on a password or a registrar account.
Organisations. Groups thinking about naming and identity for brands, devices or agents.

Identity comes first, and it is available today at uiid.me.

Frequently asked questions

Is LNS a replacement for DNS?

LINKSPREED describes it as a decentralized alternative to DNS. In practice it is a separate root that is read by BRIDGE and W4OS. Ordinary DNS keeps working as before.

Can a regular browser open LNS names?

Not natively. Names from outside the DNS root need software that knows the LNS root. That is the reason BRIDGE exists.

Are LNS names really free?

LINKSPREED has described LNS Web4 domains as free lifetime domains with biometric security, without recurring registrar fees. The registry has not launched publicly yet, so final terms apply at launch.

Why not launch the registry first and the browser later?

Because a name that cannot be opened has no value. We prefer to wait until resolution works natively.

Do LNS and BRIDGE need a UIID?

Ownership of an LNS name is anchored to UIID, and BRIDGE supports UIID sign-in. A UIID is therefore the starting point for both.

Where is this on the roadmap?

Both are in beta. LNS is the naming layer and BRIDGE is the browser layer of the same effort, and the registry launch follows native resolution.

Conclusion

LNS and BRIDGE solve one problem from two sides. LNS makes a name something a person owns. BRIDGE makes that name something anyone can open. Without the first there is nothing to own. Without the second there is nothing to reach. UIID ties both to one identity.

That is why they are being built and tested together, and why the public launch waits for the moment when both halves work.