Summary: Moving a pico from one engine to another looks like a migration feature, but the point is autonomy. Most people will never run their own servers, so freedom online depends on apps and data that can move between hosts, and identity is what lets them move without breaking. This post lays out the argument behind my IIW demo.
My session at Internet Identity Workshop (IIW) next week will show a pico moving from one engine to another. A bike club sells Gravel Bike #7 to a new owner, and the pico that represents the bike, along with the child pico for its bike computer, moves from the club’s mesh to the new owner’s mesh. Its identity comes along, and so do its relationships. I described the mechanics (with a video) in Moving Picos from Mesh to Mesh; here I want to explain why I think it matters.
It’s easy to see a demo like this as a migration feature, the kind of thing an operations team uses to shuffle workloads between data centers. That is not my primary goal. My aim is loftier: portability is how people keep control of their online lives without having to run the infrastructure themselves, and identity is what makes portability work. In other words, identity enables autonomy.
Freedom Requires Portability
Personal freedom online requires that we control our apps and our data. I’ve been making some version of that argument for decades. For example, in The CompuServe of Things, I worried that the Internet of Things was being built as a collection of walled gardens, each with its own servers, accounts, and terms of service. If the company running the server decides your thermostat is no longer supported, the thermostat stops being yours in any meaningful sense. The same is true of the apps and data that run the rest of our lives.
The obvious answer is to run your own servers, but realistically, most people never will. That isn’t a failure of will or education; it’s the same reason most people don’t generate their own electricity. Hosting is a service, and people should be able to buy it the way they buy other services, so long as they can freely move to another service. A renter doesn’t own the apartment, but they own the furniture, and when they move, the furniture goes with them. Apps and data should be the same: hosted by someone, but not owned by them.
Spheres of Control
Every hosting arrangement comes down to a simple question: whose rules apply? In the physical world, we answer it without thinking. The things in your house are yours to use, lend, or rearrange; the things in a store belong to the store until you buy them, and the store sets the rules for handling them. Each of us has a sphere of control, the set of things we get to make decisions about, and we move through other people’s spheres all day long without confusing them with our own.
Online, those boundaries are much harder to discern. An app on your phone feels like yours, but in most cases the app’s logic and the data it collects live on someone else’s servers and follow someone else’s rules. You’re a visitor in the provider’s sphere of control, even when the subject is your own health, your car, or your bike. The important question isn’t who hosts the app; it’s whose sphere of control the app and its data belong to.
Figure 1 shows how most apps work today. The app and the data about you sit inside the provider’s sphere of control, and you reach both through the provider. You use the app, but the provider decides what it does, what happens to your data, and how long either one exists.
Figure 2 shows a better model. The app and the data sit inside your sphere of control, and the company that used to be the provider becomes a partner that works with your data on terms you set, labeled “my terms“ in the figure. The components in the two figures are nearly identical. What changes is who’s in charge.
I first imagined the arrangement in Figure 2 in the area of IoT, where every connected thing could have its own app under its owner’s control rather than its manufacturer’s. That was hard to realize when every app had to be built and maintained by someone with a business reason to do it. AI changes the calculation. As I wrote in There’s a Personal App for That, building a custom app for a single person or organization is now a morning’s work. When apps are that cheap to make, software stops looking like a few products with millions of users and starts looking like a billion small markets. Those apps need somewhere to live that the person controls, and they need to be able to move.
Identity Is the Foundation
Portability sounds like a storage problem: export the data and import it somewhere else. The hard part is everything that points at the thing you moved. A pico does its work through relationships with other picos, and if moving it breaks every relationship that refers to its old address, the pico hasn’t really moved; it has been orphaned. Identity is what lets the rest of the world still recognize something that has moved.
That’s why some of the recent pico engine work focused on pico-to-pico identity. Each pico carries two kinds of DIDs, and they do different jobs in a move. The did:webvh is the pico’s public identity, the passport it hands to strangers. Its self-certifying identifier (SCID) survives a move; only the host and path change, and anyone who resolves the DID finds the pico at its new location.
Relationships ride on something else. Each relationship is based on a pair of did:peeridentifiers, private, point-to-point names with no engine address baked into them. The picos use them to exchange messages using DIDComm. After a move, the pico sends a rotation message to each of its peers, and each peer updates where it sends traffic for that relationship. Nothing has to be reintroduced; the did:webvh keeps the pico findable, and the peer DIDs keep its relationships intact. In the demo, four things move together:
The subtree — the bike pico and its children export as a portable blob and import on the new engine. This isn’t federation of whole engines; it’s one subtree changing hands.
The identity — the SCID stays the same while the DID’s host and path follow the engine.
The relationships — they’re kept whole, even when that means converting a local ECI-based relationship into a DID-based one.
The app — the application and all its data move from one sphere of control to another.
The last item is the point the demo is trying to make. The new owner doesn’t get a data export from the club’s system; they get the bike’s pico, with its functionality, history, and relationships, running in their own mesh.
Identity Enables Autonomy
A personal app needs more than code; it needs a place to keep its state, a way to talk with the people, devices, and services it works with, and an identity those parties can rely on. Picos package all of that together. The name itself is short for “persistent compute object” and that’s been the goal for as long as picos have existed.
Each pico persists its own logic and data, responds to events from anywhere on the internet, and carries its relationships with it. Because the whole package travels as a unit, moving a personal app from one host to another becomes an operation rather than a rewrite. The host provides a place to run; the pico is the app.
Selling a bike is one reason to move a pico, but there are many others:
Resilience — leave a host that fails, turns hostile, or censors.
Economics — find cheaper compute or storage.
Latency — get closer to the people, devices, and other picos it works with.
Bandwidth — move toward the data instead of hauling it across the network.
Jurisdiction — live on infrastructure with the right governance and data-handling rules.
Ownership — follow a sale, or simply avoid lock-in.
Today, a person or a program acting for them decides when a pico moves. And does the exporting and importing by hand. What I ultimately want is for a pico to move itself on command and, eventually, on its own judgment, weighing cost, latency, reliability, and trust to decide where it should live. Getting there takes more work. Moves need to be atomic, with rollback when something fails halfway and forwarding from the old location; the engine needs to transfer exports and clean up the donor rather than leaving those jobs to the operator; and we need far more testing against relationships that cross subtree boundaries and external systems that remember old addresses. I expect the sharp edges to show up as soon as people use this for something other than my demo.
Picos are persistent objects with their own identities and relationships, not session tokens issued by whatever app happens to host them. That distinction is what makes everything else possible. An app whose identity belongs to its host can only live where it’s told. A pico with its own identity can choose where it lives, just like the person it works for. Identity enables autonomy.
Photo Credit: A pico comes home to its owner from ChatGPT (public domain)
I completely agree with all of the principles and motives and the idea of a personal control sphere that you can move to any host.
I have a personal agent running on Digital Ocean under a domain that I own. If I move the agent to another host, I can test it and then shift the DNS entry to point to it. No DIDs are involved. What am I missing?