真正的用户自主权：自由选择，平滑迁移

数字时代，用户真正的自主权是什么？

是把服务器搬回家？是在设置里找到一个“导出数据”的按钮？还是不用换掉自己的身份、放弃过去的积累，就能选择另一家服务？

我认为，真正的用户自主权，是自由选择，也能平滑迁移。 你可以把数据和应用放在别人那里，也可以放在自己这里，还可以按需要组合使用。“平滑”讲的是改变这些选择时，自己的关系和日常使用能够接续，而不是拿到一包文件以后，一切靠自己重新建立。

这里说的迁移，比“把数据 export 出来”多得多。导出一份文件，如果新服务读不了，应用用不了，原有的权限不被识别，别人也找不到你，那只是带走了一份副本。真正的自由迁移，是位置和服务可以改变，身份、数据与使用体验仍然连续。 你的资料放在哪里，不应该决定它用起来是否方便。

我们要从三个角度把这件事做完整。身份这一层，你仍然是同一个人，原来的关系和授权可以延续，别人也能通过稳定的标识找到你。数据这一层，你的资料、个人记录，以及数字资产的归属和访问授权仍在你的控制之下，并且能继续被应用使用。计算这一层，你可以替换运行应用、执行任务的机器或服务，而不必连身份和数据一起重建。

“别人怎么找到你”也属于迁移体验。你的 naming，也就是别人认识和寻找你所用的名字或标识，不应该因为换了一台服务器，就被迫变成一个新的账号或新的联系方式。稳定的身份需要能指向新的服务位置；用户搬走，关系也应该能跟着走。

这是我希望 Arc Space 正式推出之前先讲清楚的判断。Self-host 是自己运行服务；self-sovereign，自我主权，是由你决定使用谁的服务，并保留改变选择的能力。自己运行是一种选择，使用托管也是一种选择。自由的关键，是这两个选择之间有一条容易走的路。

所以我们把 Arc ID、Arc Space 和 ARC 分开设计。身份决定谁有权，数据保存你积累的一切，计算负责替你做事。让迁移不打断使用，是我们要兑现的产品标准；协议支持这条路，还需要部署、寻址、同步和恢复共同把它做成真实体验。

用户嫌麻烦，不等于用户不想拥有

经常有人说，用户不 care 隐私，也不关心数据归谁，只要好用就行。我觉得，这个判断把一种妥协当成了偏好。

用户的确会为了方便使用中心化服务。但过去，想自己掌握数据，往往意味着学会部署、备份、升级，还得处理各种自己根本不懂的故障。操作太麻烦，承担的成本也高。一个人在这些条件下放弃控制权，不能说明当便利程度相近时，他依然不想要。

住房就是一个容易理解的类比。我相信，如果拥有自己的住处是可负担、可管理的选择，几乎每个人都会希望居者有其屋。这是我的判断，不是一个人口调查的结论。有人租房，有人住酒店，这些选择当然有各自的理由，但不能据此推导出人们不想有自己的家。

有自己的房子，也不妨碍请物业维护，出差住酒店，或者到另一个城市租房。拥有和使用服务，本来就可以共存。自由还包含另一层意思：你有迁徙的权利，可以选择住在哪里、接受谁的服务。一个人不应该因为离开某个住处，就失去自己的身份和过去积累的一切。

数字生活也应该如此。我们要解决的问题，是让拥有不再那么麻烦，让用户不用在“方便”和“属于自己”之间做那么大的妥协。

Local-first 正是在重新提出这个问题。2019 年，Martin Kleppmann 等人在 Ink & Switch 的论文 Local-first software^[1]里讨论了如何同时保留本地软件的掌控感和云服务的协作便利。用户手里的数据副本应当能支持工作，断网也能继续使用，联网后再与其他设备或协作者同步。云可以提供服务，却不必成为每次访问自己资料都要经过的关卡。

Automerge^[2]已经把多份数据副本的合并做成开发基础设施，2024 年和 2025 年的 Local-First Conf^[3][4]也说明这个方向正在形成持续的开发活动。Self-host 则有更早的历史：第一个网站运行在 Tim Berners-Lee 在 CERN 使用的 NeXT 计算机^[5]上。专业托管后来接过了大量运行工作，近年家庭 NAS、小型主机和本地软件又让自己运行服务受到关注。Home Assistant 在 2025 年报告了超过两百万个活跃安装^[6]，就是一个具体例子。

更好的宽带，以及 Tailscale 这样的远程连接工具^[7]，降低了连接自己设备的门槛。但连得上，仍不等于维护起来容易。Local-first 可以由软件替用户处理复杂性，self-host 却常常还要用户自己承担运维。它们都是重要的进展；接下来更值得问的是：即使用别人的服务，我还能不能保留自己的控制权？

手机可以换，身份和数据应该留下

你可能已经换过好几代 iPhone。手机变了，照片还是你的，联系人还是你的，你也希望保留原来的电话号码。

当然，电话号码依赖运营商，照片迁移也依赖具体工具。这里借用的是一个很清楚的关系：我们愿意替换设备，却不愿意每换一台设备，就重新成为一个人、重新积累一遍自己的生活。

计算机、服务器和运行应用的环境，也应该遵循这个关系。机器的性能、可靠性和安全性很重要，但机器是替你工作的。它不应该决定你是谁，也不应该成为你失去它就失去一切的原因。

Arc ID：身份在前，服务在后

身份为什么排在最前面？因为系统要先知道谁有权，才能判断谁可以访问数据、谁可以授权应用。文件还在，并不表示你一定有权读它；账号被停用之后，存在平台上的资料也可能变得无法访问。

如果身份只能由一家平台发放，那么换服务就可能意味着换账号，再把原有的权限和关系重新建立一遍。邮箱也有类似的依赖：即使你有自己的域名，域名注册和邮件服务仍分别由其他系统提供。

DID，去中心化标识符，给了我们另一条路径。采用用户持有密钥的自认证 DID 时，你可以自己产生标识，并用自己的密钥证明对它的控制。验证方依据公开规则核验，不必让原服务商重新给你发一个账号。ArcBlock 的 DID 体系延续的就是这个思路：身份控制权应当由用户掌握，服务围绕这个身份工作。

自己掌握身份也意味着要处理密钥的安全和恢复。W3C 的 DID 标准^[8]允许不同方法，各有创建、解析和控制规则；DID 不能被笼统理解成永远不会丢、不会被盗。自认证证明你控制这个标识，学历、任职等现实属性仍需要相应机构的证明。Arc ID 要做的，是把身份管理做得容易理解，而不是要求每个人先学会密码学。

身份标识和服务地址也要分开。DID 不必随机器更换，但应用仍需知道该去哪里访问服务，这需要相应的解析和寻址机制。人们使用的易读名称，又有各自的命名规则；并不是有了 DID，所有域名和用户名就自动归你控制。我们要保留的是关系的连续性：更换服务位置时，能更新访问位置，让原来的标识仍然有用。

Arc Space：数据是你积累的东西

身份解决“谁有权”，数据则是这个人长期积累下来的东西。照片、联系人、作品和个人记录是数据；许多数字资产的归属与授权，也以数据形式记录。迁移存储并不等于搬动一条链上的资产；需要保留的是你对它的控制，以及应用识别和使用它的路径。讨论数据掌控时，不能只把它当成几份可以重新下载的文件。

Crypto 已经让很多人认识到这一点。把资产放在中心化交易所，由交易所保管相关私钥，操作可能更方便，但自己看到的余额和实际控制的对象之间，多了一个服务商。“Not your keys, not your coins”

（译：私钥不归你掌握，币也不归你控制。）

这句话提醒的是这层区别。DeFi，也就是通过区块链上的程序提供金融操作，同样不能自动消除所有依赖。Wrapped token 可以理解成代表另一项资产的凭证；自己签名持有凭证，不表示它代表的底层对象也都由自己控制。WETH^[9]和依赖验证者或托管安排的跨链包装资产^[10]有不同的控制结构，不能混为一谈。凭证再包装凭证，只会让用户更难看清自己究竟掌握了什么。

回到个人软件，只有“导出”还不够。你带走文件之后，能不能继续使用？换到另一个服务，原来的身份和授权关系还能不能被识别？这才决定了迁移是不是一条真正可走的路。

Arc Space 从 DID Space演进而来。我们把数据所属的用户身份、应用访问数据的接口，以及数据所在的存储位置分开处理。Arc 当前已有本地和云端存储后端，通过同一套 AFS（Agentic File System）接口提供数据。这让按接口开发的应用可以减少对某个具体存储实例的依赖。

这里保持的是用户身份的连续性，不是说所有服务器都变成同一个实例。数据还需要复制，权限还需要核验，应用找到数据的地址还需要更新。我们要让这些工作由协议和产品承担，减少用户切换服务时需要自己理解和操作的部分。

ARC：计算可以替换，积累不必重来

ARC 是运行应用的计算环境。它负责执行任务，使用用户授权的数据。计算的迁移需要处理应用、配置与外部依赖；正在执行的任务也有自己的状态。复制数据不是把这些事情都做完了，产品需要让替换运行环境之后的工作能够继续，而不是留给用户重新拼装。身份和数据与计算分开以后，你才能根据需要更换机器、运行环境或服务商，而不是每换一次计算服务，就连自己的数字生活一起重建。

这个顺序很重要：先有自己控制的身份，再有归这个身份掌控的数据，然后选择在哪里计算。日常使用时，用户不必每次都看到这三层；产品需要把它们分开，才能让更换其中一层时，另外两层不被迫跟着改变。

所以，自我主权最先需要保护的，是身份和数据。计算可以租，可以换，也可以自己运行。它的重要性在于服务你，而不是把你留在原地。

为什么我们也提供托管服务？

既然强调自己拥有，为什么 Arc Space 和 ARC 还可以由我们提供服务？

因为让普通人容易开始使用，本来就是我们要解决的问题。托管服务可以替用户处理部署、在线运行和维护。如果只有自己装一套才算拥有，我们就又把同一道门槛放回去了。

我们想提供接近云服务的便利，同时让身份和数据在协议层能够迁移。区别应当落在这里：你选择这家服务，是因为它适合你；想更换时，自己的身份和资料仍能继续使用。

也不需要把选择变成一场彻底搬家。我们希望用户可以先在自己的设备保留副本，再决定哪些工作留给托管服务；可以按需要组合自有和托管实例，让它们同步，或让多个独立服务按共同协议协作。这种独立服务之间的协作，就是我们所说的 federation。自己运行、由别人运行，以及两者混用，都应该是正常的产品选择。

住房的类比在这里需要补一句：数据可以复制，房子不能。复制之后，两边同时修改如何处理，授权如何保持一致，应用怎样找到新的数据地址，都需要实际机制。DID 提供身份的连续性，却不会替我们自动完成全部迁移。

当前实现已有本地与云端后端、快照和增量同步机制，也有导出与导入路径；这些能力在不同平台上的接入程度并不相同。它们不等于任意托管商之间已经可以一键切换。我们要把部署、同步和迁移做成普通人也能使用的体验，具体可用组合以 Arc Space 正式推出时的产品说明为准。

这个方向不能只对第三方成立。我们自己提供的服务也必须接受同样的要求：用户可以从这里开始，但不应因此只能留在这里。提供便利，以及保留离开的权利，是我们需要同时兑现的两件事。

几个关于用户自主权的迷思

“我自己运行服务器，所以已经自主了”

Self-host 给了你运行机器的控制权。可如果登录身份仍由另一家平台发放，应用仍必须通过它才能识别你，或者别人联系你的地址仍随它的账号一起失效，你只掌握了其中一层。

反过来，使用托管服务也不能直接等同于放弃自主权。更值得追问的是：能不能保持身份和关系，更换存储与运行服务？拿“机器放在哪里”替代这个问题，会把真正的依赖藏起来。

“数据能导出，你就已经自由了”

Google Takeout 可以导出 Gmail 的邮件资料^[11]，这当然有价值。你可以备份旧邮件，也可以把它们导入其他工具。但拿到邮件文件，不会让另一家邮件服务获得替你运营原来 @gmail.com 地址的能力。

你仍可以保留 Gmail 账号，或设置自动转发^[12]，让旧地址收到的信转到新邮箱。联系人并不会因为你按了 export 就立刻找不到你。问题在于，继续通过旧地址联系你的这条路，仍依赖 Google 的邮件服务；归档带走了，地址却没有随你独立迁移。

这就像搬家时把家具都运走了，但所有人仍只能把信寄到原来的门口。可以打包行李是一种能力，搬走之后仍能被找到、正常生活，是另一种能力。

“号码能跟着我，是运营商给的方便”

电话号码提供了一个更有意思的对照。美国的号码携带，并不只靠运营商愿意帮忙。1996 年《电信法》^[13]在第 251(b)(2) 条规定，本地电话运营商须按 FCC 的规则，在技术可行范围内提供号码携带。它对号码携带的定义也不只要求“保留号码”，还包括在同一地点更换运营商时，不损害服务质量、可靠性或便利程度。

移动号码携带随后通过 FCC 规则分阶段落实。2003 年 11 月 24 日，美国最大的 100 个都市统计区开始实施相关无线号码携带要求；当日加州公共事业委员会的公告^[14]明确告诉用户，可以更换服务商并保留号码。这不是 1996 年立法之后第二天就全国自动实现，也不是用户获得了号码的无限产权，而是运营商受到约束，不能把换号码当成所有更换服务的必经代价。

这恰好说明了我说的“平滑”。用户关心的不是把一串数字写在纸上带走，而是换了服务，别人照常拨这个号码，仍然能找到自己。号码、服务商和服务位置，需要能被分开处理。

数字时代的自主权也需要这种制度意识。数据可携带、身份或地址可继续使用，是不同的权利，不能用一个 export 按钮替代全部。协议和产品可以提供迁移路径，法律可以规定服务商必须配合什么、不得设置哪些障碍；技术上的自认证身份，也不能替代争议处理与权利保障。

“用户嫌麻烦，所以自主权不重要”

嫌麻烦只能说明现有门槛太高，不能证明用户希望永远被绑定。如果更换服务比留下来难得多，用户没有搬走，也不足以证明留下来是自由选择。更换服务的成本本身，可能就在替用户做决定。

也不需要等每个人都真的搬一次家，迁移能力才有意义。即使你一直愿意使用同一家服务，知道自己可以带着身份和积累离开，与因为离不开而留下，是两种完全不同的关系。我们要让这份选择变得可行，AI Agent 则给了我们降低门槛的新机会。

Arc ID 与 DID、Arc Space 与 DID Space 是什么关系？

这里也需要把品牌和协议分开。DID 是去中心化身份的协议与标准；Arc ID 是我们面向用户提供的身份产品与服务品牌，底层使用 DID。DID Space 是数据空间的底层协议；Arc Space 则是我们基于这个协议提供的产品与服务品牌。以 Arc 开头的这些名字，是 ArcBlock 自己的品牌，并不意味着底层协议也只能由我们提供服务。

简单来说，Arc ID 使用 DID，Arc Space 使用 DID Space，ARC 提供运行计算的环境。 产品品牌帮助用户理解和使用服务，协议则定义身份与数据如何被识别、访问和迁移。理解这层区别，就不会把“使用我们的产品”与“身份和数据必须留在我们的服务里”混为一谈。

AI Agent 降低了门槛，也让主权更重要

AI Agent 对这件事有两种作用：它有机会让自己掌控变得更容易，也让失去掌控的代价变得更大。

过去，一个人想 self-host，可能得先学一堆部署知识；想安全地 self-custody，又得理解密钥、备份和授权。很多人还没开始，就被陌生的词和看起来可怕的操作劝退了。现在，Agent 可以按你眼前的问题解释原理，查阅文档，在获得授权后协助配置，并检查结果。像 Claude Code 的官方实践文档^[15]，已经把读取文件、执行操作和验证结果放进同一个工作过程。

我觉得，这是一种知识的民主化。过去需要找到专家、自己消化大量资料才能得到的帮助，现在有机会在需要的时候获得。用户不必把所有细节都学完才开始；可以先理解自己要做什么、为什么这样做，再让 Agent 协助完成。Local-first 的开发和 self-host 的维护，也有机会因此走出更小的技术圈子。

安全知识同样如此。Agent 可以帮助解释备份与恢复的区别，核对官方操作说明，提醒用户检查可疑网址或授权请求。比如钱包恢复时需要在可信的钱包里输入恢复短语，和一个所谓客服网站要求你填写恢复短语，看起来都在“输入一串词”，控制关系却完全不同。MetaMask 的官方说明^[16]明确要求，不要把恢复短语或私钥交给他人。Agent 的帮助应当围绕理解这些区别，而不是让用户把秘密贴进对话，换取一句“我替你看看”。

这也不等于 Agent 的每个判断都可靠，或者使用它就能避免钓鱼。它的操作仍需要明确的授权边界和可以核验的结果。但我认为，随时可获得的解释和协助，会大幅降低过去依靠个人知识才能跨过的门槛。拥有不再必须以成为极客为前提。

门槛降低的同时，值得自己掌控的东西也更多了。

你会尝试不同的模型、不同的 Agent，也会更换服务。今天某个模型更适合写作，明天另一个 Agent 更适合处理工作，这些都很正常。执行任务的能力在变化，而你积累的个人历史不应该随着每次选择重新归零。

Agent 的 memory 看起来是软件的一项功能，其实里面可能包含你的偏好、长期目标、工作策略，以及它和你一起形成的记录。这些东西来自你的生活和工作。若它们只能留在某个 Agent 服务的 silo 里，用得越久，更换服务就越难。搬走几份聊天记录，也不等于已经带走这些积累。

把这件事放回 Arc 的三层里，就容易理解了：Arc ID 用来确认你的身份和授予权限；Arc Space 承载你自己的数据，包括你选择保存的记忆与策略；ARC 提供执行环境，让获得授权的 Agent 来做事。Agent 更换时，应该改变的是为你工作的工具，而不是你这个人及其全部积累。

这也不意味着任何 Agent 都能直接读取另一种 Agent 的全部内部状态。模型和应用仍有各自的数据格式与处理方式，需要相应的接口或转换。更基础的要求是，值得长期保留的用户数据不应只有某一家服务才能解释和使用；授权一个 Agent 访问，也不应等于把资料的最终控制权交给它。

我希望 Arc Space 正式推出之前，大家理解我们为什么这样分层。我们并不要求所有人都自己运行所有东西。我们想让身份由你掌握，让数据能跟着你，让计算和 Agent 成为你可以选择、更换的服务。

真正的用户自主权，应该让你自由选择，也能平滑迁移。 Agent 有机会让这种掌控更容易，也让它更加必要。今天愿意托管，明天想自己运行，或者始终把两者组合使用，都不应该让你变成另一个人，也不应该让你丢掉原来的积累。身份和数据由你掌握，是为了让它们能跟着你走。我们要把部署、同步和迁移做得容易，让你可以选择留在哪里，也可以改变选择。

参考