Real user sovereignty: freedom to choose, freedom to move

What does real user sovereignty mean in the digital world?

Bringing a server home? Finding an export button in settings? Or choosing another service without replacing your identity and giving up everything you have built up?

I believe real user sovereignty means freedom to choose, with continuity when you move. Your data and applications can live with a provider, on your own system, or in a combination of both. Continuity means that relationships and everyday use survive a change of service. It should mean more than receiving an archive and being left to reconstruct everything yourself.

Moving means more than exporting data. If another service cannot read the files, applications cannot use them, permissions are no longer recognized and people cannot find you, you have taken away a copy. Freedom to move means that locations and services can change while identity, data and use remain continuous. Where your records live should not determine how convenient they are to use.

We need to address three parts. At the identity layer, you remain the same person: relationships and authorizations can continue, and others can find you through a stable identifier. At the data layer, your files, personal records, and control of digital assets and access permissions remain yours and usable by applications. At the compute layer, you can replace the machine or service that runs applications and tasks without rebuilding identity and data along with it.

How others find you is part of this experience too. Naming, the name or identifier people use to recognize and reach you, should not force a new account or contact address on you every time you replace a server. A stable identity needs a way to point to a new service location. When you move, your relationships should be able to come with you.

Before Arc Space formally launches, I want to make this distinction clear. Self-hosting means running a service yourself. Self-sovereignty means deciding whose services to use and retaining the ability to change that choice. Self-hosting and professional hosting are both choices. Freedom requires an easy path between them.

That is why we separate Arc ID, Arc Space and ARC. Identity establishes authority. Data preserves what you have accumulated. Compute does the work. Moving without disrupting use is the product standard we want to meet. Protocol support needs deployment, addressing, synchronization and recovery to turn that standard into an actual experience.

Choosing convenience doesn't mean rejecting ownership

People often say users don't care about privacy or who owns their data. They just want something that works. I think that confuses a compromise with a preference.

Users do choose centralized services for convenience. But keeping control has often meant learning deployment, backups and upgrades, then fixing problems they don't understand. It takes time and money. Giving up control under those conditions does not tell us what people would choose if ownership were just as easy.

Housing is a useful comparison. I believe that, given an affordable home they can manage, almost everyone would like a place of their own. That is my judgment, not a demographic finding. People rent or stay in hotels for good reasons. Those choices don't establish that they wouldn't want their own home.

Owning a home doesn't stop you from hiring someone to maintain it, staying in a hotel on a trip or renting in another city. Ownership and services can coexist. Freedom also includes being able to move, choose where to live and choose whose services to use. Leaving a residence should not cost you your identity and everything you have accumulated.

Digital life should work that way too. The problem we want to solve is making ownership easy enough that people face less of a trade-off between convenience and control.

Local-first software asks a related question. In the 2019 Ink & Switch paper Local-first software^[1], Martin Kleppmann and his coauthors examined how to combine the control of local software with the collaboration offered by cloud services. A user's own data copy should support their work, including offline work, and synchronize with other devices or collaborators when connectivity returns. The cloud can help without becoming a gate that must open every time you want your own files.

Automerge^[2] provides infrastructure for merging data replicas. Local-First Conf in 2024^[3] and its 2025 program^[4] show sustained developer activity around the idea. Self-hosting has an older history: the first website ran on Tim Berners-Lee's NeXT computer at CERN^[5]. Professional hosting later took over much of the operational work. Home NAS devices, small computers and locally run software have brought renewed attention to running services yourself. Home Assistant reported more than two million active installations in 2025^[6], one concrete example.

Better broadband and remote networking tools such as Tailscale^[7] make reaching your devices easier. Maintaining them is another question. Local-first software can hide its complexity from users; self-hosting often leaves operations in their hands. Both are useful advances. The next question is whether you can keep control while using someone else's service.

Replace the phone. Keep the person and the data.

You may have replaced your iPhone several times. The device changes. Your photos and contacts remain yours, and you want to keep your phone number.

Phone numbers depend on carriers, and moving photos requires actual tools. The relationship is what matters here: we accept replacing a device. We don't accept becoming a new person and rebuilding our lives every time we do.

Computers, servers and application environments should follow the same principle. Their performance, reliability and security matter. But they work for you. They should not determine who you are or become the thing you must keep to avoid losing everything else.

Arc ID: identity comes before the service

Why put identity first? A system must establish who has authority before deciding who can access data or authorize an application. The files may still exist while you can no longer reach them, for example when the platform account used to access them is suspended.

If one platform alone issues your identity, changing services may mean getting a new account and rebuilding your permissions and relationships. Email has related dependencies. Even with your own domain, domain registration and mail service involve other systems.

DIDs, decentralized identifiers, offer another path. With a self-certifying DID whose keys you hold, you can generate an identifier and prove control using those keys. A verifier checks it according to public rules, without needing your original provider to issue a replacement account. This is the thinking behind ArcBlock's DID system: the user should control the identity, and services should work around it.

Controlling identity also requires key security and recovery. The W3C DID standard^[8] allows different methods with different creation, resolution and control rules. A DID is not a blanket guarantee against loss or theft. Self-certification proves control of an identifier; education, employment and other real-world attributes still need relevant issuers. Arc ID should make identity management understandable without requiring everyone to study cryptography.

An identity identifier and a service address must also be separate. A DID need not change with a machine, but applications still need to locate the service through resolution and addressing mechanisms. Human-readable names have their own rules; a DID does not automatically give you control of every domain or username. We want continuity of relationships: changing the service location should allow its address to be updated while the original identifier remains useful.

Arc Space: data is what you have built up

Identity establishes authority. Data preserves what a person accumulates over time. Photos, contacts, work and personal records are data. Ownership and authorization for many digital assets are also recorded as data. Moving storage does not move an asset on a blockchain. What must remain is your control of it and the means for applications to recognize and use it. Control of data is about more than a few replaceable downloads.

Crypto made this distinction explicit. A centralized exchange holds assets and manages the relevant private keys on your behalf. It can make operations convenient, but puts a provider between the balance you see and the underlying object you control. “Not your keys, not your coins” points to that difference. DeFi, which uses blockchain programs to perform financial operations, does not automatically remove every dependency either. A wrapped token represents another asset. Signing for that token does not necessarily give you direct control of what it represents. WETH^[9] and cross-chain assets^[10] that depend on validators or custody arrangements have different control structures. Treating them alike obscures the question. Wrapping one claim in another makes it harder to see what you actually hold.

For personal software, an export button is only part of the answer. Can you keep using the files after taking them away? Will another service recognize your identity and permissions? Those questions determine whether moving is practical.

Arc Space evolves from DID Space. We separate the user's identity, the interface applications use to access data, and the storage location. Arc already has local and cloud storage backends exposed through the same AFS, Agentic File System, interface. Applications built against that interface can reduce their dependence on a particular storage instance.

The continuity is in the user's identity. It does not make all servers the same instance. Data still has to be copied, permissions checked and the addresses applications use to find data updated. We want the protocol and product to handle this work so users have less to understand and manage when changing services.

ARC: change the compute without starting over

ARC is the environment that runs applications. It executes tasks using data the user authorizes. Moving compute also involves applications, configuration and external dependencies. Running tasks have their own state. Copying data alone does not address all of that; the product needs to let work continue after a change of environment without leaving users to reconstruct everything. Separating identity and data from compute is what makes it possible to choose another machine, runtime or provider without rebuilding your digital life around each new service.

The order matters: an identity you control, data governed by that identity, then a choice of where work runs. Users need not see these layers every day. The product must separate them so changing one does not force the others to change too.

Self-sovereignty should protect identity and data first. Compute can be rented, replaced or run yourself. Its role is to serve you, rather than make you stay.

Why offer hosted services ourselves?

If we emphasize ownership, why can Arc Space and ARC also be services we provide?

Because making it easy for ordinary people to get started is part of the problem we are solving. Hosting can handle deployment, availability and maintenance. Requiring everyone to install their own system would put the same barrier back in place.

We want the ease of cloud services with identity and data that are portable at the protocol layer. You should choose a provider because it suits you. When that changes, your identity and records should remain usable.

Nor should the choice demand a complete move all at once. We want users to be able to keep a copy on their own device first, then decide which work remains hosted. Combining self-managed and hosted instances, synchronizing them, or having independent services cooperate through shared protocols is the direction behind federation. Self-hosting, hosting by others and a mixture of both should be ordinary product choices.

The housing comparison has a limit: data can be copied; houses cannot. Copies introduce questions about simultaneous changes, consistent permissions and finding the new data location. These require actual mechanisms. A DID provides identity continuity, not automatic migration of everything around it.

The current implementation includes local and cloud backends, snapshot and incremental synchronization mechanisms, and export/import paths. Their integration differs across platforms. That does not establish one-click switching between arbitrary hosting providers. We want deployment, synchronization and migration to be usable by ordinary people; the combinations available at launch must be described in Arc Space's product documentation.

This requirement must apply to our own service too. People should be able to start here without being obliged to stay here. Convenience and a practical right to leave are both things we need to deliver.

A few myths about user sovereignty

“I run my own server, so I already have sovereignty”

Self-hosting gives you control over the machine. But if another platform still issues the identity used to log in, applications need that platform to recognize you, or your contact address disappears with its account, you control one layer.

The reverse assumption is just as weak: using a hosted service does not automatically mean giving up sovereignty. Ask whether you can keep your identity and relationships while changing storage and compute providers. Focusing solely on where the machine sits hides the remaining dependencies.

“You can export your data, so you are already free”

Google Takeout can export Gmail records^[11]. That is useful. It lets you back up old messages and bring them into other tools. It does not give another mail provider the ability to operate your original @gmail.com address.

You can keep the Gmail account or set up forwarding^[12] to a new inbox. Exporting does not suddenly make you unreachable. The limitation is that reaching you through the old address still depends on Google's mail service. The archive can leave; the address has not independently moved with you.

It is like moving your furniture while everyone must still send letters to the old doorstep. Packing your belongings is one capability. Remaining reachable and carrying on with life after moving is another.

“Keeping my phone number is just a carrier convenience”

Phone numbers offer a more interesting comparison. In the United States, portability is not simply a favor from carriers. The Telecommunications Act of 1996^[13] added Section 251(b)(2), requiring local exchange carriers to provide number portability under FCC rules to the extent technically feasible. Its definition went beyond retaining digits: at the same location, switching carriers should preserve service quality, reliability and convenience.

Wireless portability followed through phased FCC implementation. Requirements began in the 100 largest metropolitan statistical areas on November 24, 2003. A California Public Utilities Commission announcement that day^[14] told consumers they could change providers and keep their number. Nationwide portability did not appear overnight after the 1996 law, and users did not gain an unlimited property right in numbers. Carriers were constrained from making a new number the inevitable cost of every change of service.

That captures the continuity I mean. A user wants more than a string of digits written on paper. After changing service, other people should still be able to dial that number and reach them. Number, provider and service location need to be treated separately.

Digital sovereignty also needs this institutional perspective. Data portability and continued use of an identity or address are different rights; an export button cannot stand in for all of them. Protocols and products can provide migration paths. Law can define what providers must cooperate with and which obstacles they may not impose. Self-certifying identity does not replace dispute resolution or legal protection.

“Users dislike the effort, so sovereignty doesn't matter”

Disliking the effort tells us the barrier is high. It does not show that people want permanent dependence. If moving is far harder than staying, the fact that users have not moved is not enough to establish free choice. The switching cost may already be making the decision for them.

Nor does everyone have to move before portability matters. Willingly staying with a service, knowing your identity and accumulated records can leave with you, is a different relationship from staying because you cannot leave. We want that choice to be practical. AI agents offer a new way to lower the barrier.

How do Arc ID and Arc Space relate to DID and DID Space?

The names distinguish product brands from the protocols underneath. DID is a protocol and standard for decentralized identity. Arc ID is our user-facing identity product and service brand, built on DID. DID Space is the underlying data-space protocol; Arc Space is our product and service brand built on that protocol. The Arc names belong to ArcBlock's own brands. They do not mean that only ArcBlock can provide services using the underlying protocols.

Arc ID uses DID. Arc Space uses DID Space. ARC provides the computing environment. The brands help people understand and use the services; the protocols define how identity and data are recognized, accessed and moved. Using our products should not be confused with requiring your identity and data to stay in our hosted services.

AI agents lower the barrier and raise the stakes

AI agents affect this in two ways. They can make control easier to exercise, while making the cost of losing it greater.

Self-hosting used to require learning a considerable amount about deployment. Safe self-custody meant understanding keys, backups and authorization. Unfamiliar terminology and intimidating operations stopped many people before they started. An agent can now explain the problem in front of you, consult documentation, help configure a system with permission, and check the result. The official Claude Code practices^[15], for example, bring reading files, taking action and verifying work into the same process.

I see this as a democratization of knowledge. Help that once required finding an expert and absorbing extensive documentation can become available when it is needed. Users need not learn every detail before starting. They can understand what they want to do and why, then get help doing it. That could also bring local-first development and self-hosted maintenance within reach of more people.

Security knowledge can work the same way. An agent can explain backup versus recovery, check official instructions, and help a user examine suspicious addresses or authorization requests. Entering a recovery phrase into a trusted wallet during recovery and entering it into a supposed support website may look similar. The difference in control is enormous. MetaMask's official guidance^[16] says not to share recovery phrases or private keys with others. Help should make that distinction understandable, without asking users to paste secrets into a conversation for inspection.

An agent is not always right, and using one does not guarantee protection from phishing. Its actions still need clear permission boundaries and verifiable results. But I believe readily available explanation and assistance can substantially lower a barrier that previously depended on personal expertise. Ownership need not require becoming a technical enthusiast.

As that barrier falls, people also have more worth controlling.

You will try different models, agents and services. One model may suit your writing today; another agent may handle your work better tomorrow. The tools change. Your personal history should not reset with every choice.

An agent's memory looks like a software feature, but may contain your preferences, long-term goals, working strategies and records developed through working together. These come from your life and work. If they can exist only in one agent service's silo, changing services becomes harder the longer you use it. Downloading chat logs does not necessarily preserve everything you have built up.

Arc's three layers make the intended relationship clear. Arc ID establishes your identity and permissions. Arc Space holds your data, including the memory and strategies you choose to preserve. ARC provides an execution environment where authorized agents work. Replacing an agent should change the tool working for you, without replacing you or erasing your accumulated history.

This does not mean every agent can directly read another agent's entire internal state. Models and applications have their own formats and processing methods, requiring interfaces or conversion. The more basic requirement is that personal data worth keeping should not depend on a single service to remain interpretable and usable. Authorizing an agent to access it should not transfer ultimate control to that agent.

Before Arc Space launches, I want people to understand why we separate these layers. We do not require everyone to operate everything themselves. We want people to control their identity, keep their data with them and choose the compute and agents that serve them.

Real user sovereignty should mean freedom to choose, with continuity when you move. Agents can make that control easier to exercise and more necessary. Hosting today, running your own system tomorrow, or combining the two should not make you become someone else or lose what you have built up. Control of identity and data should let them travel with you. We want deployment, synchronization and migration to be easy enough that you can choose where to stay and change your choice.

References