几周前，我看了马丁·克莱普曼(Martin Kleppmann)关于CRDTS的演讲，我感到了深深的绝望。也许我在过去十年中所做的所有工作终究不会成为未来的一部分，因为马丁在CRDT方面的工作将取代它。真的很好吃。
2010年左右，我在Google Wave上工作。Wave试图建立可协作编辑的空间，以取代电子邮件、Google Docs、网络论坛、即时通讯和上百个其他小型单一用途应用程序。Wave在我的工具中有一个我喜欢的属性，这是我在任何地方都没有见过的：它是一种通用的媒介(如纸张)。与许多其他工具不同，它不会强迫您进入它自己的工作流。你可以用它来做任何事情，从计划假期，做一个维基，和你的朋友一起玩D&A；D；D，安排一个会议，等等。
在内部，Wave的协作编辑建立在操作转换(OT)之上。OT已经有一段时间了-我们使用的算法是基于1995年的原始木星论文。它的工作方式是为每个更改的每个文档存储一个按时间顺序排列的列表。“在位置0处键入H”。“在位置1处键入a i”。等。大多数情况下，用户正在编辑文档的最新版本，操作日志只是所有更改的列表。但是，如果用户进行协作编辑，我们就会获得并发编辑。发生这种情况时，到达服务器的第一个编辑将照常记录。如果第二次编辑已过期，我们将使用操作日志作为参考，以确定用户真正想要的是什么。(通常这只意味着更新字符位置)。然后，我们假装这就是用户一直以来的意思，并附加新的(编辑过的)操作。这就像实时git-rebase。
Wave死后，我在ShareJS中重新实现了OT模型。这是在诺德还是个新人和怪异的时候。我想在NPM推出之前我已经让ShareJS正常工作了。只需要大约1000行代码就可以运行一个简单的协作编辑器，当我第一次演示它时，我在浏览器和本地应用程序中协作编辑了一个文档。
从本质上讲，OT是一个美化了的for()循环，它具有一些用于更新字符偏移量的助手函数。在实践中，这非常有效。OT简单易懂。实现速度很快。(每秒10k-100k次未经优化的javascript操作。在优化的C中为1-20兆次/秒。)。唯一的存储开销是操作日志，如果您愿意，可以将其削减。(不过，如果您这样做了，您就不能合并超旧的编辑内容)。您需要一个集中式服务器来全局订购操作，但是大多数系统都有一个集中式服务器/数据库，对吗？
OT的最大问题是对集中式服务器的依赖。你有没有想过，当一个文档被分享到社交媒体上时，为什么google docs会给你显示一个奇怪的“这个文档超载，所以编辑被禁止”的东西？原因(我想)是因为当你打开一个Google文档时，会选择一台服务器作为运行所有编辑的计算机。当暴徒降临时，谷歌需要出一堆把戏，这样电脑才不会变得不堪重负。
他们可以使用一些解决方法来修复此问题。除了按文档分片(如google docs)外，您还可以通过围绕数据库事务的重试循环进行编辑。这会将序列化问题推到您的数据库中。(FirePad和ShareDB的工作方式是这样的)。
不过，这并不完美。我们希望Wave取代电子邮件。电子邮件是联合的。一个电子邮件线程可以跨越多个公司，而且一切都很正常。与Facebook Messenger不同，电子邮件只发送给抄送的公司。如果我给我的同事发电子邮件，我的电子邮件不会离开大楼。为了让Wave取代电子邮件，我们需要同样的功能。但这怎么能在OT之上起作用呢？我们让它工作了，有点，但它很复杂，而且有问题。我们最终得到了一个方案，在该方案中，每个wave都会排列一个wave服务器树，操作在树上上下传递。但它从未真正起作用。就在不到10年前，我在Wave协议峰会上做了一次演讲，解释了如何接入网络。我练习了那次演讲，并做了一个完整的排练。我真的一步一步地跟着走了一天，我现场制作的版本不起作用。我还是不知道为什么。无论错误是什么，我认为开源版本中都没有修复过。这一切都太复杂了。
请记住，使用的算法Wave是在1995年发明的。那是很久以前的事了。我想我在1995年的时候家里甚至连互联网都没有。从那时起，研究人员一直忙于试图让OT更好地工作。最有希望的工作是使用CRDT(无冲突复制数据类型)。CRDT处理问题的方式略有不同，允许实时编辑，而不需要中央真理来源。马丁在他的演讲中比我更好地阐述了它们是如何工作的，所以我就跳过细节。
多年来，人们一直在问我对他们的看法，我的回答总是这样的：
它们很整洁，我很高兴人们在做它们，但是：
他们动作很慢。就像，真的很慢。例如，Delta-CRDTS需要近6个小时来处理一个真实世界的编辑会话，只需一个用户输入一篇100KB的学术论文。(基准-查找B4。)。
由于CRDT的工作方式，文档可以不受约束地增长。当前的Automerge Master需要83MB来表示磁盘上100KB的文档。你能删除那些数据吗？大概不会吧。而且这些数据不能仅仅停留在磁盘上。需要将其加载到内存中以处理编辑。(为此，Automerge的内存目前增长到1.1 GB。)。
CRDT缺少OT多年来拥有的功能。例如，还没有人创建支持/Object Move/(将某物从JSON树的一个部分移动到另一个部分)的CRDT。您需要在Workflow这样的应用程序中使用它。不能很好地处理这件事。
我提出了所有这些批评，并驳回了CRDT。但在这样做的过程中，我停止了对文学的跟踪。还有-惊喜吧！CRDT过去了，并悄悄地好转了。马丁的讲话(非常值得一看)谈到了要点：
速度：使用现代CRDT(Automerge/RGA或y.js/yata)，只需log(N)查找就可以应用操作。(有关这一点的更多信息，请参见下文)。
大小：Martin的列式编码可以存储文本文档，与内容本身相比，其开销仅为1.5倍-2倍。马丁在54分钟的演讲中谈到了这一点。在Automerge中实现这一点的代码还没有合并，但YJS实现了马丁的想法。这样，YJS可以将同样的100KB文档以160KB的大小存储在磁盘上，或将其存储在3MB的内存中。好多了。
特点：至少有一种理论上的方法可以使用倒带和回放来添加所有的功能，尽管还没有人实现这一功能。
复杂性：我认为一个像样的CRDT会比同等的OT实现大，但不会大很多。马丁仅用了大约100行代码就成功地实现了一个微小而缓慢的Automerge。
我仍然没有完全被速度的论据说服，所以我使用Automerge的思想，使用B-tree对Rust中的CRDT实现做了一个简单的概念证明，并对其进行了基准测试。它缺少的功能(删除字符、冲突)。但它每秒可以处理600万次编辑。(每次迭代由一对交替的用户对空文档进行2000次编辑，耗时330µs。因此，每秒插入606万次)。这意味着我们已经将CRDT做得足够好，CRDT和OT之间的速度差异小于Rust和Javascript之间的速度差异。
所有这些改进在Automerge的性能部门“即将到来”已经有很长一段时间了。但Automerge并不是市场上唯一像样的CRDT。Y.js运行良好，在Y.js基准测试中揭开了Automerge当前实现的序幕。它缺少一些我想要的功能，但是修复一个实现通常比发明一个新算法更容易。
我很关心发明未来。100年后没有什么是荒谬的呢？显然，我们会进行实时编辑。但我不再相信OT-以及我在这方面所做的所有工作-还会存在。我对此感到非常难过。
现在到处都在使用JSON和REST。比方说，在15年内，实时协作编辑无处不在。实时编辑的JSON等价物是什么，任何人都可以直接将其放到他们的项目中？在辉煌的未来，我们将需要高质量的CRDT实现，因为OT不适用于某些应用程序。你不能用OT制作Git的实时版本，也不能简单地翻拍Google Wave。但是，如果我们有好的CRDT，我们还需要好的OT实现吗？我不相信我们会这么做。OT的每一项功能都可以放入CRDT中。(顺便说一句，包括修剪操作)。但事实并非如此。聪明人不同意我的观点，但如果我们有一个好的，快速的CRDT，可以在每种语言上使用，并在网络上集成，我认为我们根本不需要OT。
OT的一个优势是它很适合集中式软件--这是当今大多数软件。但是分布式算法在集中式软件中也很有效。(如看吉瑟布)。我认为在WASM中运行真正高质量的CRDT会比在JS中实现OT更快。即使你只关心集中式系统，请记住--由于OT的限制，Google在使用Google Docs时遇到了可伸缩性问题。
所以我认为现在是我们做一个精简而快速的CRDT的时候了。学术工作已经基本完成。我们需要更多令人振奋的实现。
我越来越不喜欢集中式软件的世界了。在我的电脑上，软件与我的数据交互。现在是我的软件反映这种关系的时候了。我想让我的笔记本电脑和手机通过WiFi共享我的文件。而不是把我所有的数据上传到另一个国家的服务器上。尤其是如果那些服务器是由竞购我眼球的广告商资助的。
从哲学上讲，如果我修改一个Google文档，我的计算机就是在请求Google允许编辑该文件。(你可以看出来，因为如果谷歌的服务器说不，我就会丢失我的更改。)。相比之下，如果我将GIT推送到GitHub，我只会通知GitHub有关代码更改的信息。我的储藏室就是我的。我拥有所有的零件，以及容纳它们的所有硬件。这就是我希望我的所有软件都能工作的方式。多亏了像马丁这样的人，我们现在知道如何制作好的CRDT了。但在本地优先软件成为默认软件之前，仍有很多代码需要编写。
所以运营转型，我想这是我的告别。我们度过了一些美好的时光。我所编写的一些最具挑战性、最有趣的代码是操作转换代码。你很聪明，很迷人，但是CRDT可以做你永远做不到的事情。而CRDTS需要我。通过一些好的实现，我认为我们可以做出一些非常特别的事情。
我对这些年来我在OT上所做的一切工作表示哀悼。但OT不再符合我对未来的愿景。CRDT可以让我们重新制作Wave，但是更简单更好。他们会让我们编写软件，将用户视为数字公民，而不是数字农奴。这很重要。