Part I — The Invention

Before there was an investigation, there was an idea.

The idea began with a question:

Can communication and financial transactions take place without requiring us to surrender control of our privacy and sovereignty through which that information travels?

I began thinking about communication within emerging Web3 environments, where identity, ownership, governance, and transactions were increasingly being represented digitally.

But the problem was larger than sending a message.

A person might need to communicate privately with another person. A journalist might need to communicate with a source. An organization might need to coordinate sensitive information. Members of a decentralized organization might need to discuss governance. Participants in a financial transaction might need to communicate without unnecessarily exposing information about themselves or their activity.

What happens when those interactions depend upon infrastructure controlled by someone else?

My original concept was to approach that problem architecturally.

The invention combined client-side encryption with decentralized, transient relay infrastructure. Rather than relying upon a conventional centralized server to receive, store, and manage communication, the proposed system would use relay nodes whose purpose was to facilitate the traversal of information and then discard the associated data.

The relay was not intended to become the custodian of the communication.

It was intended to be transient.

The concept contemplated messages being encrypted on the user's device before leaving that device. The relay would therefore function as part of the transportation mechanism rather than as the party responsible for accessing the plaintext.

Identity was also approached differently.

Instead of relying upon usernames, passwords, or other conventional identity providers, the concept incorporated cryptocurrency wallets as the foundation for identity and authentication. Wallet-to-wallet communication could therefore establish a cryptographic relationship between participants.

The potential applications extended beyond ordinary messaging.

The system contemplated communication associated with decentralized organizations, including governance activity and multisignature operations. It also contemplated financial transactions and other interactions in which the parties might have reason to communicate without relying upon established communication platforms.

This distinction matters.

I was not simply attempting to create another messaging application.

I was attempting to rethink the infrastructure through which communication and transactions could occur.

The Transient Relay

The transient relay became one of the central ideas.

The relay would receive information, facilitate its delivery, and then destroy the information associated with that interaction.

The proposed architecture contemplated the use of volatile memory rather than persistent storage, with information existing only for a predetermined period of time or for the duration necessary to facilitate transmission.

The intention was to minimize the existence of an audit trail.

This raised immediate architectural challenges.

What medium would I utilize to secure the data?

Will the medium ever connect to the internet?

These were not peripheral questions.

They were part of the invention itself.

The absence of persistence creates a different security model, but it also creates different engineering constraints.

The concept therefore required consideration of delivery mechanisms, relay selection, identity, encryption, routing, storage, and the relationship between the communicating devices and the infrastructure between them.

The Questions Behind the Invention

It was always apparent that encryption alone was not the entire problem.

End-to-end encryption can protect the contents of a communication.

But what about the infrastructure surrounding the communication?

What information exists while the communication is moving?

Who controls the systems through which it travels?

What remains after the communication has been delivered?

And what happens when a supposedly private interaction becomes dependent upon several other protocols?

Those questions would eventually lead me somewhere much larger than the original invention.

But at this point, I was still designing.

I was trying to solve the problem by creating a different architecture.

The provisional patent captured that thinking.

It captured the system I imagined, the mechanisms I believed could address the problem, and the applications I believed could benefit from it.

It was a snapshot of the idea before the investigation that followed.

Part II — The Quest

One Year Ago

One year ago I began on a Data Sovereignty Quest.

How can people who need private messaging — journalists, NGOs, and people conducting financial transactions, do so on platforms that are publicly known for sharing data?

Platforms known to harvest data:

Platforms that state a willingness to profile people, knowing that such profiling could, in particular circumstances, put lives at risk and discuss it as though it were just a normal day's work?

How could we possibly trust these means of data exchange?

That question disturbed me.

It wasn't simply a question about whether a message was encrypted.

It was a question about whether the infrastructure carrying that message deserved the level of trust we routinely give it.

So I began designing a messaging system that would not utilize any of the established platforms.

A system that would not store data.

A system that would be ephemeral.

A system that could operate on an independent device, such as a Raspberry Pi.

The goal was to send messages and conduct transactions securely on a device that did not require conventional internet service.

I wanted to develop a protocol that was sovereign.

At the time, I was attempting to bring two ideas together:

independence from the internet and an ephemeral relay protocol.

Over the following year, I began questioning whether those two ideas could actually coexist in the way I originally envisioned.

That realization did not invalidate the original concept. It created another question.

And that question became more interesting to me as the year progressed.

I began looking beyond the message itself.

I began looking at the infrastructure surrounding the message.

The Question Changed

During the past year, I continued researching communication systems, application architecture, network traffic, and the parties integrated into the systems we use every day.

Through that research, I began to recognize something within my original concept that I had not fully confronted at the beginning.

My objective was to combine independence from the internet with an ephemeral relay protocol.

I began questioning the architectural relationship between those two ideas.

The question changed.

I began examining applications.

I began examining their architecture.

I began examining the systems communicating with them.

And I began examining what happens when data crosses from one system into another.

An application can be well designed.

It can perform exactly as its developers intended.

It can protect the information it was specifically designed to protect.

And yet, when that application becomes part of a larger stack of applications, services, libraries, APIs, infrastructure, analytics systems, authentication providers, advertising systems, or other integrations, the security and privacy characteristics of the overall system can change.

This raised another question:

Can an application be secure in isolation while the system surrounding it introduces vulnerabilities that the application itself does not contain?

I began examining applications not only as individual products, but as components within larger systems. In order to engineer a software, design a protocol and establish a secure means of data transmission, I first had to analyze the current systems as they are.

The question wasn't merely "does an application work?". It became: Who else is involved in making it work?

My focus was architecture, plus intent of the the architect. And who were the invited third parties?

As I researched different applications,
I became increasingly interested in the parties
that participate in the traversal of data.
The more I looked at systems,
the more I began noticing
Connections.
Requests.
Domains.
Endpoints.
APIs.
Services.
Infrastructure.
Third-party integrations.
I began seeing that an interaction that appears simple
from the user's perspective can involve considerably
more infrastructure beneath the surface.

A person may perceive an interaction as:

“I sent a message.”

Architecturally, however, that interaction may involve many systems communicating with one another.

This became one of the central questions of my research:

What happens to the data when it crosses each boundary?

And another question:

Who controls the systems on the other side of those boundaries?

Upon reviewing network traffic, I began noticing what appeared to be an increasing number of participants in interactions.

I know that third parties are involved because I can observe connections to systems beyond the primary application or service.

But observation creates another question.

Has third-party integration become so sophisticated within data traversal that it becomes easy to proclaim that they are not there?

One Year Later

One year ago, I was asking how to create a communication system that could be sovereign.

Today, I am asking a broader question:

What does sovereignty mean when the infrastructure carrying our information is controlled by someone else?

We have become extraordinarily comfortable exchanging our most intimate information through systems we neither own nor control.

Messages.

Relationships.

Political conversations.

Organizational information.

Research.

Financial information.

Personal histories.

And, increasingly, information that shapes how we understand one another and the world around us.

This raises a question that extends beyond cybersecurity.

What happens to privacy and ultimately to democracy, when the infrastructure through which people communicate is controlled by systems they cannot meaningfully inspect or govern?

I do not intend for this publication to answer that question today.

I intend to investigate it.

What Do We Surrender?

The packet capture gives you the footprints.

The broader documented reality of contemporary digital systems helps establish what those footprints may represent.

You can observe the architecture and then investigate what is already documented

about data collection, tracking, profiling, advertising, automated decision-making, and machine-learning systems.

Some platforms provide privacy controls, opt-outs, or deletion mechanisms.

Others may make participation conditional upon accepting particular practices.

The deeper question for me is not simply whether an option exists.

It is whether that option provides meaningful sovereignty and practical control.

Sovereignty

We place our communications within systems whose architecture, infrastructure, policies, and future development we do not govern.

Control

We cannot independently determine every system through which our data travels, how those systems change, or which third parties become part of the ecosystem.

Anonymity

Even when the content of a communication is protected, participation in a network can generate metadata and other observable information about the communication.

Choice

We may technically have privacy settings, opt-outs, or deletion mechanisms, but our ability to withdraw from an ecosystem altogether can be limited when essential communication, employment, commerce, or services depend upon it.

Data Autonomy

Information generated through our participation can become part of systems used for purposes beyond the immediate act of communication—including analytics, profiling, automated systems, and potentially machine-learning applications, depending on the platform's practices and terms.

This brings me back to the question that began changing the direction of my research:

When I communicate through infrastructure I do not control, what am I actually giving up?

The answer isn't simply privacy.

It may be a degree of sovereignty over the conditions under which our data exists, moves, and may subsequently be used.

Encryption answers one question.

Sovereignty asks who controls the environment surrounding the communication.

The Illusion of Choice

Opting out is not always as simple as choosing “no.”

In some digital systems, exercising an opt-out may require the user to navigate settings, locate documentation, follow a separate process, submit a request, or communicate with the organization operating the platform.

The existence of an opt-out mechanism does not necessarily mean that the choice is immediate, obvious, or equally accessible to the person using the service.

There is another complication.

Sometimes the decision to opt out comes after participation has already begun.

A person may use a platform because their employer requires it, because their community uses it, because it provides a necessary service, or simply because it has become the convenient means of communication.

At some point, the user may encounter a choice that effectively becomes:

Agree, or do not use the platform.

The decision to withdraw may therefore occur under the pressure of an existing dependency.

The user is not necessarily making a choice between two equally accessible alternatives.

They may be deciding whether to surrender continued access to something they already rely upon.

And the question extends beyond the content of a message.

Digital interactions can also contribute to the creation of a digital fingerprint, a collection of characteristics and signals that can help distinguish or recognize a device, browser, account, or user across interactions.

Some of these characteristics can exist outside the message itself.

This creates another layer of the sovereignty question.

I may choose what to write.

I may choose whether to send the message.

But how much control do I have over the information generated simply by participating in the system?

The ability to opt out after participation has begun is not necessarily equivalent to having control from the beginning.

This distinction matters because sovereignty is not merely the ability to leave a system.

Sovereignty is having meaningful control over whether, how, and under what conditions you participate in it in the first place.

Follow the Connections

The patent is where the idea began.

The investigation did not end there.

If anything, the patent gave me a place from which to begin asking different questions.

So now I want to invite you to investigate the systems you use yourself.

You do not have to take my observations as the answer.

You do not have to agree with my conclusions.

You can open the tools and look.

Exploring Data Traversal With Developer Tools

You do not need specialized security software to begin.

Choose a web application that you use regularly.

Try this:

1. Open a web application you use regularly.

1. Open your browser's Developer Tools.

In most browsers, right-click the page and select Inspect, or use the browser's Developer Tools keyboard shortcut.

1. Select the Network tab.

1. Reload the page.

Watch the requests populate as the application loads.

1. Interact with the application.

Open a page.

Search.

Send a message.

Upload something.

Perform another ordinary action.

1. Watch what appears.

You may begin to see that an action you perceive as:

“I sent a message.”

can involve a much larger collection of requests and infrastructure.

Pay attention to:

• Domain / hostname — Where is the browser sending the request?

• IP address — What infrastructure does the hostname resolve to?

• Request method — What type of HTTP request is being made?

• Status code — How did the server respond?

• Initiator — What caused the request?

• Headers — What information accompanies the request?

• Response — What does the application receive in return?

• Timing — When does the communication occur?

• Third-party domains — Which domains appear that are not the primary domain you intentionally visited?

Now repeat the process while performing a specific action.

Clear the existing requests.

Perform the action.

Watch what appears.

Then ask:

Who else is involved?

Why are they involved?

What information crosses each boundary?

Who controls those systems?

And perhaps most importantly:

Would I know these systems existed if I had never looked?

The purpose of this exercise is not to assume that every third party is collecting information improperly.

It is to observe the architecture.

A network request is a footprint.

A packet is a footprint.

A domain is a footprint.

The footprint does not necessarily tell you the entire story.

But it can tell you where to begin looking.

You can then investigate the organizations, documentation, policies, technical architecture, and other available evidence associated with what you observed.

That is the process I have come to value:

Observe.

Analyze.

Question.

Investigate.

Understand control.

And then ask what the implications might be.