Kleppmann Demands Open Sync Protocols to Break SaaS Vendor Lock-In

Kleppmann呼吁开放同步协议以打破SaaS厂商锁定 即便开发商关闭服务器，应用程序也必须能无限期运行，这需要行业用商品化的开放同步协议取代专有云后端，从而消除SaaS强行造成的用户数据锁定。 Kleppmann回顾了本地优先（local-first）软件的历史演进，从早期的CRDT学术研究、Automerge的创建，直至2019年该术语的诞生。他基于Leslie Lamport的原则提出了一个操作性定义：另一台计算机的不可用绝不能阻碍用户开展工作，从而让软件具备足够的弹性，即使厂商彻底倒闭或被收购（即“经得起不可思议旅程的考验”）也能继续存活。为了克服自托管和纯点对点网络的运维障碍，他主张通过开放、商品化的字节中继协议和混合投机型P2P，将客户端应用与同步基础设施解耦。Kleppmann在总结时强调，本地优先使小型工程团队无需沉重后端维护即可构建协作工具，从而改变了开发的经济模式，同时向行业发起挑战，呼吁用价值驱动的软件取代绑架数据的SaaS商业模式。 在发表最初的本地优先文章五年后，Martin Kleppmann基于对Leslie Lamport分布式系统原则的逆向思考，重新定义了本地优先：另一台计算机的不可用绝不能阻碍用户继续自己的工作。 (7:20) 要实现真正的本地优先，应用程序必须“经得起不可思议旅程的考验”——即使厂商倒闭、破产或被收购并终止其服务器，软件仍能正常运行。 (9:53) 标准化通用的字节级云同步协议可以使数据同步像Amazon S3一样商品化为通用基础设施，让用户只需更改一个配置标记即可切换后端托管服务。 (15:24) 本地优先彻底改变了软件工程的经济学，它消除了定制后端API、数据管道和全天候轮岗值班的需求，使小团队能够以极低的资本构建具有竞争力的协作应用。 (21:30)

Martin Kleppmann argues that local-first software must guarantee continuous user operation independently of external servers or vendor survival, shifting synchronization into commoditized, open infrastructure that fundamentally alters software economics. Redefining Local-First Around Availability and Survival (7:20) Kleppmann refines the conceptual boundaries of local-first software, moving away from the movement's original seven ideals toward an operational definition rooted in distributed systems principles. Inverting Leslie Lamport's famous dictum about distributed failures, Kleppmann posits that the availability of another computer should never prevent or block a user from working. Under this rule, offline functionality and multi-device synchronization are non-negotiable baselines, but simply being offline-first or local-only fails to meet the standard. Traditional local desktop applications lack multi-device synchronization, while relying on Conflict-free Replicated Data Types (CRDTs) does not automatically confer full local-first resilience. The ultimate operational test of the paradigm is making software 'Incredible Journey proof'—meaning the application remains fully functional even if its founding company goes bankrupt, shuts down its servers, and ceases paying cloud hosting bills. Kleppmann notes that startups documented on the Tumblr blog Our Incredible Journey routinely leave acquired users stranded with unusable raw JSON exports. For example, workspace tool Skiff shut down following an acquisition by Notion despite relying on the modern Yjs CRDT library. With large vendors also retiring nearly 300 products on Killed by Google, true longevity requires an architecture that survives the permanent disappearance of upstream infrastructure. The Practical Limits of Self-Hosting and P2P (12:45) While relying on proprietary, closed-source sync servers leaves users vulnerable when backends shut down, alternative decentralization architectures present severe operational bottlenecks. Kleppmann dismisses self-hosting as an inadequate general remedy, observing that running server infrastructure demands technical literacy that most users lack and imposes administrative overhead that even engineers actively avoid. Pure peer-to-peer (P2P) networking presents equal friction. P2P fundamentally struggles when collaborating devices are not online simultaneously. Furthermore, navigating real-world internet topologies requires traversing firewalls and NATs using signaling protocols and fallback TURN relay servers. Kleppmann highlights the architectural contradiction where deploying and maintaining specialized relay servers to sustain P2P connections introduces immense complexity while replicating the burden of operating conventional sync servers. Decoupled Architecture and Hybrid Commoditized Sync (15:24) To build durable systems without brittle P2P networks or bespoke backends, Kleppmann outlines an architecture where client software handles all domain logic, data mutations, and computations locally. This structure reduces remote servers to generic byte-passing pipelines that remain completely agnostic to application schemas, document types, or business rules. Kleppmann envisions standardizing these sync protocols so that major cloud providers like AWS or Azure could offer utility-style sync billing by the gigabyte, similar to Amazon S3. If a provider raises prices or discontinues a service, users could switch backend targets via simple configuration adjustments. This decoupled, open protocol approach enables an opportunistic hybrid model. Devices in physical proximity—such as laptops on the same desk—can sync directly over local networks to avoid latency and data round-trips to remote hubs like AWS data centers in Virginia. Cloud relays serve as asynchronous fallbacks when direct local connections fail, maximizing uptime by ensuring the failure modes of local networking and cloud infrastructure remain independent. Altering Developer Economics and SaaS Business Models (21:30) Kleppmann identifies a critical advantage overlooked in early local-first essays: transforming engineering economics. Building conventional SaaS forces companies to staff dedicated backend engineers, maintain complex cloud setups, and manage 24/7 on-call incident rotations. By consuming local-first synchronization as an off-the-shelf library that handles network drops, retries, and offline queues automatically, small engineering teams can launch multiplayer applications in days without massive venture capital. However, this architecture directly threatens the economic model of traditional Software-as-a-Service, which relies on proprietary data lock-in and hostage data dynamics to drive recurring subscription renewals. In a local-first ecosystem where users own their data and can redirect sync pipelines at will, software companies can no longer monetize through artificial data moats. Kleppmann contends that vendors must transition toward charging for continuous workflow improvements, active value creation, and superior user experience, though viable long-term business models remain an open, evolving question. Kleppmann concludes that the local-first movement must prioritize architectural resilience over dogmatic implementation choices, encouraging experimentation across diverse engines like Automerge rather than rushing premature standardization through bodies like the IETF. The foremost unresolved question remains whether viable commercial business models will emerge to sustain local-first applications once artificial data moats are eliminated.

分布式系统学者 Martin Kleppmann 提出，“本地优先”（Local-first）软件的核心准则是用户的操作绝不能因任何外部计算机的不可用而受阻；该架构不仅要求支持离线操作与跨设备同步，更要求软件在开发商倒闭、专有服务器关停的极端情况下依然能够持续运行并保留完整数据访问权。 概念界定与操作化定义的演进 (7:20) Kleppmann 回顾指出，2019 年发表的奠基性论文《Local-first software》列出的七大理想虽然描绘了终端用户的核心利益，但缺乏清晰的技术边界。行业初期常出现三种认知误区：将本地优先等同于早期的“离线优先”（Offline-first）、误认为本地优先仅仅是 CRDT（无冲突复制数据类型）的代名词，或是教条式地要求完全抛弃服务器走向纯粹的点对点（P2P）架构。此外，仅保存在单机本地的传统单机软件也不属于本地优先，因为跨设备同步是该体系不可或缺的前提。 为了确立严谨的技术判定标准，Kleppmann 逆向引用了分布式计算先驱 Leslie Lamport 于 1987 年关于分布式系统脆弱性的经典论断，提出本地优先的操作化定义：在本地优先软件中，任何其他计算机的可用性状态都不得阻断当前用户的正常工作。这意味着离线可用是一项强制性的基础前提，但本地优先对数据所有权、长期存续性与协同架构的追求远超单纯离线模式的范畴。 抵御服务终结的架构生存力 (9:53) Kleppmann 认为，衡量本地优先的真正试金石是应用能否经受住原创开发商倒闭并停止支付云账单的考验。科技行业长期存在初创企业被收购后迅速停服的惯例，诸如记录初创企业落幕的博客《Our Incredible Journey》，或是收录了近 300 款废弃产品的《Killed by Google》。在此类风险面前，即使像端到端加密套件 Skiff 那样采用了 Yjs 和 CRDT 技术，在被 Notion 收购后依然难逃关停命运，用户往往只能获得无法导入其他工具的 JSON 导出文件。这证明孤立的数据结构算法并不能自动保障软件的长期存活性。 为抵御这种消亡危机，单纯依赖自行托管（Self-hosting）难以成为普适方案，因为其技术门槛与维护负担将绝大多数普通用户拒之门外，即便专业工程师也不愿承担繁重的服务器运维工作。另一方面，纯 P2P 网络受制于 NAT 穿透、防火墙限制以及多设备难以同时在线的客观限制，其所依赖的信令与 TURN 中继服务器反而消解了去中心化的理论优势。因此，架构必须确保应用逻辑与本地数据完全脱离对特定商业主体的依赖。 解耦存储与商品化同步协议 (15:24) 为了突破专有服务器与纯 P2P 的两难困境，Kleppmann 提倡将用户界面及业务逻辑与底层的同步传输通道进行彻底解耦。在本地优先架构中，所有数据计算与状态突变均在用户的本地设备完成，这使得同步服务器的角色退化为完全不感知业务模型、数据格式或具体文档类型的通用字节流管道。无论是电子表格、图形设计工具还是任务面板，都可以接入同一种通用传输层。 基于这种解耦逻辑，未来的数据同步基础设施有望演变为类似 Amazon S3 的开放标准协议，由大型云服务商提供按传输容量计费的商品化同步服务。届时用户与开发者只需切换配置参数，即可在不同云服务商或自建服务之间无缝迁移，消除厂商锁定。在此基础上，系统可采用混合网络拓扑：在面对面的局域网环境中优先建立直接互联以规避越洋机房带来的延迟，同时保留云端管道作为兜底备份，从而最大限度地提高系统的整体韧性。 研发经济重塑与商业模式重构 (21:30) Kleppmann 坦承，2019 年的初期论述忽视了本地优先在工程效能层面对开发者的重大价值。在传统 SaaS 架构下，团队不得不耗费巨额成本雇佣后端专家、搭建复杂的云基础设施、处理 CI/CD 流程并承担全天候的紧急运维轮值；而本地优先将网络波动重试、离线队列管理和冲突解决下沉为通用的标准客户端库，使极小的初创团队能够以极低的资本支出开发出高水准的多人协同软件，根本性地改变了软件生产的经济模型。 与此同时，该范式也对传统的商业变现机制构成了深刻挑战。传统 SaaS 普遍通过垄断数据存储建立排他性护城河，利用数据迁移壁垒维系订阅收入；而本地优先赋予了用户完整的数据控制权与自由迁移能力，彻底瓦解了这一机制。Kleppmann 认为，未来的本地优先产品必须转而依赖卓越的交互设计、工作流体验与持续的增值服务来赢得市场。鉴于当前生态中各类 CRDT 实现与同步引擎仍在快速演进，过早进行僵化的行业标准化并不合时宜，当前的核心在于通过多元实践验证不同架构的取舍。 Kleppmann 强调，本地优先不是某项单一算法或排斥服务器的教条，而是一套确保用户对软件和数据拥有永久控制权的架构理念。尽管在通用同步标准的形成以及摆脱数据绑架的新型商业模式上仍存在未决探索，但彻底消除外部单点故障对用户生产力的阻碍，构成了下一代应用开发不可逆转的演进方向。

## Background 该视频由 Local-First Conf 官方频道于 2024 年 6 月 18 日发布在 YouTube 平台。内容为剑桥大学研究员、Ink & Switch 合作者 Martin Kleppmann 在大会上的主题演讲，回顾了自五年前发表奠基性论文以来 Local-First 理念的起源演化，并探讨了当前的行业现状与未来愿景。 ## TL;DR Martin Kleppmann 回顾了从早期 CRDT 理论探索、Automerge 开发到提出 Local-First 理念的历程，重塑了该架构的核心定义：外部计算机或网络故障绝不应阻塞用户工作。他提出了能够抵御开发商倒闭关停的“防御不可思议旅程（Incredible Journey Proof）”标准，犀利剖析了纯 P2P 与自托管的现实局限。最后，他倡导构建跨应用、可自由插拔的标准化通用同步协议，并指出 Local-First 将重塑软件研发经济学，迫使商业模式从数据绑架回归到纯粹的产品价值创造。 ## Atmosphere & style 现场氛围既有学术泰斗的严谨沉稳，又洋溢着极客运动先锋聚会的蓬勃朝气。Kleppmann 举重若轻地用风趣自嘲和辛辣讽刺拆解云端 SaaS 行业的荒诞现实，台下不时爆发热烈的掌声与会心笑声。整场演讲不仅有对底层分布式系统架构的深刻剖析，更充满了一种赋予终端用户数据主权、解放独立开发者的技术理想主义情怀。 ## Bulletin - [16:33](https://www.youtube.com/watch?v=NMq0vncHJvU&t=993s) Local-First 软件的核心定义升级为“抵御‘精彩旅程’的倒闭考验”（Incredible Journey Proof），即即便开发者停止运营并关停所有服务器，用户仍能完全访问并操作自己的数据。 - [19:43](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1183s) Martin Kleppmann 提出将云端服务重构为标准化的“通用同步服务”，使数据同步成为可插拔的基础设施，而非绑定在特定应用内的逻辑。 - [12:21](https://www.youtube.com/watch?v=NMq0vncHJvU&t=741s) Local-First 不应被狭隘理解为纯 P2P，通过结合通用云存储、局域网直连与标准协议，可构建性能与鲁棒性兼顾的混合架构。 - [22:43](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1363s) 本地优先范式正在重塑软件研发的经济学，通过外包同步层，极大地降低了小型开发团队构建复杂协同软件的门槛与运维负担。 ## Key takeaways - [08:11](https://www.youtube.com/watch?v=NMq0vncHJvU&t=491s) Local-First 的核心判据：其他任意机器或远程服务的离线或崩溃，绝不能剥夺用户读取与修改本地数据的权利。 - [08:11](https://www.youtube.com/watch?v=NMq0vncHJvU&t=491s) Local-First 必须是多设备系统；若仅支持单机运行而不具备多端同步能力，则不在其范畴内。 - [08:11](https://www.youtube.com/watch?v=NMq0vncHJvU&t=491s) Offline-First 是 Local-First 的必要条件，但后者更关注数据所有权与抵御开发商关闭服务带来的数据清空风险。 - [04:51](https://www.youtube.com/watch?v=NMq0vncHJvU&t=291s) Local-First 不等同于仅使用 CRDT，CRDT 只是实现该理念的技术路径之一。 - [12:43](https://www.youtube.com/watch?v=NMq0vncHJvU&t=763s) 单纯依赖自托管服务器或纯 P2P 存在现实缺陷：前者增加了用户的运维成本，后者在 NAT 穿透和连接稳定性上面临严峻的工程挑战。 - [09:53](https://www.youtube.com/watch?v=NMq0vncHJvU&t=593s) “Our Incredible Journey”这一现象提醒开发者，依赖初创公司专有云后端在长期可用性上具有极高的不确定性。 - [19:43](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1183s) 通用同步服务的愿景：像使用对象存储（S3）一样按量付费，且服务商可自由替换。 - [22:43](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1363s) 本地优先架构允许将业务逻辑与数据处理完全留在前端，无需处理复杂且脆弱的网络错误状态。 - [26:17](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1577s) 在本地优先架构下，商业护城河不能再依赖数据劫持，必须回归到软件自身提供的产品价值驱动。 - [26:17](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1577s) 目前行业处于“百花齐放”的技术探索期，制定过早的强制性国际标准化可能限制创新，应先通过实践积累经验。 - [21:37](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1297s) 混合式同步策略结合了公网云托管与本地直连，能有效解决在同一局域网内同步却需绕行远端数据中心的延迟问题。 - [00:01](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1s) Martin Kleppmann 将 CRDT 领域的研究追溯至 2011 年 Marc Shapiro 的论文，该研究为去中心化同步奠定了基础。 ## Detailed walkthrough ### [00:01](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1s) Local-First 理念的诞生背景与学术溯源 在 Chad 的介绍之后，Martin Kleppmann 登台发言。面对座无虚席的会场，他感慨自己十分激动能看到如此多志同道合的人汇聚一堂，共同致力于让 Local-First 成为现实，并称赞在场的大家都是这场运动的先驱者。Kleppmann 明确了本次演讲的脉络：以其个人视角回顾 Local-First 的起源、评估当前的行业现状，并展望未来数年的演化方向。 Kleppmann 涉足该领域的历程始于十多年前。2011 年，Marc Shapiro 及其同事发表了关于冲突自由复制数据类型（Conflict-free Replicated Data Types, CRDTs）的开创性研究论文。当时还在工业界工作的 Kleppmann 逐渐对主流 Web 软件与 SaaS 的构建方式感到沮丧，四处探寻能够改善这一现状的技术。大约在 2013 年，他读到了 Shapiro 的论文，敏锐地意识到其中蕴藏着某种变革的核心潜能，尽管当时还无法清晰地用语言归纳出来。为了全心投入这项研究，他毅然辞去工业界工作，休了整整一年的学术假，随后正式进入学术界。 为了验证 CRDT 的实际效能，Kleppmann 开始编写自己的文本编辑器原型。他打趣道，这个编辑器是用 Ruby 写的，因为在 2015 年 Ruby 依然有不少人使用（他随即笑着向台下解释自己绝无贬低之意）。“它是一个非常糟糕的软件，在你编辑之后需要两分钟才能把文件保存下来，”但正是这样一个简陋的原型，开启了后续的一系列重要探索。 - 2011 年：Marc Shapiro 等人发表 CRDT 核心论文，奠定了去中心化无冲突数据同步的理论基础。 - 2013 年前后：Kleppmann 接触到 CRDT 论文，萌发了改变 Web 及 SaaS 架构的想法。 - 2015 年：Kleppmann 转入学术界，使用 Ruby 开发了实验性质但极为缓慢的 CRDT 文本编辑器原型。 --- ### [02:23](https://www.youtube.com/watch?v=NMq0vncHJvU&t=143s) 从 Automerge 到《Local-First 软件》宣言：为一种新架构命名 到了 2017 年，研究机构 Ink & Switch 主动联系了 Kleppmann。他们向他提议：既然已经拥有了出色的 CRDT 理论成果，何不合作构建能够真正落地的实用软件？双方随即展开合作，共同创建了数据同步库 Automerge。该项目最初采用 JavaScript 编写，并由 Kleppmann 亲自维护了数年；后来为了追求极致性能，Automerge 完全由 Rust 进行了重写，走向生产级成熟，Kleppmann 也逐渐转为项目的顾问角色。 ```mermaid flowchart TD accTitle: Automerge 与 Local-First 演进脉络 accDescr: 展示从理论研究到工程实践，再到社区生态爆发的发展路径。 subgraph Phase1["理论与原型探索 (2011-2015)"] A["Marc Shapiro 的 CRDT 论文 (2011)"] --> B["Kleppmann 辞职进入学术界"] B --> C["Ruby 版 CRDT 文本编辑器原型 (2015)"] end subgraph Phase2["工程落地与概念提出 (2017-2019)"] D["Ink & Switch 与 Kleppmann 合作"] --> E["Automerge (JS 版起步)"] E --> F["确立核心原则与价值观"] F --> G["发表《Local-First 软件》论文 (2019)"] end subgraph Phase3["Rust 重写与生态爆发 (2019-至今)"] G --> H["Automerge 用 Rust 彻底重写达到生产级"] G --> I["大量自研与开源 Local-First 项目涌现"] end Phase1 --> Phase2 Phase2 --> Phase3 ``` 在长期构建此类系统的过程中，团队始终面临一个表达困境：缺少一个恰当的形容词。他们经常需要描述“我们正在构建某种特定类型的应用”，而这个空缺的词必须精准承载他们试图注入技术中的核心价值观与设计原则，它不仅仅是指代某项单一的技术本身。在权衡了诸多替代方案后，团队最终锁定了“Local-First”（本地优先）这一概念。整整五年前（2019 年），他们联合发表了奠基性的长文《Local-First 软件》（Local-first software: you own your data, in spite of the cloud），系统阐述了这种全新架构范式对终端用户带来的根本价值。 - 2017 年：Ink & Switch 与 Kleppmann 联手，启动开源 CRDT 库 Automerge 项目。 - 2019 年：正式发表 Local-First 开篇长文，提炼出以此为指导原则的七大理想（Seven Ideals）。 - 过去五年间：Automerge 迁移至 Rust 并投入生产环境；与此同时，海量自称为 Local-First 或理念高度契合的第三方软件与框架在业界全面爆发。 --- ### [04:51](https://www.youtube.com/watch?v=NMq0vncHJvU&t=291s) 厘清认知迷雾：Local-First 不是单一技术绑定 随着 Local-First 阵营从一个纯粹的学术/小圈子探索发展为大规模的技术运动，社区内涌现出各种对定义的分歧与疑问。Kleppmann 指出，很多人会问：它与早在六年前就存在的“Offline-First”（离线优先）到底有何区别？如果两者一样，为何还要造一个新词？Kleppmann 明确回应，当年提出 Local-First 时，他们非常清楚 Offline-First 的存在，之所以必须铸造一个新概念，是因为 Offline-First 遗漏了许多关乎用户数据主权和架构形态的核心诉求。 此外，行业中还充斥着几种典型的狭隘认知： 1. **“Local-First 等同于使用 CRDT”**：Kleppmann 认为这种理解过于狭隘，CRDT 仅仅是实现该理念的技术路径之一，完全可以通过其他算法或同步机制实现 Local-First。 2. **“Local-First 必须是纯 P2P（对等网络），绝不能有任何服务器”**：这同样是对架构的过度误读，服务器在 Local-First 中依然扮演着重要的备份、中继与协同角色。 3. **“原论文提出的七大理想就是充要定义”**：原本设想软件满足这七项原则即可被称为 Local-First，但实践证明，那七条更偏向终端用户能获得的价值收益清单，无法作为非黑即白的工程判定标准。因此，学术界与早期发起人们意识到，必须为 Local-First 提供一个更加精准、清晰的新定义。 --- ### [07:21](https://www.youtube.com/watch?v=NMq0vncHJvU&t=441s) 核心重塑：以 Leslie Lamport 的分布式系统法则为镜 为了引出对 Local-First 的最新定义，Kleppmann 引用了著名分布式系统先驱、2013 年图灵奖得主 Leslie Lamport 在 1987 年的一封电子邮件中的经典名言： > “A distributed system is one in which a failure of a computer you didn't even know existed can render your own computer unusable.”（分布式系统就是这样一种系统：一台你甚至不知道它存在的计算机发生故障，就会导致你自己的计算机无法使用。） Kleppmann 调侃说，这对于现代开发者再熟悉不过了——只要 GitHub 宕机，或者 AWS 某项基础服务出现异常，半个互联网就会瘫痪，你自己的工作也会瞬间中断。基于对这种脆弱性的反思，Kleppmann 提出了他对 Local-First 的核心定义：“在本地优先软件中，另一台计算机的可用性，永远不应阻止用户进行工作，它绝不应该阻塞用户（in local-first software, the availability of another computer should never prevent the user from working; it should never block the user）。” 接着，Kleppmann 逐步拆解这一定义的内在边界： 1. **Local-First 不等于 Local-Only（仅本地）**：纯粹将文件存储在本地磁盘、完全不接入互联网的传统桌面单机软件，虽然技术上符合本地运行，但不是 Local-First 关注的对象。Local-First 必须是**多设备系统（Multi-Device Software）**。不论是不同协作者之间的数据共享，还是单个用户在自己的多台终端（如手机与电脑）之间同步数据，具备多端数据同步能力是判定 Local-First 的绝对前提。 2. **“另一台计算机的可用性”涵盖网络基础设施**：如果网络断开、Wi-Fi 关闭，或者用户身处没有蜂窝信号的地下隧道中，软件就无法继续正常工作，那它绝对称不上是 Local-First。因此，**Offline-First 是 Local-First 的必要条件，任何 Local-First 软件都必须先做到 Offline-First**，但仅满足 Offline-First 还远远不够。 3. **核心思想的递进**：Local-First 在离线支持的基础上，进一步通过所有权、本地主写副本与去中心化可用性保障，彻底消除了由于外部节点不可达而导致的客户端阻断。 - 核心思想判据：其他任意机器或远程服务的离线或崩溃，绝不能剥夺用户读取与修改本地数据的权利。 - 适用范围界定：排除了无网络连接诉求的传统 Local-Only 孤岛软件，专注于解决多设备、多用户下的无阻塞实时与异步协同。 ### [09:53](https://www.youtube.com/watch?v=NMq0vncHJvU&t=593s) 本地优先的核心定义：“抵御‘精彩旅程’的倒闭考验” Martin Kleppmann 开门见山地给出了他对本地优先（Local-First）最严苛但也最本质的定义：哪怕原软件的开发商倒闭、关停所有服务器、不再支付 AWS 账单，这款软件依然必须能够正常工作，否则它就根本不配被称为本地优先。听众席随即爆发出热烈的掌声与笑声。Kleppmann 解释道，这里所追求的鲁棒性（robustness），不仅仅是指网络断开这种网络层面的可用性，更是指当外部计算机彻底宕机、停机并抹除所有数据时的生存能力。 ```mermaid flowchart TD accTitle: 传统 SaaS 与本地优先应用在服务关闭时的对比 accDescr: 展示当开发团队停止维护并关闭服务器时，传统 SaaS 导致数据丢失，而本地优先应用依然保留数据与核心功能。 subgraph CloudSaaS["传统中心化 SaaS"] A["创业团队被收购或关停"] --> B["服务器下线 / 欠费停机"] B --> C["数据彻底清空"] C --> D["用户软件完全瘫痪<br/>（最多给一个无法导入的 JSON 压缩包）"] end subgraph LocalFirstApp["真正的本地优先架构"] E["原始开发商倒闭"] --> F["中央服务器永久消失"] F --> G["本地数据完好无损"] G --> H["离线功能照常运行<br/>（Incredible Journey Proof）"] end ``` 为了讽刺当今云端软件行业的常态，Kleppmann 提到了 Tumblr 上一个仍在更新的著名讽刺博客“Our Incredible Journey”（我们难以置信的精彩旅程）。在这个博客里，收录了无数刚被巨头收购、并计划在三个月内关停服务的初创公司公告。创始人总是在公关稿里抒情地说：“感谢用户让我们拥有如此不可思议的创业与套现之旅！”随后话锋一转：“但现在我们要狠狠坑你们一把——几个月后删掉你们所有的数据；运气好的话，给你们一个装满导不出格式的 JSON 文件的 zip 压缩包，祝你们好运。”Kleppmann 直言，这种困境正是五年前促使他们构思本地优先概念的核心驱动力，可惜他们在早期的原始论文中未能将这一点阐述得足够透彻，因此他今天必须大加强调。 这一事实也雄辩地证明，仅有 CRDT（无冲突复制数据类型）并不足以构成完整的本地优先应用。Kleppmann 以博客最新收录的案例举例：端到端加密的协同文档工具 Skiff 尽管底层完全构建在优秀的 CRDT 库 Yjs 之上，但当它被 Notion 收购后，依然毫无悬念地宣布关停并登上了“Our Incredible Journey”。“如果整套应用架构没有从根本上围绕本地优先进行设计，光靠一个 CRDT 库根本救不了用户。”此外，这种威胁绝不局限于初创公司，像“Killed by Google”网站就记录了近 300 个被谷歌亲手埋葬的产品，其中不乏像 Google Reader 这样深受喜爱的殿堂级应用。因此，业界现在将这一设计目标形象地称为“抵御‘精彩旅程’的倒闭考验（Incredible Journey Proof）”。 - 衡量标准：即使原开发者停止支付 AWS 账单并下线全部服务器，软件依然可以正常运行。 - 反面教材：Skiff 虽然采用了基于 Yjs 的端到端加密与 CRDT 技术，但被 Notion 收购后依然难逃被整体关停、登上 Our Incredible Journey 的命运。 - 行业现象：Killed by Google 记录了近 300 款被官方关停的谷歌产品（如 Google Reader），证明即便是巨头的产品也不具备永久可用性。 > “在我看来，如果软件在原始开发者破产、关闭所有服务器并停止支付 AWS 账单后就无法运行，那它就不是本地优先。”（"In my opinion, if the software doesn't work even if the original developer of the software goes out of business and shuts down all of their servers and stops paying their AWS bills, then it's not local first." —— Martin Kleppmann） --- ### [12:45](https://www.youtube.com/watch?v=NMq0vncHJvU&t=765s) 破局路径辨析：自建服务、P2P 与通用云存储的现实困境 要让应用在服务器消失后依然存活，最大的技术挑战在于设备间的同步需求。通常两台设备同步时，中间总会依赖服务器。如果依赖的是专有服务器（只有开发者持有专有代码），用户便无法应对服务器断供的风险。Kleppmann 逐一剖析了目前社区探讨的几种替代路径及其现实瓶颈： 第一条路是开源服务器并倡导用户“自行托管”（Self-hosting）。Kleppmann 认为这并非完美解法，因为自建服务器对技术水平有极高要求，能做到的人在总人口中比例极低；更何况哪怕是像他这样具备技术能力的极客，现实中也不想被琐碎的运维所绑架：“我不想整天折腾维护服务器，我的人生还有更重要的事情要做。”因此自托管只能作为一种补充方案，绝非根本之道。 第二条路是纯点对点（P2P）网络。P2P 在理论上极具吸引力，设备之间无需服务器即可直连同步，顶多依赖天空中的通用 DHT（分布式哈希表）。但在实践中，构建优秀的 P2P 体验异常困难：不仅要求两台设备必须同时在线才能握手，更麻烦的是现实互联网中充斥着复杂的 NAT 穿透问题和防火墙屏障。为了建立连接，开发者被迫设计出精密的信令（Signaling）机制，并且为了防止打洞失败还必须配置 TURN 中继服务器。这反而导向了一个荒谬的悖论：“既然你无论如何都必须搭一套信令服务器和 TURN 服务器，那为什么不直接用这台服务器去跑数据同步呢？”Kleppmann 坦言，现阶段 P2P 方案往往是“付出了巨大的技术复杂度，却只换来了微薄的收益”。 第三条路则是将数据存入通用的第三方云存储（如 Dropbox、Google Drive 或 iCloud），而非开发者的专有服务器。虽然理论上云巨头也可能停运，但比起一个由两人创立的随机初创团队自建的服务，Google Drive 在未来十年内继续存在的概率显然高得多（这绝非轻视创业者的野心，而是基于历史规律的客观评估）。然而这类通用网盘纯粹是按文件系统设计的，无法优雅支持光标追踪、鼠标实时轨迹等多用户低延迟协同。不过，利用解耦的通用服务这一构想，给未来架构带来了至关重要的启发。 - 自托管（Self-hosting）的局限：极高的认知与技能门槛，连资深工程师也不愿耗费宝贵精力充当“兼职系统管理员”。 - P2P 网络的工程悖论：为了解决 NAT 和离线问题而搭建的信令（Signaling）和中继（TURN）服务器，其运维成本让纯 P2P 架构丧失了无服务器的初衷。 - 通用网盘（Dropbox/Google Drive）的瓶颈：面向静态文件读写设计，天然缺乏对毫秒级实时多光标协同的支持。 > “在理论上我确实可以自己托管服务器，但我真的想这么干吗？我可不想整天干维护服务器的营生，我的人生还有更有意义的事要做。”（"Like in principle I could self-host the server, but do I really want to? Like I I don't want to be in the business of running servers. I have better things to do with my life." —— Martin Kleppmann） --- ### [16:43](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1003s) 面向未来的构想：通用的标准化同步协议 在演讲迈入面向未来的章节时，Kleppmann 勾勒出了本地优先软件的长远蓝图。试设想一个用户在手机和笔记本上安装了由不同开发者编写的多款本地优先应用：电子表格、图形设计工具、任务管理器等。本地优先的核心设计原则是“所有核心逻辑都在客户端本地运行”，因此设备之间的同步本质上应该极其纯粹——不过是把一串字节（bytes）从一端可靠地搬运到另一端，服务端根本不应当承载复杂的应用业务逻辑。 ```mermaid flowchart LR accTitle: 基于标准化协议的跨应用通用同步服务架构 accDescr: 多款客户端应用通过统一开放的标准同步协议，连接到任意可互相替换的通用云同步服务提供商。 subgraph ClientDevices["用户终端设备（全量本地逻辑）"] App1["表格应用"] App2["图形设计应用"] App3["任务管理应用"] end subgraph OpenProtocol["开放标准同步协议 (Standardized Wire Protocol)"] direction TB Proto["纯字节流传输 / 不绑定特定数据模型"] end subgraph SyncProviders["可自由插拔的通用同步后端"] AWS["AWS 本地优先同步服务<br/>（类 S3 按 GB 计费）"] Azure["Azure 兼容同步服务"] SelfHost["开源备用同步节点"] end ClientDevices --> Proto Proto -.->|"自由切换配置"| AWS Proto -.->|"无缝迁移"| Azure Proto -.->|"自主接管"| SelfHost ``` 既然服务器只需要做一个无差别的“哑管道（dumb pipe）”，那么完全可以构建一个独立于具体应用类型和数据模型的“通用同步服务”（Generic Syncing Service）。在 Kleppmann 的愿景中，整个本地优先社区应当共同探索并制定出一套去中心化、应用无关的开放标准同步协议。只要大家在协议层达成共识，市场上就可以涌现出各种不同厂商实现的互操作服务： 未来可能就像今天使用 AWS S3 存储对象一样，AWS 或微软 Azure 也会提供标准化的本地优先同步托管服务，按存储与传输的吉字节（Gigabyte）向终端用户收取低廉的费用。用户买来任何本地优先软件，只需在设置里填入自己的同步端点。当某一天 AWS 决定关停服务、更改条款或者大幅涨价时，用户根本不需要担心软件瘫痪，只需修改一行配置，将应用指向 Azure、其他托管商或社区开源节点，整个数字生活便可无缝延续。 - 职责分离：业务逻辑 100% 留存端侧，云端退化为仅负责转发字节流的极简同步层。 - 商业模型构想：云计算厂商像售卖 S3 存储桶一样提供同步管道基础设施，用户按用量自付极低的成本，摆脱对单一软件厂商专有云服务的寄生依赖。 - 终极目标：建立跨厂商、可自由替换的标准化同步协议，从根本上终结“软件停运即死亡”的行业宿命。 > “由于在客户端本地离线运行的要求下，服务端本就不该承担任何业务逻辑或复杂操作，这就意味着我们完全有可能打造一个通用的同步服务，供大量截然不同的应用程序共同使用。”（"Because you shouldn't be doing any sort of business logic or anything particularly complex in the server anyway if you want all of the software to continue working offline locally on the user's client, which suggests that it should be possible to have a generic syncing service that can be used by a whole bunch of different applications." —— Martin Kleppmann） ### [19:44](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1184s) 通用同步协议与混合架构：为什么点对点与云服务必须并存 Martin Kleppmann 指出，当同步服务演变为高度商品化（commoditized）的底层基础设施时，应用开发者在切换不同的同步托管服务时，只需要在应用里修改一个配置项（configuration flag），其余所有功能都应当保持正常运行。应用开发者不再需要被绑定在某一家特定的同步服务上，这种跨服务的互操作性（interoperability）正是通用同步协议的核心价值所在。 ```mermaid flowchart TD accTitle: 混合同步网络架构 accDescr: 本地客户端同时利用局域网点对点和通用云同步服务实现高容错同步 subgraph Clients["本地设备端"] C1["设备 A"] C2["设备 B"] end subgraph SyncChannels["双通道同步机制"] P2P["局域网 / P2P 连接<br/>（就近快速通信）"] Cloud["通用云同步服务<br/>（基础设施托管）"] end C1 <-->|"本地局域网 / 机会性直接同步"| P2P P2P <--> C2 C1 <-->|"公网备份与离线中转"| Cloud Cloud <--> C2 ``` 有了通用的同步协议后，将点对点（peer-to-peer，P2P）重新引入架构才真正具备了现实意义。Martin 强调，P2P 协议在能够正常连接时的体验非常惊艳，而当两台设备面对面放在同一张桌子上时，同步数据却非得绕道弗吉尼亚州的 AWS us-east-1 节点，这本身就是一件荒谬的事情。因此，在局域网可用时利用本地网络，或者在公网上机会性（opportunistically）地建立 P2P 直连，是绝佳的性能优化路径。关键在于不能将 P2P 作为唯一的同步手段；将云端托管与 P2P 相互结合，系统在容错性上能实现双重保障，因为云服务宕机的场景与 P2P 连接失效的场景往往截然不同。Martin 坦言：“这对我来说是实现防御‘不可思议旅程’（Incredible Journey proof）这一目标极具前景的路径，即拥有多个可互操作的同步提供商。”虽然整个生态目前尚未完全实现这一愿景，但这正是社区需要共同努力的方向。 - 只要所有同步服务遵循统一协议，开发者换用服务商就像切换开关一样简单。 - 当两台设备处于同一空间时，通过本地局域网直连能彻底避免绕行远端数据中心的网络延迟与带宽浪费。 - 混合架构能同时抵御 P2P 穿透失效与云端单点故障，构建真正坚固的容错闭环。 --- ### [21:30](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1290s) 解放前端与独立开发者：本地优先对软件研发模式的经济学重塑 将同步层变为通用的公共基础设施，不仅为终端用户带来好处，更为软件开发者带来了颠覆性的红利。Martin 回忆道，五年前他们发表最初的 Local-First 论文时，主要视角都集中在终端用户的权益上；但过去五年的实践表明，本地优先带给开发团队的收益绝不亚于用户端。最显著的改变在于，应用开发团队不再需要专门雇佣一支庞大的后端工程团队。在传统的云原生架构下，初创公司不仅要构建用户界面，还必须招聘人员去编写云端服务、研究 AWS 晦涩复杂的配置、维护 DevOps 运维体系，并由后端工程师背负 24 小时待命的 On-call 轮值压力。 如果把繁琐的后端数据同步完全当成“别人的问题”，软件团队就可以把 100% 的精力集中在打造核心差异化体验上——打磨卓越的 UI、顺畅的交互，以及深入满足终端用户的业务需求。不仅如此，本地优先模式彻底改变了传统云端应用脆弱的网络编程模型。在传统的云端架构中，前端每一次操作都要向后端发起网络调用，开发者必须处理各种弱网超时状态，并编写繁琐的 UI 错误提示。而在本地优先架构中，所有读写都直接作用于本地状态，同步协议作为现成的 npm 依赖在后台静默运行。正如 Martin 所总结的那样：“它关乎改变软件的经济学，让更小的团队能做更多的事情，用更少的人和更少的资金构建出更令人惊艳的应用。”这让小团队甚至个人开发者为利基市场（niche markets）构建小而美的软件变得在经济上完全可行。 - 本地优先技术极大加速了软件原型开发，许多开发者借助这套模型在短短一周内就构建出了复杂的协同交互原型。 - 免去了开发团队自己搭建和为云端基础设施买单的成本，托管同步成本可以直接转由用户独立订阅或自选。 - 移除了散布在前端各处的网络错误捕获逻辑，本地操作拥有确定性的即时响应体验。 --- ### [26:17](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1577s) 商业模式挑战与未来愿景：百花齐放与真正的技术原则 本地优先为研发经济学带来红利的同时，也迎面撞上了软件商业模式的最大挑战。在传统 SaaS 模式中，服务商手里握有一把无形的枪顶在用户头上：“你在这里存了挺不错的资产，要是这些数据全丢了多可惜啊？所以你最好乖乖付订阅费，免得我们把你的数据全删了。”而在具备防御“不可思议旅程”能力的本地优先世界中，这种威胁彻底失效了，因为用户随时可以带着完整数据迁往别处。换言之，初创公司口中常说的“数据护城河（data moat）”在本地优先语境下被大幅削弱了。Martin 指出，软件行业必须转变思维，不能再靠劫持用户数据作为人质（holding users ransom）来收费，而应凭借软件本身持续为用户创造的使用价值来赢得付费意愿。 针对技术实现路径，虽然 Martin 深度参与了 Automerge 项目，但他强调自己对生态中涌现的各种不同技术持完全开放的态度。目前整个领域依然处于“百花齐放（thousand flowers blooming）”的探索阶段，大家尚未完全摸清各种技术方案的权衡得失，因此现在就跑到 IETF 去为通用同步协议制定死板的国际标准还为时尚早。在接下来的几年里，社区需要通过大量实践积累经验，届时再去成立标准化委员会才水到渠成。在全场热烈的掌声中，Martin 总结道：“本地优先是一套原则和价值观，而不是某一种具体的技术。”本地优先的核心底线，就是无论网络连接是否通畅，无论软件开发商的服务器是否倒闭关闭，用户都永远能够不受干扰地继续开展他们的工作。 - 传统 SaaS 依靠数据锁定和绑架用户维系订阅，本地优先迫使软件回归以产品工具体验和真实价值驱动的商业逻辑。 - 当前不需要急于推进 IETF 级别的协议大一统，多样化探索有助于在复杂的分布式同步问题中找准工程权衡点。 - 本地优先的最高原则：软件必须同时具备强大的离线可用性，以及抗团队倒闭关服的“防御不可思议旅程”属性。 ## Notable quotes > [09:53](https://www.youtube.com/watch?v=NMq0vncHJvU&t=593s) 在我看来，如果软件在原始开发者破产、关闭所有服务器并停止支付 AWS 账单后就无法运行，那它就不是本地优先。 — Martin Kleppmann > [26:17](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1577s) 本地优先是一套原则和价值观，而不是某一种具体的技术。 — Martin Kleppmann > [07:21](https://www.youtube.com/watch?v=NMq0vncHJvU&t=441s) 在本地优先软件中，另一台计算机的可用性，永远不应阻止用户进行工作，它绝不应该阻塞用户 — Martin Kleppmann > [16:43](https://www.youtube.com/watch?v=NMq0vncHJvU&t=1003s) 由于在客户端本地离线运行的要求下，服务端本就不该承担任何业务逻辑或复杂操作，这就意味着我们完全有可能打造一个通用的同步服务，供大量截然不同的应用程序共同使用。 — Martin Kleppmann > [12:45](https://www.youtube.com/watch?v=NMq0vncHJvU&t=765s) 在理论上我确实可以自己托管服务器，但我真的想这么干吗？我可不想整天干维护服务器的营生，我的人生还有更有意义的事要做。 — Martin Kleppmann ## Mentioned Martin Kleppmann, Marc Shapiro, Leslie Lamport, Chad, Ink & Switch, Automerge, CRDT, Yjs, Ruby, Rust, Skiff, Notion, Google, Google Reader, Google Drive, Dropbox, iCloud, AWS, AWS S3, Microsoft Azure, GitHub, IETF, Our Incredible Journey, Killed by Google ## Video description Speaker: Martin Kleppmann, University of Cambridge, Inc & Switch We have come a long way since my colleagues and I published the local-first essay five years ago. In this talk I'll review where the local-first idea came from, where we are now, and what I hope the local-first community can work towards in the future. --- Learn from engineers, designers, academics, startups, and indie developers who are putting local-first into practice and reaping the benefits of a cloud-optional architecture. Join our discord! https://discord.com/invite/unjj72J6gH --- Subscribe for more talks: @localfirstconf Follow: https://twitter.com/localfirstconf Visit: https://www.localfirstconf.com --- Thanks to our wonderful sponsors: - DXOS - https://dxos.org/ (foundation layer for cloudless, collaborative software) - Heavybit - https://www.heavybit.com/ (leading investor in dev-first startups) - PowerSync - https://www.powersync.com/ (Postgres and SQLite sync layer) - Rocicorp - https://rocicorp.dev/ (creator of multiplayer and sync infrastructure) - Axil - https://axil.llc/ (agency focused on local-first software dev) - Affine - https://affine.pro/ (workspace merging docs, whiteboards, and databases) - CrabNebula - https://crabnebula.dev/ (creator of Tauri, for deploying web technologies as desktop apps) --- Thanks to https://sceal-studio.com/ for the videos! [Source](https://www.youtube.com/watch?v=NMq0vncHJvU)

[9:53] Martin Kleppmann: 在我看来，如果软件在原始开发者破产、关闭所有服务器并停止支付 AWS 账单后就无法运行，那它就不是本地优先。 [26:17] Martin Kleppmann: 本地优先是一套原则和价值观，而不是某一种具体的技术。 [7:21] Martin Kleppmann: 在本地优先软件中，另一台计算机的可用性，永远不应阻止用户进行工作，它绝不应该阻塞用户 [16:43] Martin Kleppmann: 由于在客户端本地离线运行的要求下，服务端本就不该承担任何业务逻辑或复杂操作，这就意味着我们完全有可能打造一个通用的同步服务，供大量截然不同的应用程序共同使用。 [12:45] Martin Kleppmann: 在理论上我确实可以自己托管服务器，但我真的想这么干吗？我可不想整天干维护服务器的营生，我的人生还有更有意义的事要做。

[7:20] Martin Kleppmann: The definition I will propose is that in local-first software, the availability of another computer should never prevent the user from working; it should never block the user. [12:45] Martin Kleppmann: In principle I could self-host the server, but do I really want to? Like, I don't want to be in the business of running servers; I have better things to do with my life.

[0:01] [Music] [0:07] thank you so much Chad and it's I can't [0:09] explain how how really excited I am to [0:12] be here in such a large room full of [0:14] people who are all interested in this [0:16] idea of local first and all want to help [0:18] make it happen so thank you so much for [0:20] as Chad said being pioneers and being [0:23] part of this movement I would like to [0:24] talk a little bit about where local [0:27] first came from at least from my very [0:28] subjective perspective [0:30] um do a bit of discussion about where I [0:32] think we are today in terms of um [0:35] understanding our the state of things [0:38] and then where I hope we can all work to [0:41] uh towards in the future over the coming [0:43] years so starting with the history um my [0:48] personal background and how I came to [0:49] this topic starts uh over 10 years ago [0:53] um so back in 2011 uh Mark Shapiro and [0:57] his colleagues published this uh [0:58] research paper on [1:00] replicated data types or cdts which if [1:03] you haven't heard about them don't worry [1:05] uh it's kind of not really Central to [1:07] the discussion here um but for me that [1:09] was kind of the starting point because [1:11] at the time I you know I was working in [1:13] industry but I was a bit frustrated with [1:16] the state of how we were building [1:18] software for the web uh and you know [1:20] software as a service and websites in [1:22] general um and I was looking around for [1:24] technologies that would help make things [1:26] better and I came across this paper uh [1:28] maybe in about 2013 or so I don't [1:30] remember precisely when um and I thought [1:33] ah this is this is interesting there [1:35] there seems to be the core of something [1:36] here I couldn't really articulate it [1:38] very well yet at the time um but I [1:42] wanted to start working on that properly [1:43] so I left my uh job in Industry um I [1:47] took some out some year out as a [1:49] sabatical and then moved into Academia [1:52] and I started working with uh cdts I [1:54] started writing my own crdt based text [1:57] editor in Ruby as it happens because [2:00] back in 2015 that was still a language [2:02] that some people used [2:05] um I'm sure some people still use it now [2:07] sorry I I I don't mean to be looking [2:10] down on anyone at all um and so it it [2:14] was a terrible piece of software you [2:15] know it it took two minutes to save a [2:17] file after you had edited but uh it it [2:20] was sort of a starting point for all of [2:21] this and then about [2:23] 2017 uh the folks at Inc and switch got [2:26] in touch with me and said well you know [2:27] you have this nice Theory work on C but [2:30] should we try building some software [2:31] that actually works with it and so uh I [2:34] got together with them and we built this [2:36] Library called automerge uh which was [2:38] initially in JavaScript and then I [2:40] maintained the JavaScript version for [2:41] several years um but then eventually [2:44] rewrote it in Rust uh and other people [2:46] are now maintaining that and I'm just [2:48] more of an adviser to the project um but [2:51] through all of this time we were lacking [2:53] an adjective we we wanted some adjective [2:56] to describe I I am building an xtype app [2:59] where X somehow represented the the [3:01] values and the principles that we were [3:03] trying to embody in these Technologies [3:05] so it wasn't really about the technology [3:07] per se it was about these values we were [3:09] trying to uh to represent in our [3:12] software and so after a bunch of [3:15] thinking we came up with this term that [3:17] we called it local first we considered a [3:19] bunch of Alternatives as well um but [3:21] this seemed to be like the the best we [3:23] had and we wrote this essay which [3:24] probably many of you have seen um so I'm [3:27] not going to recap the whole thing but [3:29] that came out uh pretty much exactly 5 [3:32] years ago and uh in this we tried to [3:36] articulate what we thought was [3:38] interesting about this new way of [3:39] building software uh and some of the [3:42] benefits that it would bring certainly [3:44] from the end user point of view and then [3:47] in the last five years of course things [3:48] have continued so as I mentioned Auto [3:50] merge got reuten in Rust it became [3:52] production ready uh we contined adding [3:54] more features Etc I'm not really going [3:56] to talk about Auto merge in this talk uh [3:58] Alex good later today will be giving [4:00] more of an update on automod [4:01] specifically but another thing that [4:03] happened uh over these years while we [4:05] were working on our little project was [4:08] lots of other people were also working [4:10] on all sorts of other projects related [4:11] to local first and this is not a [4:13] comprehensive survey by any means but [4:16] I've just tried to pull out at least a [4:18] bunch of uh software projects that [4:20] mention local first on their website uh [4:22] and so self-describe themselves as local [4:24] first or some of these don't explicitly [4:27] describe themselves as local first but I [4:29] think are sufficiently like aligned in [4:31] terms of philosophy that I put them on [4:32] here anyway and this is just to show [4:35] that you know it's it's actually become [4:36] a real movement you know it's it's not [4:38] just a small group of us writing [4:40] academic papers and doing a bit of [4:41] theory but this is this is actually a [4:43] very much real thing and it has grown [4:45] tremendously over the last few [4:47] years um and so this has then however [4:51] opened a lot of questions and in [4:52] particular as people have joined the [4:54] community they've asked very reasonable [4:55] questions like what exactly do you mean [4:58] with local first actually um the term [5:00] offline first had already been around [5:02] for a long time it predates uh local [5:05] first by at least six years or something [5:06] like that and obviously we were aware of [5:08] the term local uh offline first when we [5:11] coined the term local first and the [5:12] reason we coined a new term was because [5:14] we wanted to express something new [5:16] something more than offline first which [5:18] was not captured in the term offline [5:21] first and so I will go into that in a [5:23] moment of what what I think that [5:25] additional bit is um some people seem to [5:29] think that uh local first is just like [5:30] software that uses crdts which is one [5:33] way of looking at it but that's kind of [5:34] too narrow in my opinion because crdts [5:36] are just one technology and you could [5:37] use other Technologies as well to create [5:40] local first software um some people [5:42] think that local first means it has to [5:44] be peer-to-peer uh networking and you [5:46] can't have any servers at all which [5:48] again I think is not really the right [5:50] answer either um but we'll get into [5:52] that in terms of our attempt to Define [5:56] what local first is what we did in the [5:58] original uh local first essay was we [6:00] articulated these seven ideals um and [6:03] the idea we what we were trying to do at [6:05] the time to think well if you ticked all [6:07] of those seven boxes uh then you can [6:10] qualify as being local first software [6:12] but you could also imagine it you know [6:13] being a somewhat of a gradient where [6:15] there's uh a gray area of being like [6:17] somewhat local first but maybe not [6:19] satisfying all of these ideals um we've [6:22] now since then come to realize that [6:24] actually these seven ideals aren't [6:26] really a good definition of what local [6:28] first is the ideals actually more the [6:31] benefits that local first can bring [6:33] especially from the point of view of an [6:35] end user but it's not really a crisp [6:37] definition that allows you to say like [6:39] is this piece of software local first or [6:41] not um and so we've realized more [6:44] recently that there's a need to [6:45] articulate more precisely what it is we [6:47] mean and I want to propose one such [6:49] definition in this in this talk um and [6:53] we'll probably do a followup uh to the [6:55] local first essay uh sometime soon as [6:57] well to uh have it in written form [7:00] um the definition I will propose is [7:03] potentially up to some debate and people [7:05] might reasonably disagree with what I [7:07] will propose as a definition um but this [7:10] is sort of what we've come to this we [7:12] being the people who uh originally [7:14] published the local first essay and [7:16] among discussions among [7:18] ourselves um and so as a way of [7:21] introducing the new definition I want to [7:24] bring up Leslie Lamport some of you [7:26] might have heard of him he's if you're a [7:27] distributed systems nerd you probably [7:29] but you will have heard of him uh he won [7:32] the touring award back in 2013 I think [7:35] uh for his work on distributed systems [7:37] and he has this old quote old like you [7:39] know being from [7:41] 1987 in which he said in an email a [7:44] distributed system is one in which a [7:46] failure of a computer you didn't even [7:47] know existed can render your own [7:50] computer unusable may sound familiar if [7:53] you've ever tried to you know get [7:54] something done while GitHub was down or [7:56] while AWS was having a hissy fit or [7:58] something like that and half the [7:59] internet doesn't work um and so this is [8:03] kind of in some sense uh a good [8:06] capturing of what we were trying to get [8:08] at with local first and definition I [8:11] will propose is that in local first [8:13] software the availability of another [8:16] computer uh should never prevent the [8:19] user from working it should never block [8:20] the user [8:23] so let me unpack a little bit what we [8:25] mean with that um firstly one aspect of [8:29] local first is that it's not local only [8:32] software so if it's in know traditional [8:34] desktop software which only stores its [8:36] data in files on the local dis and [8:38] doesn't actually use the internet at all [8:40] you know it's sort of local first in a [8:41] technical sense but it's not not what we [8:44] really talk about here so what we think [8:46] is a an important part of the definition [8:48] of local first is that it's Multi-Device [8:50] software at least there is some sort of [8:52] data syncing happening from one device [8:53] to another this might be between [8:56] different users who are collaborating on [8:58] some data or it might be a single user [9:00] software but with the user having [9:02] multiple devices and syncing the data [9:04] between their own devices but so I would [9:06] say that this uh having it multi-devices [9:08] is definitely a prerequisite for uh [9:11] qualifying as local first [9:13] software secondly I said the [9:15] availability of another computer should [9:16] not stop you from working so [9:19] availability here includes the network [9:21] so if your network is down or if you [9:23] your Wi-Fi is off or you're somewhere in [9:25] a tunnel underground where you don't [9:27] have cellular data reception uh if the [9:30] software does not just continue working [9:33] then it's not local first in my opinion [9:35] and so that means offline first is a [9:38] part of local first uh you can't be [9:40] local first without being offline first [9:43] but that alone I think is not sufficient [9:45] to qualify as local first and the final [9:48] bit is this so in my opinion and there [9:51] might be some debate about whether this [9:53] is the right definition uh in my opinion [9:56] if the software doesn't work even if the [9:59] original developer of the software goes [10:00] out of business and shuts down all of [10:02] their servers and stops paying their AWS [10:04] bills then it's not local first so in [10:07] other words what we're trying to get at [10:08] here thank [10:11] you what what what we're trying to get [10:13] here is robustness not only against [10:17] availability in the network sense where [10:19] the network is down but availability of [10:21] another computer in the sense where that [10:23] computer actually fails because it's got [10:25] shut down and it's deleted all of its [10:27] data so you might be familiar with this [10:29] this ancient uh Tumblr blog called our [10:31] Incredible Journey which still exists [10:33] and still seems to be updated um in [10:36] which startups that have just got [10:38] Acquired and that are going to shut down [10:40] their product in three months time wax [10:42] lyrical about oh thank you users you [10:44] allowed us to have such an incredible [10:46] journey building this startup and [10:48] selling it and now we're going to screw [10:50] you all by just deleting all of your [10:52] data in a few months time and giving you [10:55] if you're lucky a zip file containing a [10:57] bunch of Json to download which you [10:58] can't important to any other software [11:00] and so uh well good luck with that [11:03] so um and so I think this is this is [11:07] really part of what motivated local [11:08] first and we didn't do a very good job [11:10] of explaining this in the original essay [11:12] which is why I want to really emphasize [11:14] it now um incidentally it also shows why [11:18] crdts in themselves are not sufficient [11:21] in order to make local first if you look [11:22] at the the top item here that is posted [11:25] there that is the shutting down of um a [11:28] service called skiff which got acquired [11:30] by notion uh skiff was like this end to [11:33] end encrypted Google Docs equivalent it [11:35] was built on yjs very good uh crdt [11:39] Library um but that didn't stop them [11:41] from appearing on our Incredible Journey [11:44] when they decided to get shut down so it [11:46] seems you need more than cdts you need [11:48] the entire application architecture to [11:51] be uh built accordingly of course it's [11:53] not just startups getting acquired big [11:55] companies shut down products all the [11:56] time as well uh so another website you [11:59] might might have seen is this one killed [12:00] by Google which cataloges almost 300 [12:03] products that Google has shut down over [12:04] the years including some very beloved [12:06] ones like Google Reader you might [12:08] remember so what we've been doing is [12:11] calling this uh making apps Incredible [12:14] Journey proof [12:15] so so [12:17] the what what what we want here is that [12:21] somehow at a fundamental level the [12:23] architecture of the software is [12:25] resilient against the creators of that [12:27] software just disappear ing um and in [12:32] particular it means the user shouldn't [12:33] lose any data um but also as far as [12:37] possible the functionality of the [12:38] application should continue working even [12:40] if any servers related to the [12:42] application are disappear and so this [12:45] this is bit of a challenge because you [12:46] know if you want to synchronize between [12:48] two devices there's usually a server [12:50] involved in the middle somewhere um and [12:53] well if this server is a proprietary [12:54] server that only the makers of the [12:56] software can run because only they have [12:58] the code uh to do though that's not [13:01] really local first in my opinion because [13:04] um you know it's that there's no way for [13:06] users to recover from the the failure of [13:09] that server you can improve things a bit [13:12] uh by at least having a an open- Source [13:14] server that people can self-host and [13:18] it's not really a great solution because [13:21] uh self-hosting is uh it's only [13:24] accessible to people with the [13:25] appropriate technical skills uh which is [13:27] already a very small fraction of the [13:28] population [13:29] um and then even among people with the [13:32] technical skills like in principle I [13:33] could self-host the Ser but do I really [13:35] want to like I I don't want to be in the [13:37] business of running servers I have [13:38] better things to do with my life so um [13:41] so I feel that self-hosting is it's you [13:43] know it's a a small bit of an answer but [13:46] it's not really a complete answer to [13:48] making software Incredible Journey proof [13:51] another thing that people propose is [13:52] peer-to-peer networking and in theory [13:54] this is really appealing because [13:55] peer-to-peer means that you can just uh [13:58] connect two devices and multiple devices [14:00] and have them synchronize some data [14:02] without involving any servers at all or [14:04] maybe just involving some general [14:06] purpose DHT in the sky or something of [14:08] that sort um but the practice is it's [14:12] actually still really difficult to make [14:14] peer top software good um this is [14:17] something that you know a lot of people [14:18] have put a huge amount of effort into [14:20] and they think it's still unsolved [14:21] problem um part of it is just the fact [14:25] that the two devices have to be online [14:26] at the same time in order to talk to [14:28] each other that's kind of fundamental [14:29] thing um but then also partly just [14:32] because of the way the internet works [14:33] nowadays and there's natat and firewalls [14:35] and all sorts of things that get in the [14:36] way of uh establishing peer-to-peer [14:39] connections and so you need these [14:41] elaborate dances like signaling in order [14:44] to introduce the two devices to each [14:45] other but then you need a server in [14:47] order to do that signaling and then also [14:49] if you want to then uh be robust you [14:52] need some sort of fail back in a [14:54] fallback in in in case the direct [14:56] connection between the devices fails so [14:58] you need a turn Service as well and now [15:00] you've got these servers for signaling [15:03] and turn which then raises the question [15:05] of you know why don't you just use those [15:07] servers to do the actual data [15:08] synchronization anyway if you've got [15:10] servers anyway you might as well use [15:11] them [15:13] so my my feeling is that maybe [15:15] peer-to-peer will will get better with [15:17] more people working on the technology [15:18] but right now it seems to me that uh [15:20] it's a lot of complexity for Fairly [15:22] little [15:24] benefit but what we could do maybe is to [15:27] rely on other services [15:29] so you could imagine for example that [15:32] you have your local first app say it's a [15:34] local first spreadsheet or whatever and [15:36] it stores its data not on your own [15:39] servers not on the app developer servers [15:42] uh but in some general purpose Cloud uh [15:45] storage service like Dropbox or Google [15:46] drive or iCloud or whatever you like um [15:49] this is not really ideal as well for a [15:51] number of reasons uh in theory of course [15:53] that cloud service could also go away [15:55] although I have higher confidence that [15:58] say Google Drive will still exist in 10 [16:00] years time compared to your random twers [16:03] startups Uh custom service still [16:05] existing in 10 years time um I I don't [16:09] mean to uh underestimate your ambition [16:11] or anything like that but just looking [16:13] at prior experience that's uh hopefully [16:16] a a fair assessment um another thing is [16:20] also that uh all these cloud storage [16:22] services are really file storage service [16:24] so they don't really work very well for [16:25] real-time collaboration if you want to [16:27] like see other people cursors and mouse [16:29] positions in real time and so on then [16:32] doing that sort of thing uh via a file [16:35] storage Server doesn't really work very [16:37] well but it seems to me like this is [16:39] more a promising Direction This is a a a [16:42] thread that we can pull [16:43] on so what about this as a longer term [16:48] vision for where uh local first software [16:51] should go and this is I think where we [16:52] move to the Future Part of the talk is [16:56] uh consider you have a number of local [16:59] first apps written all by different [17:00] software developers so maybe there's a [17:02] local first spreadsheet and a graphics [17:04] app and some sort of task management app [17:06] and many other apps and a user has these [17:09] apps installed on their phone and also [17:10] has these apps installed on their laptop [17:12] and so now you need some sort of [17:13] synchronization between those but part [17:16] of the idea of local first is that uh [17:20] all of the interesting logic lives on [17:22] the client side uh in in the users app [17:24] you know in the software that actually [17:26] runs on the users devices which means [17:29] that any synchronization that happens [17:31] between them should be like a really [17:34] simple matter it should be just a matter [17:36] of getting some bites over the wire from [17:37] one device to the other device because [17:40] you shouldn't be doing any any sort of [17:41] business logic or anything particular [17:43] complex in the server anyway um if you [17:46] want all of the software to continue [17:48] working uh offline locally on the user's [17:51] client which suggests that it should be [17:53] possible to have a generic syncing [17:56] service that can be used by a whole [17:58] bunch of different [18:00] applications and now this is where [18:01] things get really [18:03] interesting this syncing service here if [18:06] we it's doesn't exist yet but this is [18:08] why I'm talking about the future um the [18:11] syncing Service uh should be able to [18:14] exchange the data uh perform the [18:17] synchronization regardless of the data [18:19] model and the file types of the [18:21] applications on top of it um because it [18:23] should be a fairly simple protocol that [18:25] is just moving some bytes back and forth [18:27] and uh [18:29] in fact what I will hope we will move [18:31] towards is as as we figure out what the [18:34] syncing service should look like we can [18:36] actually standardize the protocols that [18:38] the syncing service uses uh in such a [18:41] way that it's app independent and that a [18:44] large community of people agrees on like [18:46] this is a good general purpose protocol [18:48] to use and then we can have multiple [18:50] oper multiple different implementations [18:52] of that protocol made by different [18:54] people and they can all interoperate [18:55] with each other and you should be able [18:56] to then take a local first app that's um [19:00] that is maybe currently pointed at one [19:02] particular syncing service say in some [19:04] hypothetical future AWS runs a syncing [19:07] service for local first apps just in a [19:09] way they run F3 today um and you know if [19:14] you want to sign up for that you can pay [19:16] AWS a small amount of money you know [19:18] just charge it by the gigabyte as they [19:20] do for S3 and uh and point your local [19:23] first apps at that syncing service but [19:26] you know if something happens if uh [19:28] whatever Amazon decides to shut it down [19:30] or change it in some way or just decides [19:33] to make it too expensive or whatever you [19:35] should be able to just point your apps [19:37] at the equivalent service run by Azure [19:39] and if they're following an open [19:41] standard protocol you should be able to [19:42] just point your app to a different [19:44] service by just changing a single [19:46] configuration flag in your app uh and [19:48] everything else should just continue [19:50] working and the app developers in [19:52] particular don't need to worry about [19:53] which syncing service you're using uh [19:56] because it has then just become this [19:57] commoditized piece of infrastructure so [20:00] the interoperability between different [20:03] uh syncing Services is what makes this [20:06] valuable then um and because there yes [20:10] because all of these different syncing [20:11] Services can speak the same protocol and [20:14] if we have this general purpose sying [20:16] service now it makes sense to add peer [20:18] top into the mix again because I think [20:20] peer top is amazing when it works [20:22] especially for example if you've got two [20:24] devices sitting right next to each other [20:26] on the same table it's ridiculous that [20:28] all of the data synchronization should [20:30] go via U uh AWS Us East one in Virginia [20:35] when in fact you've got them sitting [20:36] right next to each other okay so using [20:38] the local network when it's available or [20:41] opportunity opportunistically using [20:43] local uh using peer-to-peer networks [20:45] even over the Internet when they're [20:47] available is great as long as it's just [20:49] not relying on that as the soul thinking [20:51] mechanism and then this again provides [20:53] additional robustness because the [20:56] situations in which the cloud service [20:57] fails will probably be different in the [20:59] situ from the situations in which the [21:01] peer-to-peer sync fails and so if we can [21:03] have both well then it would just gain [21:05] robustness overall uh we gain robustness [21:08] against both peer-to-peer failures and [21:10] uh cloud service failures so this seems [21:13] to me like a very promising way of [21:16] achieving this goal of being Incredible [21:18] Journey proof uh to have multiple [21:20] interoperable Sy providers now obviously [21:23] we're not there yet and I'm not [21:24] pretending we are there um but this is [21:26] something that I hope we can work work [21:29] towards [21:30] um now I think this architecture in [21:34] which we make this um this uh [21:38] synchronization service for local first [21:39] a kind of piece of commoditized [21:42] infrastructure has a huge set of [21:44] benefits for not just the end users but [21:48] also for the people developing the [21:50] application software and this is another [21:52] piece that we missed in our original [21:55] local first essay 5 years ago uh that [21:58] say Focus very much on the benefits from [22:00] the point of view of the end user which [22:01] is important um but since then we've [22:05] come to realize that actually the [22:07] benefits to the app developer are [22:09] perhaps at least as big as those to the [22:12] end user um one of the really big ones [22:16] is that as an app developer if if you [22:18] adopt this kind of architecture where [22:20] the thinking service is just some [22:22] general purpose piece of infrastructure [22:24] is the app developer doesn't need that [22:26] me need their own uh backend engine [22:28] engineering team anymore this is you [22:30] know a huge amount of complexity that [22:33] currently startups have to take on in [22:35] order to build not only you know the [22:38] using fa user facing parts of their [22:40] product but also hire a bunch of people [22:43] who can write cloud services and who [22:45] know how to operate uh aws's weird [22:48] configuration and who know how to do [22:50] devops and uh all of this stuff in [22:55] particular all of also all of these [22:56] backend people who then have to take [22:58] shifts uh for on Call rotation to be [23:01] available 24/7 because again if all of [23:04] the back end is just somebody else's [23:06] problem then uh well the you as app [23:09] developers just don't have to worry [23:11] about it [23:12] anymore and I think this is a huge deal [23:14] because it means then app developers can [23:17] focus on the parts of the app where they [23:19] are distinctive that is the building [23:21] really good user interfaces and user [23:23] interactions and making sure that the uh [23:27] the the um the purpose that the app is [23:31] serving you know the the end users are [23:33] very well served by the by the app they [23:36] are building um and none of that is [23:38] specific to uh to building backend [23:41] Services you know the the backend [23:42] service is is an entirely separate [23:44] concern and you can have a separate team [23:45] that then specializes in running a [23:48] really good syncing service and [23:49] providing that as a service to the rest [23:51] of the uh [23:53] ecosystem another benefit to app [23:55] developers with the local first approach [23:58] is that actually just the app [23:59] development model becomes a whole lot [24:01] simpler uh compared to the traditional [24:04] approach of building Cloud software [24:05] because with Cloud software you're [24:07] constantly making these Network calls um [24:10] from the browser to the back end and you [24:11] have to worry about what if the user is [24:13] on a spotty Wi-Fi and so the call times [24:16] out and then how do you communicate that [24:17] back to the user and actually um we've [24:21] seen again and again with people [24:23] building local first apps one of the [24:24] things they love about it is that they [24:26] don't have to write all of this network [24:27] error handling code [24:29] uh because the synchronization protocol [24:31] is again just runs in the background [24:33] it's a piece of off the-shelf [24:34] infrastructure you just pick a library [24:36] off npm and you're done um and you app [24:40] developers don't have to worry about [24:42] that and then finally of course Us app [24:43] developers don't have to worry about [24:45] paying for cloud services if if this is [24:46] a separate service that the uh that the [24:49] users sign up for [24:51] directly so overall it just gives us [24:54] this uh picture of app development [24:56] becoming radically simpler and that [24:58] changes the whole economics of software [25:00] development and that is perhaps one of [25:02] the deepest effects I think that I I [25:05] think local first is going to have uh [25:08] it's not about a particular technology [25:10] it's about changing the economics of [25:13] software allowing smaller teams to get [25:15] more done um and building more [25:19] impressive apps with fewer people and [25:21] therefore with less capital and so that [25:24] then has a whole bunch of exciting [25:26] implications it becomes economically [25:29] feasible for um for smaller teams uh to [25:33] build really Niche apps that serve a [25:36] small number of users really well and uh [25:39] and that's fine because even though [25:41] those smaller number of users won't [25:42] generate a huge amount of Revenue but if [25:45] you're not trying to build a you know [25:46] Venture funded huge uh you know hundreds [25:50] of millions of users type app um you if [25:53] you can build something with a small [25:55] number of people it's fine to uh have a [25:58] user base but that is that finds the [26:00] product really valuable and also uh it [26:04] seems to work very well for prototyping [26:05] as well so we've seen people build [26:07] impressive prototypes of collaborative [26:09] apps within a week or so using local [26:11] first Technologies and a lot of that is [26:14] down to just the programming model being [26:16] so much [26:17] simpler now the uh challenge the biggest [26:22] challenge that I see for local first for [26:24] the future is also an economic one and [26:27] so the counterpart here to this [26:30] opportunity uh I think is whether the [26:32] business model the traditional business [26:34] model of software will still work in the [26:37] in the local first [26:39] era I I think and I hope that it will uh [26:42] that in some sense you can just say it's [26:44] the same business model as SAS you pay a [26:47] subscription um but of course with the [26:49] traditional model of SAS uh you know app [26:51] developers have this gun that they can [26:53] point at the user's head and say you [26:55] know you have some nice data here it [26:57] would be a shame if you lost all of that [26:58] data wouldn't it be so how about you pay [27:00] up and pay pay your subscription so that [27:03] we don't go and delete all your data and [27:05] of course in the local first world if if [27:06] you're following this idea of being [27:08] Incredible Journey proof then that [27:10] doesn't work anymore because the users [27:11] can just take their data somewhere else [27:13] so what uh what is in startup jargon [27:16] called the moot the data Moote is is [27:18] weakened in in local first software it [27:21] might be that that's not a problem it [27:23] might be that actually we can just say [27:24] you know we're selling software on the [27:27] basis that it of the that it provides to [27:29] users not on the on the basis of you [27:32] know holding users Ransom um but I hope [27:35] that will be one of the topics for [27:36] discussion today of how we can Bridge [27:39] these uh the economics and these [27:41] challenges so in terms of the [27:44] Technologies for actually making this [27:46] obviously I mentioned that uh I've been [27:47] involved in the automerge project for a [27:49] long time but there are many other [27:50] projects as well and I'm very [27:52] open-minded to lots of people uh [27:54] building different Technologies and I [27:55] think that's a great thing that there's [27:57] such Lively ity in this ecosystem [27:59] because I think the the simple answer is [28:01] we don't know yet what will work and [28:03] what won't work and so the uh we need [28:07] those uh thousand flowers blooming so [28:10] that we can uh just gain experience of [28:12] different approaches and understand the [28:14] trade-offs better so I'm really excited [28:16] that so many of you are helping build [28:17] this ecosystem and trying lots of [28:19] different approaches and [28:21] experimentation I think right now it's [28:24] too early to go to the ietf and start [28:26] standardizing the protocol that we can [28:27] use for this generic syncing Service uh [28:30] because right now I think we don't [28:31] understand the trade-offs well enough [28:33] yet but I think in a few years time we [28:35] will understand it and then then at that [28:37] point uh we can you know start found [28:39] founding our standardization committee [28:41] and stuff like that so I think we will [28:43] get to that but fundamentally what I [28:45] want to get across is that local first [28:46] is a set of principles and values it's [28:48] not any one technology um but I do [28:51] believe that these principles and values [28:53] lead us to a better way of building [28:55] software in the future uh and this is [28:58] really the the core of it to leave you [29:00] with this um that we want to make sure [29:03] that the users can always continue doing [29:06] their work regardless of whether they [29:08] have an internet connection and [29:09] regardless of whether the servers of the [29:11] software developer disappear we wanted [29:13] to be incredible journey proof as well [29:15] as being offline capable that's it from [29:18] me thank you so much for listening and [29:19] enjoy the day [29:29] excellent talk and amazingly [29:34] [Applause] [29:34] [Music]