From IP Addresses to Identity: How UIID Can Become the Addressing Layer of Web4

Every message you’ve ever sent across the internet was delivered using a number. Not your name, not your account — a number. Understanding that number, where it came from, what it can and cannot do, and what comes after it, is one of the most useful technical journeys you can take.

This article covers the full arc: what IP addresses are, how IPv4 and IPv6 work, where the model shows its age, and how LINKSPREED’s UIID, together with LNS, the web4:// protocol, and the BRIDGE browser and OS, opens the door to something genuinely new — an internet addressed by identity rather than by location.

What an IP address actually is

An IP address is the destination label on a packet of data. When your device sends information, it wraps it in a header that says, essentially: from this address, to that address. Routers along the way read only the destination, consult their routing tables, and pass the packet to the next hop closer to the target. Thousands of independent networks cooperate this way, with no central conductor.

Two properties define the system.

IP addresses are locations, not identities. An IP address describes where in the network topology something currently attaches, not who or what it is. Move your laptop from home Wi-Fi to mobile data, and its address changes completely. Nothing about the laptop changed; only its position did.

IP addresses are assigned, not owned. Address space is distributed from IANA to regional registries, from registries to ISPs and organizations, and from those to end users, usually temporarily via DHCP. Your address is lent to you.

IPv4: the internet’s original address book

IPv4 was standardized in RFC 791 in 1981. It uses a 32-bit address, written as four numbers from 0–255 separated by dots: 203.0.113.42.

Thirty-two bits allow roughly 4.3 billion unique addresses. In 1981, with a few hundred connected machines, that looked effectively infinite. It isn’t. Today that same pool has to serve over five billion internet users plus every phone, laptop, TV, sensor, camera, and server they touch.

The final IPv4 blocks were allocated by IANA in 2011, and every region has since depleted its supply. IPv4 addresses are now traded on a secondary market at roughly $48–60 each, a market generating over $850 million annually, and cloud providers charge about $0.005 per hour — roughly $43.80 per year — for every public IPv4 address you use.

The NAT workaround. The internet survived exhaustion through Network Address Translation. Your home router holds one public IPv4 address and hides an entire private network behind it, rewriting addresses and ports on the fly. ISPs took this further with carrier-grade NAT, sharing one public address among many customers.

NAT was brilliant engineering, and it quietly changed the internet’s nature. Behind NAT, devices can initiate outbound connections but cannot easily be reached directly from outside. The original peer-to-peer symmetry of the internet gave way to a client-server world, which is a significant part of why centralized platforms became the default shape of the web. Address scarcity became an architectural bias.

IPv6: the answer that arrived early and moved slowly

IPv6 was designed in the 1990s, with the modern specification finalized as RFC 8200 in 2017. It uses 128-bit addresses, written in hexadecimal groups: 2606:4700:4700::1111.

That yields roughly 340 undecillion addresses — a pool so vast it’s effectively inexhaustible. Beyond size, IPv6 brings simplified headers, stateless address autoconfiguration, cleaner routing, native multicast, and no structural need for NAT.

Where adoption stands in 2026: global IPv6 connectivity has reached roughly 47.5% of internet users, growing about 4.2% year over year. The picture is uneven. India leads at around 78%, France and Germany exceed 64%, the US sits near 58%, while some countries remain in single digits. Mobile networks lead decisively — tier-1 mobile operators carry over 88% of traffic over IPv6, and 94% of 5G standalone cores run natively on IPv6 — while enterprise internal LANs lag at around 28%.

Native IPv6 connections show a measurable latency advantage of roughly 10–15 ms over IPv4.

The transition is slow for an unglamorous reason: IPv4 keeps working. NAT removed the hard deadline, so networks upgrade when IPv6 becomes cheaper or easier rather than because they must. Most deployments are dual-stack, running both protocols side by side, with clients racing connections via Happy Eyeballs and using whichever answers first.

What neither IPv4 nor IPv6 was ever designed to do

Both protocols solve the same problem superbly: deliver this packet to that place. But the modern internet asks questions neither was built to answer.

Who or what is at the other end? An address proves reachability, never identity. Everything we use for identity — certificates, accounts, tokens — is a layer bolted on top.

How do we address things that move? Devices roam constantly between networks. Address-based identity breaks the moment location changes.

How do we address non-human actors? Autonomous agents, services, and hardware now outnumber humans online, and they need verifiable identity, not just reachability.

How do we avoid turning addresses into tracking beacons? Because addresses are tied to location and to subscribers, they’ve become one of the most widely used tracking signals in existence.

How do we stop paying for scarcity? A market where a single 32-bit number costs $50 is a market signaling that the underlying model has run its course.

None of this is a criticism of IP. It’s an observation that the addressing layer was designed for a network of places, and we now operate a network of entities.

UIID: identity as an addressable layer

This is where LINKSPREED’s UIID (Universal Integrated Identity Decoupled) becomes structurally interesting, not just as a login method but as an addressing primitive.

UIID is a local-first identity protocol that generates cryptographically secure identifiers directly on-device, using device biometrics and zero-knowledge proofs for passwordless, zero-liability authentication across both web and physical platforms. Its architecture splits presence into a master Core ID and context-specific Aliases, preventing cross-platform correlation. Keys are anchored in hardware security modules via WebAuthn.

Critically, in its current deployment UIID already issues secure digital passports across six specialized entity types, extending sovereignty beyond humans to AI agents and autonomous algorithms with zero-trust provisioning.

That multi-entity capability is the key that unlocks everything below.

Identity for hardware: giving devices a name of their own

If a person can hold a UIID, and an AI agent can hold a UIID, then so can a device.

Consider what that means. A router, a sensor, a camera, a vehicle, a home server, a Raspberry Pi running a community node — each can be issued its own registered identifier at the moment of provisioning, with a key pair generated inside its own secure element and never exported.

The practical consequences are substantial.

Identity that survives movement. A device’s UIID is bound to its hardware, not its network position. Move it from Ethernet to Wi-Fi to cellular to satellite: the identifier is unchanged. Every existing session, permission, and relationship remains valid, because none of them were ever tied to a location.

Authentication before connection. In an IP world, you connect first and authenticate afterward, which is why port scanning, spoofing, and unsolicited traffic exist as categories. With hardware-anchored identity, mutual cryptographic verification happens at the addressing layer itself. Devices that cannot prove themselves never establish a session at all.

A real inventory. Every device that participates is a registered, verifiable entity. Provisioning, rotation, and revocation become clean cryptographic operations rather than spreadsheet exercises.

No address scarcity, ever. Cryptographic identifiers are derived from key material, not carved from a finite numbering pool. There is no registry to exhaust, no secondary market, no per-address rental fee.

Privacy by construction. Because UIID separates a Core ID from context-specific Aliases, a device can present distinct identifiers to different services — reachable everywhere, correlatable nowhere.

Building an identity-addressed internet with Web4

Addressing by identity only works if the entire stack cooperates — resolution, transport, and client. That’s precisely what LINKSPREED’s Web4 stack provides.

LNS — the resolution layer. Where DNS maps a human-readable name to an IP address, LNS resolves names within the Web4 namespace. In an identity-addressed model, resolution answers a different question: not “which machine is at this location,” but “which verified entity holds this name, and what are its currently valid endpoints?” Because the answer is cryptographically bound to the entity’s key material, resolution and authentication become the same step rather than two hopeful ones.

web4:// — the transport layer. A native protocol scheme frees the client from assuming the destination is a host at an address. A web4:// request can be directed at an identity: a person, an organization, an agent, a community, or a piece of hardware. The session is established with an entity that has proven itself, and the underlying path — IPv4, IPv6, mesh, local link, relay — becomes an implementation detail chosen at connection time. LINKSPREED’s BRIDGE browser is built specifically on Web4 and LNS to deliver exactly this kind of decentralized access.

BRIDGE — the client layer. An OS and browser that understand identity natively can do what a legacy client cannot: hold the user’s UIID in secure hardware, sign requests locally, verify the far end’s UIID before rendering anything, and present a name rather than a numeric address as the primary unit of connection.

How a UIID-addressed connection works

Put together, a request looks like this:

1. Resolve. The client asks LNS for a Web4 name. LNS returns the entity’s UIID and its cryptographic material, plus current reachability hints.
2. Verify. The client challenges the destination. The destination’s secure element signs the challenge using a key that never leaves the hardware. Identity is confirmed before any application data flows.
3. Attest. The client’s own UIID presents exactly the proofs required — often nothing more than “a verified, unique entity is present” — using zero-knowledge proofs so no personal data is transmitted.
4. Transport. The session runs across whatever path is available today. IPv6 where present, IPv4 where necessary, direct local links where possible. The transport carries the conversation; it no longer defines the relationship.
5. Persist. The device roams, the underlying path changes, the session continues. The identity was never the address.

Notice the elegance of step four: this coexists with the internet we already have. Identity addressing doesn’t require the world to switch off IPv4 or finish IPv6 — it layers cleanly on top of both and simply stops depending on either for meaning. Exactly like the dual-stack pattern that carried IPv6 this far, the transition can be gradual, additive, and non-disruptive.

That’s what makes this achievable rather than theoretical. The hardware exists — secure elements ship in virtually every modern device. The cryptography exists and is standardized. The resolution layer exists in LNS. The protocol exists in web4://. The client exists in BRIDGE. The identity layer exists, is deployed, and already supports multiple entity types.

The bigger picture

IPv4 gave us the internet. IPv6 gave it room to grow. Both were engineered to answer the question where.

The next question, the one the entire industry is now circling, with the decentralized identity market projected to reach $77 billion by 2032, is who.

An internet addressed by identity is one where connections are authenticated before they exist, where devices are first-class citizens with verifiable names, where moving between networks costs you nothing, where addresses cannot be bought or exhausted, and where reachability never implies surveillance.

That’s what UIID makes possible, and what Web4 is built to carry.

Explore the identity layer of the next internet: uiid.me