@ThirdFlame playground 是分两栏模拟多用户，真实的 editor 协同页面只有一栏。目前预估 15 人同时编辑会比较丝滑，需要真实环境测试一下

@Leon6868 稳定复线，会尽快修复，非常感谢

@Leon6868 Knuth–Plass 看上去更适合阅读场景和导出场景，编辑场景支持可能比较困难。流式输出过程中目前是禁用了用户操作，底层是支持的，后续会开放。针对流式输入还有一个想法，把 AI 流式输入设计成一个协作者，可以直接召唤 AI 修改文档，AI 协作的同时，人可以直接选择修改已经输出完的文字。理论上可以支持多人多 AI 一起协作修改文档

@SummerGrow 真很刑的话就算了，阅后即焚、双方加密也没什么用吧

交钱，省心，一劳永逸

@edisonwong 对的

@xuld 感谢反馈，会尽快修复

tailscale 还发现有一个优点，目前 Mac 屏幕共享通过公网是无法开启高性能模式的，但是走 tailscale 可以开启

@Maxwe11 很可以。不过一直开着 tailscale 也挺麻烦，可能会跟梯子打架。可以试试 HomeKB ，直接把 Markdown 文件丢进.homekb/notes 就可以直接编译了。

@garyox64 最大的区别就是，DOMD 不是在 Tiptap / ProseMirror 上改出来的，而是从零按照 Markdown 编辑器设计了一套架构。

所以像 AI 增量流式输入、段落内 CRDT 合并这些能力，不是后来为了赶 AI 需求硬打进去的补丁，而是底层数据结构本来就适合做。少了通用富文本框架的负担，包更小、链路更短，输入和渲染同步，编辑起来更跟手，也几乎没有多一帧的抖动。

更底层一点，粗略类比的话，ProseMirror 这类 transaction-driven 编辑器更接近命令式更新，也可以理解成一套基于 schema 和 transaction 的编辑数据库：每次插入、删除或修改格式，都要表达成明确的操作。

DOMD 的思路则更接近 React 的声明与 reconciliation：不是逐条控制这次具体改了哪个节点，而是重新声明当前 Markdown ，再由 diff/reconcile 自动找出需要复用和更新的部分。

不过 Mermaid 、LaTeX 肯定还是要适配

@ivyliner 目前是要就给，大概流程是把你的产品告诉我，我让 AI 出一份具有法律意义的授权文案

@ota 随着版本迭代，GFM 是要做到 100%支持的

@ota GFM 支持度大概是 80%。HTML 暂时屏蔽了，后续优化编辑体验后会开放

@wang93wei 无法加载你们的图片，是我梯子的原因吗？

@Sezxy 直接输入应该不行（有一个快捷键，不过被浏览器吞了），可以粘贴一个表格文档试试，或者直接拖拽一个 md 到页面中

@Sezxy 偶先过，我尽快修复

@jokcylou 有在慢慢支持和开放

@shuimuzi 目前是通过插件的形式直接将内核操作产生的 patch 翻译成 yjs 的 OP ，产生 CRDT 数据。内核架构层不感知 yjs 和 CRDT ，理论上可以切换到其他的 CRDT 引擎

@TArysiyehua 确实，我后面加一下。现在想体验性能的话，可以直接拖一个 md 进去，是可以直接渲染编辑的，或者复制粘贴一段文本