Iroh and App Private Networks

I wrote about Sovereign Apps before I knew Iroh. I was trying to put a name to a discomfort I kept running into: as soon as a local product needs a second device, the hosted account tends to become the centre of the system. The data moves somewhere else, the two devices start talking through an API, and a computer I own becomes a client of a service it did not need a week earlier.

That is often a reasonable trade. I do not think every application should be self-hosted, and I do not think a remote service is automatically a compromise. But I wanted to see whether a different shape could work when the data already had a sensible home. In Tape Music Suite, that home is the computer holding my music library. The phone is there to listen to it, not to become another cloud-managed copy of it.

The first Sovereign Apps post was deliberately incomplete. I could explain the product boundary I was interested in — a computer as the authority for a defined body of personal data, with companion devices that connect for a specific purpose — but I did not yet have an answer for the route between those devices. “They connect privately” is an appealing sentence until you have to make it work on a phone behind a mobile network, or decide who else should be allowed into that connection.

My first instinct was to reach for the tools I already knew. A mesh VPN can make two devices see each other, but it also brings its own account, client, identity model, and maintenance burden. The network starts becoming a product that the person has to understand before they can use the music product they actually came for. That felt like moving the complexity out of Tape rather than resolving it.

I found Iroh while building Tape. What interested me was not that it could turn the phone into a remote desktop or put every device on a virtual LAN. It gave me lower-level pieces: cryptographic endpoint identities, address information, NAT traversal, encrypted QUIC connections, and a relay route when a direct connection is not possible. It did not give me a user account, a pairing flow, permissions, a library, or a backend pretending to be neutral.

That absence was the useful part. I could use Iroh to carry a session without asking it to decide what the relationship between two devices meant. Tape could still decide which phone was paired with which library, what it could access, how long a discovery record was useful for, and what the person should see when their computer was asleep. Iroh did not make those questions disappear. It stopped the transport from answering them by accident.

I had started by thinking about getting two machines onto the same network. Iroh pushed me towards a different question: what if an application suite can define its own network? Not a private internet, and not a general-purpose VPN. A network with a specific purpose, known endpoints, a connection policy, and an application protocol that belong to the apps using it.

Calling it private is only part of the picture. The same foundation can support something completely closed around one person's devices, selective sharing with a few people, or a more participatory space where people contribute within limits set by the product. Peer-to-peer describes how endpoints can exchange data. It does not decide who may join, what they may see, what they may change, or whether a shared piece of state belongs to everyone. Those are choices made by the application suite.

I have started to think of this as opening up the machinery behind meta-internets: small, bounded environments organised around a purpose people can understand, such as a library shared with friends, a private archive, or a collaborative collection. They do not need a token, a blockchain, or an economic incentive to hold together. The utility of the app can be enough.

This is not a claim that every part of the system is decentralised. Tape has an intentional centre: the computer that holds my music library. Another app may have a curator or rule-maker. The point is that this authority belongs to the purpose-built network, rather than being absorbed by a general platform. Iroh puts the route between endpoints below the application, leaving the suite to choose its own rules, bridges, and way of participating.

Participation is part of the network

The first time a QUIC connection opens, it is tempting to feel that the difficult part is done. It only proves that two endpoints can exchange bytes. The product still has to decide how a new device pairs, which identity survives a restart, how the phone finds an updated address without treating a discovery helper as an authority, and what changes when the traffic has to go through a relay.

I built those answers around Iroh rather than inside it. Tape publishes short-lived, signed presence so a phone that is already paired can find current connection candidates. The phone verifies that presence against the hub identity it already knows. When the QUIC session opens, Tape still checks its own application session before it exposes protected data. A connection is necessary; it is not permission.

That distinction is where the idea becomes more interesting than a private link. The person or team making the apps can define whether a network is only for their own devices, whether another person gets one narrow capability, or whether a group can take part in a shared activity. The boundary is not merely technical. It is a product decision made explicit in pairing, capabilities, data ownership, and the messages the apps accept.

This separation matters to me because a direct route and a relayed route can still be the same relationship. Changing the route should not force someone to create another account, pair their device again, or move their music into a service. The relay makes a path possible; it does not become the owner of the library.

There was no React Native integration that matched the boundary I wanted, so I built a narrow Rust bridge for iOS and Android and exposed it through a TurboModule/JSI layer. It starts and stops an endpoint, accepts an endpoint ticket or explicit address information, opens QUIC connections, and moves framed bytes between native code and JavaScript. Pairing, authentication, discovery policy, retries, HTTP semantics, media, and the way failures are explained still belong to Tape.

That work made the limits much less abstract. Reusing one QUIC connection for several streams does not define response semantics. A stable endpoint identity helps a phone reconnect, but it does not say whether that phone may browse the library. A relay can get a route through a hostile network, but it cannot make an unclear access model safe. The private network only exists in a meaningful sense when all of those choices agree.

An experiment after the first idea

The original Sovereign Apps text came first. After I had a real implementation in Tape and the Iroh bridge to learn from, I opened Sovereign Apps: a separate, public attempt to extract the parts that might be useful beyond a music player. It is deliberately WIP and pre-alpha. It is not something I would ask anyone to install or trust with production data yet.

The project is trying to keep a few concerns separate: identity and key storage; discovery and bootstrap; authenticated pairing and capability grants; transport adapters such as Iroh over QUIC; and the messages an application puts above the transport. It is not meant to be a generic P2P network in search of a use case. I want it to make room for application-defined networks whose participation model can range from private to selectively shared to deliberately collaborative.

Tape remains a product with music-specific decisions. Sovereign Apps is where I can test whether there is a neutral, modular shape underneath those decisions without pretending that one exists just because the folder has a name. If that separation survives contact with more than one product, it will be useful. If it does not, the failed abstraction is still worth finding early.

I still use “Sovereign Apps” as a working name, not as a category I think I have invented. For me it describes a boundary: the source computer remains authoritative for something personal, another device gets a focused experience, and the application owns the pairing and permissions even when a hosted helper is useful for discovery.

It does not remove the cost of keeping a machine online, operating relays, or maintaining software. It just makes those costs visible in the product instead of scattering them across unrelated services. Iroh has not proved that this is the right architecture for every application. It has made the question concrete enough to test with real devices, real networks, and failure cases that do not care about a neat diagram.

That is already more useful than the original phrase. I am no longer thinking about putting an app on top of a private network. I am thinking about whether a connected set of apps can define a small meta-internet around a specific relationship, purpose, and way of participating — and keep its boundaries, bridges, and rules legible to the people inside it.