In the last post, we explored how Project Canopy could reliably reach a known node. Giving the node an identity allowed it to be recognised. PathFinder made it possible to find a practical path to reach it.

But another question naturally followed. Once you’ve reached the node, what exactly have you reached? At first glance, the answer seems obvious. Storage.

After all, storing files is one of the main reasons people buy network-attached storage devices or subscribe to cloud storage services. If Project Canopy was about giving people ownership over their data, wouldn’t the node simply become another place to keep files?

As the project evolved, we realised the answer was much bigger than that.

The First Assumption

Like many ideas involving personal infrastructure, Project Canopy initially gravitated towards storage. That was a natural place to begin. Photos, documents, videos, and other personal files represent some of the most valuable parts of our digital lives. Giving people ownership over where those files lived seemed like an important first step.

If the node could securely store those files and make them available wherever they were needed, then much of the original problem would already be solved.

It was a sensible assumption. But it was also incomplete.

The Node Was Doing More Than Storing Files

As we continued building Project Canopy, the node gradually took on more responsibility.
It needed to establish its own identity. It needed to communicate across different networks. It needed to authenticate users and devices. It needed to synchronise information. It needed to host applications and coordinate how those applications interacted with the user’s data.

None of these responsibilities were simply “storage.”

Storage was only one capability among many. The node itself was becoming something much broader. It was becoming a platform.

A Different Way to Think About Personal Infrastructure

This changed how we viewed the project. Instead of asking, “How do we build a better place to store files?” we began asking, “How do we build infrastructure that people can genuinely own?” Those questions sound similar, but they lead to very different architectures.

A storage device exists primarily to hold information. Infrastructure exists to provide services. The internet we use today is not simply a collection of files. It is made up of applications, identities, communication, collaboration, automation, and countless services that work together behind the scenes.

If Project Canopy was intended to become part of a Personal Internet, then it needed to support much more than storage. It needed to become the foundation upon which those services could exist.

More Than a Personal Cloud

This is one of the biggest misconceptions about Project Canopy. It is easy to compare it to a private cloud or a network-attached storage device because those are familiar ideas.

Both provide users with greater control over where their files are kept. Project Canopy certainly shares some of those characteristics. But that is not its destination.

The objective was never to build a better Dropbox, Google Drive, or NAS. Those products solve a storage problem. Project Canopy is trying to solve an ownership problem.

Ownership extends beyond files. It includes the services that operate on those files, the applications people use every day, the identity that ties those experiences together, and the infrastructure that allows them to work consistently regardless of where the user happens to be.

The node was never intended to be a digital filing cabinet. It was intended to become a home for personal infrastructure.

The Architecture Began to Change

Recognising this shifted many of the architectural decisions that followed. Rather than designing around individual features, we began designing around capabilities.

Networking was no longer just about transferring files. Identity was no longer just about recognising a device. Synchronisation was no longer just about keeping folders up to date. Each became part of a broader platform that could support many different applications over time.

That way of thinking made the architecture more flexible. Instead of asking whether a new feature belonged inside the node, we could ask a more fundamental question:

“Does this capability belong as part of personal infrastructure?”

If the answer was yes, then the node should be capable of supporting it.

Building for the Future

One of the advantages of thinking in terms of a platform rather than a product is that it creates room for growth. The first applications might focus on familiar tasks like file management and synchronisation. Future applications may solve entirely different problems.

The underlying infrastructure does not need to be reinvented each time. It simply provides the foundation upon which those applications can operate. That philosophy has shaped Project Canopy from the beginning.

Rather than building isolated solutions for individual problems, the project aims to build a foundation that can support many solutions in the future.

Looking Ahead

Understanding that the node was becoming a platform changed another part of the project. If users were no longer interacting with a storage device, but with their own personal infrastructure, then they would need a different kind of interface.

Managing files alone would not be enough. They would need a way to manage the node itself.

That realisation led to another important step in the evolution of Project Canopy, one that fundamentally changed how people would interact with their personal infrastructure.