我们为什么做 Aside
我们曾把多年的书签、笔记和阅读清单交给一些很喜欢的产品，然后一次次看着它们关闭、易主或改变规则。这就是我们为什么做 Aside。
把分享的方向，转回你自己的地方。
Aside 是 ArcBlock 在 ARC（Agentic Realm Computer） 上构建的第一个面向普通用户的移动产品。它从 Apple iPhone 上一个很小、很熟悉的动作开始：看到值得留下的东西，点一下 Share，存进自己的地方。
第一版已经可以在 App Store 下载。当前发布的是 iOS 版本；Android、Web、桌面端和浏览器扩展会在后续逐步推出。它也是一次实际检验：一个应用团队能否借助 ARC 和 AI code agents，把产品从想法带到过去并不熟悉的移动平台。
这听起来像 bookmark，也像 note，的确不是一个新问题。真正一直没有解决好的，也不是“怎样收藏一个链接”，而是这些内容收进去以后属于谁，服务消失以后还剩下什么，以及零散的收藏能不能慢慢长成自己的东西。
好工具会消失，数据不该跟着消失
这些年，我也做过 KnowledgePoint、NeoPapr、Personal Site Framework、Slicel、CrossCourse 和 Mood Journal 等不同尝试。名字和年份并不重要。它们只是说明，我和许多人一样，反复遇到一个很普通的问题：找到一个喜欢的工具，把几年内容认真放进去，然后发现产品的生命周期从来不属于用户。
我们其实从来不缺优秀的收藏、稍后阅读和知识管理工具。很多产品定义过一个时代，也培养了用户长期保存内容的习惯。可一旦公司改变方向、产品易主或服务关闭，用户才发现“我的收藏”和“我可以继续使用的收藏”并不是同一件事。
| 产品 | 它曾经解决什么 | 用户后来面对什么 |
|---|---|---|
| del.icio.us | 把网页收藏、标签与分享变成 Web 2.0 的日常动作 | 几经易主后，2017 年停止接受新收藏；一个活跃的知识网络变成只读的历史 |
| Bloglines | 把分散在许多网站里的 RSS 订阅收进同一个阅读器 | 在原定关闭、转手继续运营之后，原服务最终消失；用户能带走 OPML，却带不走原来的阅读空间 |
| Google Reader | 让订阅、阅读与分享成为许多人的互联网入口 | Google 在 2013 年关闭服务；订阅可以导出，长期形成的阅读流程和社交语境却无法一起迁移 |
| 让“以后再读”跨设备同步，并保留一个人的阅读清单 | Mozilla 在 2025 年关闭服务；用户必须在期限内导出，否则账户与数据随后删除 | |
| Evernote（仍在运营） | 把笔记、网页和资料汇成长期个人档案 | 产品仍在，所有权与定价却可以改变；内容是否容易取回和继续使用，仍由运营者决定 |
这些产品各自有完全不同的商业经历，不能简单归为同一种失败。关闭一个产品，也可能是运营者合理而艰难的决定。但从用户这一边看，共同的问题很清楚：一个好产品能不能继续运营，不应该决定一个人的记忆能不能继续使用。
导出当然比什么都拿不到好。但一个 XML、JSON 或 OPML 文件，只是数据的紧急出口，不是一个仍然可以阅读、整理、连接和发布的个人空间。用户真正需要的不是在产品关闭前抢救一次，而是从一开始就掌握这份内容的连续性。
问题不在于云。普通人当然需要 always-on，也需要换设备以后还能找到自己的东西。问题是：我们能不能同时拥有这种便利，又不把数据的命运交给某一个运营者？
把 Share 的方向反过来
2026 年，真正触发 Aside 的是手机上最平常的系统分享菜单。
今天点一下 Share，方向几乎总是“把这个东西发到另一个平台”。我想把这个方向反过来：Share，也可以是存进你自己的地方。
于是第一版的主循环变得很简单：收集，整理，发布。
先把链接、文字、照片和文件收进来，像“以后再看”；再把真正有关系的内容放到一起，留下自己的注释；如果愿意，公开的部分以后可以成为一个别人读得到的个人站点。一个人不需要先产生“我要建站”的宏大计划。站点可以是日常收集自然长出来的结果。
内部第一版叫 Stash，就是先收起来，再决定展示什么。后来对外定名为 Aside。英文里的 as an aside，是谈话里随口补上的一句。这个名字很适合它：随手分享的一点东西，最后也许会成为你的站点。
Aside 还有一只海狸 mascot，名字叫 Timber。我们做的是 consumer app，希望它看起来像一个愿意每天打开的东西，不像又一个严肃的企业控制台。海狸也很适合这个产品：它会收集材料，也会把零散材料慢慢搭成自己的空间。
这里还藏了一个小彩蛋：Aside Beaver Timber，三个词的首字母正好是 ABT。名字起得很认真，也没有认真到不能玩一下 🤣
Aside Beaver Timber，也就是 ABT。
Aside iOS 当前产品界面，采集自 aside.sh，2026 年 9 月。
收藏不是终点
很多收藏产品都会走进同一个循环：收进来，积灰，产生负罪感，然后放弃。
Aside 想把循环改成：收集，整理，发布，再从别人的整理里发现新的东西。
这也是为什么它不只是另一个 bookmark manager。一个链接可以和当时的笔记放在一起；一组照片、地点和参考资料可以成为一次旅行；围绕同一个问题留下的网页和想法，可以慢慢成为一个研究合集。整理不是替内容加几个标签，而是给自己的判断留下位置。
Aside 的合集界面。分享与发现仍在规划中，现阶段重点是本地收集与整理。
发布会让收藏有机会产生回响，回响又让人愿意继续收集。但这里的先后顺序很重要：先是你自己的内容，然后才是公开与连接。我们不会为了做一个内容平台，把用户的个人资料库反过来变成平台的数据池。
“属于用户”要落实到哪里
数据主权很容易被写成一句正确的空话。对 Aside 来说，它至少要落到几个具体选择上。
现在发布的 iOS 版本可以不登录使用，本地资料库保存在用户设备上。是否收集，怎样归类，哪些内容只留给自己，都由用户决定。网页预览等远程内容仍然可能需要网络；保存一个链接，也不等于把整个网站完整下载到手机。这些边界需要说清楚。
接下来，Aside 会接入 ArcSpace，也就是此前的 DID Space。它要解决的不是“把本地换成我们的云”，而是让同一个用户控制的数据空间可以保持 always-on，并在自己的设备之间同步。同步将是可选的。自托管、本地优先和云端可用，不应该互相排斥。
这也是过去很难把 Aside 做完整的原因。只有 bookmark 没有用；只有云同步，最终又回到平台账户；只有本地文件，对多数人又太麻烦。DID 给这个空间一个属于用户的身份，ArcSpace 给数据一个可以持续访问的位置。Aside 才能在上面成为应用，而不是又一个新的数据孤岛。
第一版还没有跨设备同步，也还不能把合集发布成公开站点。Android、Web、浏览器扩展和桌面端也在后面的计划里。我们会一项项发布，而不是先把未来时写成现在时。
ARC 第一次走进口袋
Aside 对 ArcBlock 还有另一层意义。
新的 ArcBlock 官网已经完全运行在 ARC（Agentic Realm Computer） 上。最近完成迁移的 ArcBlock Community，则把原来运行在 Blocklet Server 上、基于 Discuss Kit 构建的社区带到了 ARC。它们证明 ARC 可以承载网站，以及持续变化的社区内容。
Aside 从另一边检验这套系统：一个普通人每天拿在手里的 consumer app，能不能也建立在 ARC 上？
我们特意把 Aside 团队当作一个独立的第三方应用团队来工作。他们专心做 Aside，不直接参与 ARC 核心实现；遇到平台不好用的地方，再把真实问题带回来。负责首个 iOS 版本的同事有 Android 和 Web 开发经验，却没有完整开发 iOS 产品的经历。这次他借助 ARC 和 AI code agents，把产品真正做到了 App Store。
这不证明“任何人一句话就能做出好 App”。产品判断、调试、设计和发布一样都没有消失。它证明的是另一件更实际的事：平台经验不再是不可跨越的门槛，一个有产品想法的开发者，可以借助 agent 和一套稳定的应用基础，把能力延伸到以前不熟悉的终端。
对 ARC 来说，这比再做一个技术 demo 有价值得多。
这是第一篇
这篇文章只想先回答两个问题：Aside 是什么，为什么我们现在要做它。
接下来我们会继续写它怎样使用，开发者第一次完整做 iOS 产品时遇到了什么，ArcSpace 同步怎样保持用户对数据的控制，以及一套 mobile、web、desktop 和浏览器扩展如何共享同一份应用能力。Aside 会发布新版本，这个系列也会跟着产品继续往前走。
我反复想了二十年的，其实不是 bookmark 应该长什么样。真正的问题一直是：当一个产品不再继续时，用户这些年留下的东西怎么办？
Aside 的答案先从一个很小的动作开始。下次看到值得留下的东西，点一下 Share，把它送回自己的地方。