In the last post, we explored why Project Canopy’s node needed an identity.

A physical node gave the system somewhere to exist. An identifier gave that node a stable place inside the system. But identity only answered one question: Which node are we trying to reach?

It did not answer the next one: How do we reach it?

That became the next practical problem Project Canopy had to solve.

Recognition Was Not Reachability

A node identifier made it possible for Project Canopy to recognise a specific node across changing conditions.

That was an important step. The node no longer had to be understood only as a device on a local network, or as something tied to a temporary address. It could be recognised as the same node even when the network around it changed.

But recognition alone was not enough. A node could have a stable identity and still be unreachable.

It could be sitting behind a home router. Its network address could change. The user could be away from home. The router could block inbound connections. The internet provider could apply restrictions. The path between the user and the node could change depending on where the user was connecting from.

In other words, the system could know exactly which node it was looking for and still have no practical way to reach it. That distinction became important very quickly.

Identity tells the system what it is looking for. Reachability tells the system how to get there. Project Canopy needed both.

Direct Access Could Not Be the Whole Answer

The simplest approach would have been direct access.

If the user was on the same local network as their node, the client could try to find and connect to it directly. In some situations, that works, and Project Canopy should preserve that path wherever possible.

But direct access could not be the whole answer.

A personal node has to remain useful when the user is not at home, when the network changes, or when a simple local route is not available. Most home networks are designed to let devices inside the home reach the outside internet. They are not designed to make devices inside the home easily reachable from the outside.

One option would have been to push that complexity onto the user. Ask them to configure port forwarding. Ask them to expose a service from their home network. Ask them to understand router settings, static addresses, firewall rules, and internet provider restrictions.

That may work for technical users, but it was the wrong default for Project Canopy. The purpose of the node was to make personal infrastructure practical. It was meant to bring ownership closer to the user, not create a new maintenance burden.

A user should not need to become a network administrator just to access their own digital environment.

So Project Canopy needed another layer. Not a replacement for the node. Not a central cloud account that quietly took ownership back. A connectivity layer.

This Became PathFinder

The reachability problem led to PathFinder. PathFinder was designed to help Project Canopy answer a practical question:

Given a known node identity, what path can be used to reach that node now?

That is the role of PathFinder. It does not give the node its identity. The identifier already does that. It does not replace the node. The node remains where the user’s personal infrastructure lives. It does not become the owner of the user’s data. Its purpose is to help known parts of the system find practical ways to communicate.

PathFinder exists because identity and reachability are different problems. The identifier tells Project Canopy which node is the destination. PathFinder helps the system work out how that destination can be reached.

This became one of the most important layers in the architecture.

The Node Needed to Make Itself Reachable

A key part of the solution was changing the direction of the problem. Instead of expecting the outside world to find the node directly inside a home network, Project Canopy could allow the node to maintain its own presence within the wider system.

That matters because outbound connections are usually easier than inbound ones. A device inside a home network can usually reach out to the internet. That is how most connected devices already work. The harder problem is reaching inward from the outside.

PathFinder uses that difference as part of the design. The node can make itself known to the system in a controlled way. The system can associate that presence with the node’s identifier. Then, when an authorised client needs to reach the node, Project Canopy has a practical basis for finding a path.

This avoids asking the user to manually expose their home network. It also avoids making the node disappear just because the user is not on the same local network.

The node remains the centre. PathFinder helps make it reachable.

Local When Possible, Assisted When Needed

Project Canopy also needed to avoid treating every connection the same way. If a client and node are on the same local network, it should not always need to travel through an assisted path. Local access should remain local where possible.

That is important for performance, resilience, and the larger philosophy behind the project.

Project Canopy is not trying to make every interaction depend on a central layer. It is trying to make personal infrastructure usable across real conditions.

So the approach became layered. Use local paths when they are available. Use PathFinder when assistance is needed. Keep the node’s identity consistent across both.

This means the user does not need to think about whether they are local or remote before the system can work. The system can treat the node as the same destination and use the most practical path available at the time.

That is the difference between a device that only works in one environment and infrastructure that can adapt to changing conditions.

Reachability Without Recentralising Ownership

PathFinder also introduced an important design boundary. A connectivity layer can easily become the centre of a system.

Many modern platforms solve reachability by placing themselves in the middle of everything as a “middleman”. The device connects to the platform. The app connects to the platform. The user gets convenience, but the platform becomes the real point of control.

That was not the direction Project Canopy was meant to take. PathFinder had to help with reachability without becoming the place where the user’s digital life actually lives. It had to support connection without taking over ownership. That boundary matters.

The node remains the user’s personal infrastructure. The identifier continues to point to that node. PathFinder helps known participants find practical paths to each other, but it does not replace the role of the node itself.

This was the balance Project Canopy had to maintain: make the system usable, but do not recentralise what the project is trying to return to the user.

What PathFinder Solved

PathFinder changed what Project Canopy could practically become.

The node no longer had to depend only on local discovery. The user no longer had to configure their router manually. Changing network addresses no longer had to break the system’s understanding of the node. A client could look for a known node, and the system could help establish a usable path.

The networking complexity did not disappear. It still exists underneath. But it moved away from the user and into the system design. That was the important shift.

Personal infrastructure should not require people to manage every technical layer by hand. It should make ownership usable enough that it can fit into ordinary life. PathFinder became one of the layers that made that possible.

The Next Layer of Project Canopy

Project Canopy has been built through a sequence of practical problems. First, the system needed somewhere to exist. That led to the physical node. Then, the system needed to recognise that node consistently. That led to the identifier.

But identity was not enough. The system also needed a way to reach the node under real-world network conditions. That led to PathFinder.

This was the next step in turning Project Canopy from a device into infrastructure. The node could now be more than something sitting in a home. It could become a reachable part of a wider personal system, without asking the user to expose their network, configure routers, or give control back to a central platform.

Identity told Project Canopy which node it was looking for. PathFinder helped Project Canopy find a way to reach it.