Throughout 2023 and 2024, much of DFLab’s public work focused on data privacy, data ownership, data autonomy, decentralised technologies, and data rights.

At the time, many of these topics appeared distinct. Data privacy focused on who could access information. Ownership focused on who controlled it. Autonomy focused on whether people could act independently in the digital world. Decentralisation explored how systems could connect without relying entirely on centralised authorities.

Yet the more we explored these ideas, the more they appeared connected. Again and again, different discussions seemed to lead back to the same place.

If users truly own their data, where does that ownership actually exist?

Looking for the Answer

At first, the answer felt obvious. Your phone, your laptop, your desktop computer, and the devices you already own and use every day. However, the deeper we looked, the less complete that answer became.

A phone is personal, but it is not designed to operate as always-on infrastructure. A laptop is personal, but it is frequently disconnected, closed, moved, or switched off. A desktop can provide greater stability, but it still depends heavily on location, maintenance, configuration, and availability.

These devices are important parts of our digital lives, but they did not fully answer the question, so we kept looking.

Exploring Existing Paths

Cloud platforms solved availability. They made information accessible from almost anywhere and removed many of the operational challenges that individuals previously had to manage themselves. However, they often reintroduced the very problem we were trying to solve because the infrastructure still belonged to somebody else.

Decentralised storage and peer-to-peer systems appeared promising from another angle.

Yet many of these models relied on distributing information across infrastructure operated by unknown participants. While technically fascinating, they raised a new question. If your data ultimately resides on systems you do not know, do not control, and cannot verify, has the ownership problem actually been solved, or has it simply been moved somewhere else?

We also explored personal storage systems and network-attached storage (NAS) devices. These came closer. They placed storage back under the user’s control and provided a stronger sense of ownership than many cloud-based alternatives. Yet they often remained expensive, technically demanding, difficult to maintain, or focused on solving a single problem rather than the broader challenge.

Ownership was about more than storage. It was also about accessibility, communication, applications, usability, and long-term independence.

The Missing Piece

The more we explored existing solutions, the more we found ourselves in an uncomfortable position. We believed ownership mattered. We believed autonomy mattered. We believed greater user control was possible. But we could not point to an existing model that fully aligned with those beliefs.

For a while, we had a problem without an answer. Eventually, another possibility emerged.

What if the reason we could not find the answer was because it did not yet exist?

That question became the starting point for what we now refer to publicly as Project Canopy.

The Birth of an Idea

Project Canopy did not begin as a product, a roadmap, a hardware device, a software application, or a finished architecture. It began as a possibility.

Could a person have their own data environment? Could they maintain ownership without sacrificing convenience? Could they remain connected without becoming dependent? Could they have infrastructure that belonged to them while still benefiting from the advantages of modern technology?

At the beginning, these questions were difficult to answer because the idea itself was difficult to define.

It was not simply a storage system. It was not simply a networking system. It was not simply a synchronisation platform. It was not simply a self-hosting solution.

Instead, it seemed to sit somewhere between multiple existing categories while fully belonging to none of them.

For a long time, the project remained broad, ambitious, and difficult to grasp. Before we could build anything, we first had to understand what we were trying to build.

Defining the Undefined

Looking back, one of the largest portions of the past eighteen months was spent on definition.

What exactly should this system be? What problems should it solve? What should remain local? What should happen remotely? How should devices communicate? How should users interact with it? What responsibilities should belong to the system itself? What responsibilities should remain with the user?

These questions influenced nearly every decision that followed.

The deeper we explored them, the clearer it became that the project was larger than we initially imagined. Every answer seemed to reveal another layer underneath it. A storage problem became a networking problem. A networking problem became an identity problem. An identity problem became a usability problem. A usability problem became an adoption problem.

The project gradually expanded from a single idea into a collection of interconnected challenges. Before we could solve the problem, we first had to understand its full shape.

As our understanding evolved, so did the project itself. Ideas that seemed central early on became less important. Questions that initially appeared secondary became fundamental. Rather than moving in a straight line from concept to implementation, development often involved revisiting earlier assumptions and redefining what the system needed to become.

In many ways, this period was less about building technology and more about building understanding. Before we could create a solution, we first had to understand the problem in its entirety.

Exploring the Foundations

As the broader direction began to emerge, the work moved into experimentation. Different communication models were explored. Different approaches to connectivity were explored. Different methods of discovery, synchronisation, remote access, and infrastructure management were explored.

Some concepts worked well in theory. Some worked well on diagrams. Some worked well in controlled environments. Not all of them survived contact with reality.

Different internet providers behaved differently. Different home networks behaved differently. Different devices behaved differently. The real world proved significantly more complex than any architecture diagram.

This period taught us one of the most important lessons of the entire project. The most elegant solution is not always the most useful one.

Many of the architectural concepts we explored were technically possible. Some were even technically impressive. However, technical possibility alone was never the goal. The goal was to create something that could operate consistently across different environments, different network conditions, and different users.

A system designed for everyday people must prioritise reliability as much as technical capability. That realisation shaped much of what followed.

When Assumptions Began to Break

One of the earliest directions we explored was a file synchronisation experience. The reasoning seemed sensible. People understand files. People understand folders. People understand synchronisation. It felt like a familiar and approachable entry point into a much larger idea, providing something tangible that users could immediately understand and interact with.

For a period of time, this appeared to be a promising direction. However, development quickly revealed that file synchronisation was not the system itself. It was merely one visible part of the system.

Keeping files synchronised required authentication. Authentication required identity. Identity required secure communication. Secure communication required networking. Networking required discovery. Discovery required reliability. Every layer depended on another.

What initially appeared to be a relatively straightforward application gradually exposed a much larger ecosystem underneath it.

The deeper we went, the more we realised that users needed more than access to files. They needed a way to understand the system, configure it, connect to it, manage it, and trust it. The file synchronisation experience ultimately helped us discover that the challenge was much larger than synchronisation itself. It revealed the foundations that would eventually need to exist beneath it and highlighted how many interconnected systems would be required to make the broader vision practical.

As these discoveries accumulated, it became increasingly clear that the project was not simply about building an application. It was about building the environment that made those applications possible.

From Exploration to Commitment

Over time, the project began to stabilise. Many assumptions changed. Some ideas were discarded. Others became foundational.

The broad direction became clearer. The project was no longer asking whether something like this could exist. It was now asking how it could exist.

Different responsibilities within the system began to emerge more clearly. Infrastructure, communication, management, applications, synchronisation, and connectivity all required their own roles within the broader ecosystem. What once existed as a broad collection of concepts slowly evolved into a more coherent system.

This marked an important shift. The focus moved away from exploring possibilities and toward building foundations. The challenge was no longer defining what Project Canopy could become. The challenge was turning it into something practical.

As development progressed, different layers of the system began to separate and mature. Communication systems needed their own responsibilities. Infrastructure systems needed their own responsibilities. User-facing experiences needed their own responsibilities. The project slowly evolved from a collection of ideas into a collection of systems.

While there was still significant work ahead, this was the period where the overall shape of the project began to emerge. For the first time, it became possible to see how the various pieces might eventually come together.

Beyond Technology

As this happened, another realisation emerged. The challenge was not only technical.

Even if the architecture worked perfectly, the project would still fail if people could not understand it, trust it, or successfully use it.

This changed how we thought about the project. Questions that initially seemed secondary became increasingly important. How should someone discover a system like this? How should they learn it? How should they understand what it is doing? How should they feel confident using it? How should complexity be managed without simply exposing more complexity?

The more we explored these questions, the more we realised that usability is not separate from infrastructure. It is part of the infrastructure.

A system intended for people must be designed around people.

That lesson influenced everything from software design to onboarding experiences and the broader direction of the project itself. It also expanded the scope of the project beyond software alone.

As development continued, we found ourselves exploring deployment experiences, onboarding journeys, documentation, operational workflows, hardware considerations, physical presentation, and long-term maintainability. The project was no longer simply about whether the technology could work. It was about whether people could realistically adopt it.

That distinction became increasingly important as development progressed.

Reaching the Real World

Eventually, Project Canopy reached a point where it could no longer remain an internal exercise.

For much of its existence, the project had lived within discussions, architecture diagrams, prototypes, testing environments, and development systems. Many of the questions we were trying to answer could be explored internally. Ideas could be debated. Assumptions could be challenged. Architectures could be revised.

Importantly, we were not only building the system during this period. We were also using it ourselves.

As development progressed, Project Canopy increasingly became part of our own day-to-day testing, experimentation, and workflows. This gave us valuable insight into how the system behaved in practice and helped uncover many of the technical, operational, and usability challenges that only emerge through regular use.

However, internal usage can only take a project so far.

The people building a system inevitably develop a deep understanding of how it works. They understand its assumptions, its terminology, its behaviours, and its intended workflows. Over time, it becomes difficult to see the project entirely through fresh eyes.

There comes a point where internal understanding is no longer enough.

The project has to encounter reality.

Not the controlled reality of development environments, but the reality of different people, different expectations, different homes, different devices, different levels of technical experience, and different ways of thinking.

This represented one of the most important transitions in the project’s journey.

For the first time, Project Canopy was no longer being shaped solely by the people building and testing it internally. It was beginning to be influenced by people approaching it from entirely different perspectives.

This changed the nature of the project. Questions that once seemed resolved were revisited. Assumptions that appeared reasonable internally were viewed differently through the perspective of new users. Certain ideas became stronger. Others required refinement. Some revealed challenges we had not previously considered.

This was not a sign of failure. It was exactly why reaching this stage mattered.

The purpose was never to prove that an idea could work for the people who created it. The purpose was to understand whether it could work for other people as well.

In many ways, this marked the transition from exploration into validation. The project was no longer simply asking what was possible. It was beginning to learn what was practical.

Why We Went Quiet

Looking back, this is one of the primary reasons DFLab’s public activity slowed throughout 2025.

The questions we were exploring had moved beyond theory. They could no longer be answered through discussion alone.

They required experimentation, testing, iteration, failure, redesign, and validation.

While public communication became quieter, development accelerated significantly behind the scenes. Much of what exists today is the result of countless revisions, discoveries, dead ends, prototypes, and lessons learned throughout that process.

From the outside, DFLab may have appeared quiet.

Behind the scenes, this was one of the most active and important periods in our history.

Looking Forward

Project Canopy continues to evolve. There are still questions to answer, systems to improve, and lessons to learn.

However, one thing has become increasingly clear.

The future of ownership, autonomy, and user control will not be shaped by ideas alone. It will also be shaped by whether those ideas can become practical systems.

The past eighteen months have been dedicated to exploring what those systems might look like. We began with a question we could not answer.

Today, we are building toward one possible answer.