Once Project Canopy had a physical node, the next question was not where it would live, but how it would be recognised.

A node can exist in someone’s home. It can be powered, connected, and physically owned by the user. But if it is going to participate in a wider system, the system needs a stable way to know what it is looking at.

Not just where the node currently appears on a network. Not just which address it has today. But which node it is.

That became the next challenge for Project Canopy. Giving the physical node a system-wide identity.

Why IP Addresses Were Not Enough

Most devices are recognised by networks through where they currently are. A phone joins a Wi-Fi network. A laptop connects through Ethernet. A router assigns addresses. Traffic moves through gateways. Devices appear, disconnect, reconnect, and sometimes return with a different address.

That is normal network behaviour. For many everyday uses, it is enough. A device needs to be reachable for a session, a request, or a connection, and the network handles the path.

But Project Canopy was not trying to treat the node as just another temporary device on a network. The node was meant to become a user-owned point of personal infrastructure. That meant it needed to be recognised as something more stable than its current network location.

IP addresses are useful, but they are not identity. An IP address can help a network route traffic to a device. It can describe where something can currently be reached. But it does not explain what that device is meant to be. It does not express ownership. It does not describe trust. It does not tell the system whether this is the user’s personal node or just another machine that happens to be connected.

It can also change. A node may move between networks. A router may restart. A home network may assign a new local address. An internet provider may change how the connection is routed. The device may be hidden behind local networks, shared connections, or other layers of routing.

If Project Canopy treated the node’s address as its identity, then the system would become too dependent on temporary network conditions. A change in address could become more than a connectivity issue. It could weaken the system’s understanding of which node it was dealing with.

That was the wrong foundation. An IP address can tell a network where something currently appears to be. It cannot tell Project Canopy which node it is dealing with. So the system needed another layer.

The Node Needed Its Own Identifier

The physical node gave Project Canopy a place to exist. The identifier gave that place a system identity.

This distinction became important because the system had to be able to refer to the node itself, not only to the path currently used to reach it. A user interface needs to know which node it is connecting to. Future services need to know which node they are communicating with. Local access, remote access, synchronisation, permissions, and trust all depend on the same basic question: Which node is this? That question comes before the question of how to connect.

An identifier does not replace networking. Devices still need networks to communicate. Data still needs a path. Connections still need to be established. But the identifier gives the system something stable to work from before the path is chosen.

Instead of asking only, “What address is this device on right now?” the system can begin with a different question: “Which node are we trying to reach?” That changes the design.

Connectivity becomes a matter of finding a path to a known node, rather than treating the current address as the node’s identity. The network location can change. The route can change. The connection method can change. But the system still has a stable way to recognise the node it is trying to communicate with.

This also makes the relationship between the user and the node clearer. The node is not just present because it appears on a network. It is present because the system recognises it as a specific part of the user’s personal infrastructure. That was the shift Project Canopy needed.

Why We Chose a 128-Bit Hexadecimal Identifier

For the starting point, we chose a 128-bit hexadecimal identifier. At a basic level, it serves a similar purpose to a UUID or GUID. It gives the node a stable reference that can be used across the system without depending on the node’s current IP address or network location.

But Project Canopy’s identifier is not treated as merely a standard application-level UUID.

UUIDs and GUIDs are useful general-purpose identifiers, but they also come with existing assumptions around format, generation, versioning, representation, platform behaviour, and how they are commonly used. Project Canopy needed an identifier model that could begin simply, remain system-controlled, and later evolve with the architecture rather than being tied too closely to a conventional UUID/GUID model.

The 128-bit hexadecimal format gave us a practical starting point. It provides a very large identity space, making accidental collisions extremely unlikely at the scale Project Canopy is beginning with. It is also simple to represent, compare, transmit, store, and debug. Those practical qualities matter when an identifier is not only a hidden database value, but part of how a wider system recognises and refers to a node.

Just as importantly, it gives the project room to grow. The identifier model can later expand to 256-bit, 384-bit, 512-bit, or another larger format if future layers require a larger identity space, stronger collision resistance, or additional identity structure.

So while the identifier behaves similarly to a UUID or GUID in that it uniquely refers to a node, it is intentionally treated as a Project Canopy identifier rather than a generic UUID.

The goal was not only uniqueness. The goal was to create a stable identity layer that belongs to the system itself.

Identity Before Connectivity

It is tempting to think connectivity should come first. After all, if two things cannot connect, nothing else can happen. But for Project Canopy, connectivity alone was not enough.

Before the system decides how to reach a node, it needs to know which node it is trying to reach. Before a client can trust a connection, it needs to know what it is connecting to. Before access can be managed, the system needs a stable idea of the node that access belongs to.

Connectivity is about paths. Identity is about the destination. That distinction shaped the next layer of Project Canopy. The node needed to be reachable, but reachability could not be the same thing as identity. If the system confused the two, every change in network condition would risk changing how the node was understood.

This is especially important for personal infrastructure because the node is not meant to be tied to one fixed environment forever. People change routers, move homes, switch networks, travel, replace devices, and use different access methods. The system has to remain clear about which node belongs to the user even when the path to that node changes.

A personal infrastructure node needed something more permanent than its current route through the internet. It needed an identity that belonged to the node, not to the router, the modem, the internet provider, or the temporary address assigned to it.

From Physical Ownership to System Identity

A Personal Internet cannot be built only around accounts, profiles, or devices recognised by someone else’s platform. It needs infrastructure points that can belong to the user and remain recognisable as part of the user’s own digital environment.

The physical node was the first part of that. It gave Project Canopy a user-owned place to live. The identifier became the next part. It gave that place a way to be recognised.

Together, those two layers changed the shape of the project. Project Canopy was no longer only asking where personal infrastructure should exist. It was asking how that infrastructure could have a stable presence of its own.

Physical ownership gave Project Canopy its foundation. System identity gave that foundation a presence. And once the node had both, the next challenge became clearer: how to reach it reliably, securely, and practically across the different environments where people actually live.