周日（昨天） 本地优先会议 ,举行了第一场活动“CRDTs Are Not Enough: 从 CRDT 到本地优先同步引擎“。 活动的形式是线上（能力有限）。 模式是社区开源沙龙，即自由发起活动，社区做支持。 工具是 bd.ailishi.ai 。 活动逐字稿第一时间发布在： https://bd.ailishi.ai/blog/ 欧洲的本地优先大会已经是第三届，许多内容很有趣，这得益于他们历史与生态。 欧洲的 Hacker 文化原本就健壮 ，较成熟的技术知识流动体系。结合技术，讨论工程、哲学等诸多问题，让新人逐渐发掘工程的乐趣与意义。这对一个新兴技术栈来说更友好。 本会议发起的灵感来自于欧洲的会议。邀请了一些该大会的分享者。但不认识他们的组织者（如果有人能帮忙认识，非常感谢）。 本地优先是一个新技术栈，但建立在一堆老理论上。本地优先是分布式系统的分支，并且更像是分布式系统领域成熟后的副产品。这一副产品，被越来越多人尝试与喜欢，离不开今天的现实——越来越多人质疑云的害处大于益处。 而它的新则体现在，社区中有关其想象、定义、协议，能有大量多样的辩论，各执一词，谁也无法说服谁。这反倒让人兴奋，这意味其中的讨论交流、尝试犯错，本身也在定义与发展本地优先相关的技术。 前沿 这是第一届本地优先会议。现在活动标题都取的太正式，但目的是为抛砖引玉。不只是日历上的活动，在场的大家一定都有自己擅长的与热爱的领域，值得分享给大家。本地优先领域，如果去看学界论文或者一些工程实践，这几年它的演进速度非常快，并且 agent 加速了这些东西，以后应该还会继续加速。所以，有没有可能出现一种新的计算栈，土计算？我不知道，最近看群聊，大家的想象都很不一样。 今天分享者 Loro 的陈子轩，在华人里可能是最有发言权的团队之一。也许都不止华人，我觉得是世界。他们团队对工程、各种设计的细节都很棒。如果有本地优先或者 CRDT 的问题，寻求他的想法，好一百倍。所以先表达对分享者的尊重，然后我们就开始吧。 分享征文 谢谢。今天我讲一下“CRDTs are not enough”，也就是：如果要做一个本地优先的同步引擎，现在还缺什么东西。 先简单自我介绍一下，我叫陈子轩，和 Leon 从 2022 年开始做 loro.dev ，它是一个 CRDT library 。到 2025 年，我们开始基于 Loro 做 lody.ai ，它是一个 local-first 的团队 AI agent 控制面。通过 Lody ，我们从真实的产品需求、从用户 UI/UX 的打磨出发，挖掘本地优先同步引擎现在该有的形态。中间我们发现了很多现在还缺失的东西，今天就分享一下我们的经验。 首先，什么是本地优先软件？ 简单说几个点：用户控制数据；可以自由切换不同的云端，作为数据备份。云端是一个备份和辅助者，而不是权威所有者。在这个架构里，云端只是一个备份和额外的副本。local-first 和 local-only 不一样：local-only 是只能在本地做这些事情，而 local-first 仍然希望保持多设备同步的便利性。 它给用户承诺五种体验：能秒开，因为数据读写都在本地；离线可用；多端协作；后端可以切换，不会因为软件服务提供商关门就影响使用；数据归我所有。这里面，一方面是软件服务提供商不能把我阻拦在使用软件之外；另一方面是隐私，我的数据不能被服务提供商随意读取。 最经典的例子是 Git 。虽然 Git 还没有做隐私这部分，但它已经非常接近本地优先软件理想中的形态。首先，它以协议的形式定义好本地和远端怎样交换数据。你可以切换不同的后端：GitHub 挂了，或者不想用 GitHub 了，可以切换 origin ，改用 GitLab ，或者自己 self-host 。 local-first 和 local-only 是不一样的。我看到群里挺多人会把两者混在一起。但现在其实缺一个大众级的应用，来完整交付这样的 local-first 体验。很多应用缺少云端的便利性，本来是 local-only ，却称自己为 local-first ；实际上没有提供云端便利，也没有提供 P2P 同步等选项。 我们和 local-first 社区对同步引擎的想象是什么样的？ 可以引用今年 Martin Kleppmann 在 Local-first Conference 上的分享：对于开发者来说，不用再担心请求失败、超时、数据是否到达服务器、要怎样告诉用户——这些复杂问题全部交给同步引擎就好了。但其实我们现在还没有这样的同步引擎。 大家希望一个统一、通用的同步引擎吸纳这些事情：请求失败怎么处理，数据没到服务端怎么处理，前端怎么告知用户，怎么管理权限，让用户能不能编辑这些事情都符合直觉、显而易见。还有，本地和后端怎样持久化，怎样切换不同的服务提供商。 从最终用户的角度，本地优先带来最直接的好处，一个是快，一个是安全。这样的同步引擎能够给终端用户带来这两种好处。 但从理论上来说，它绝对不可能是万能的。有一大类场景它解决不了，就是强一致性的场景。比如抢票、库存管理、支付、会议室抢占式预约，这些都是本地优先同步引擎从原理上没有办法处理的问题。因为这一系列问题需要强一致性，而本地优先的同步方式可以处理好最终一致性的场景。 这类场景很多时候就是创作，比如代码、文档、视频剪辑、音乐创作、各种艺术创作。这一大类场景是这类同步引擎可以统一解决的。 背后的必要复杂度，要从应用开发者转移到同步引擎上。 包括本地怎么存、超时怎么办、怎么告诉用户、要提供哪些事件、怎样表达背后的权限、怎样切换后端、怎样提供 P2P 、怎样同时提供端到端加密。这些都变成了同步引擎的职责。 现在 CRDT 库已经提供了这些能力：Loro 、Yjs 、Automerge 都能像 JSON 一样建模结构化文档，并提供最终一致性。只要各端最终拿到的更新集合一致，最终状态就一定一致。它们也提供增量同步；对文本、富文本、列表等类型，合并结果会尽可能符合预期。这里有比较多的相关论文，成果也被吸纳到这些 CRDT library 里了。更新同步时的乱序、重复等事情，也都被覆盖了。你不用关心一个更新在什么时间到达，可以安全地重发更新，它不会被应用两次。但这些并没有解决刚才说到的所有问题。这些 library 本质上是比较纯的计算，不覆盖网络层、持久化层等涉及 I/O 的部分。这些却都是同步引擎需要做好的事情。 比如，P2P 环境下的实践应该怎么做？这里还缺少很多东西，现在没有答案。同步协议怎么设计？目前也比较百花齐放。UX 怎么设计和交付，尤其在去中心化环境里，怎样让它更符合用户直觉？还有，在去中心化环境下怎么做鉴权，相应的 UI/UX 怎么呈现？ 我们在 Lody 落地的过程中一步步反推，积累了一些经验，简单分享一下，作为抛砖引玉。 这个项目现在应该有七千多个 commit 。 Lody 是一个 agent 控制面，需要同步各种对话信息，未来还会有更多文档信息。这里面相当于有几千篇文档，要同步它们的数据：怎么做懒加载？怎么同步整个 repo ？这是我们遇到的第一个问题。你不可能一打开应用就全量加载所有文档内容。但 Loro 、Yjs

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/22 01:57:04