即刻App年轻人的同好社区
下载
置顶Loro 1.0 版本发布了！你可以用它实现实时协作、版本管理以及创造本地优先应用。
我们花了很大功夫在 API 设计上，现在这可能是同步文档（可支持富文本同步，以及任意 JSON schema 的数据同步）的最简洁易用的方案之一。最少一轮数据交换就能保证任意两个 peers 的文档达到一致性。
并且 Loro 性能非常优秀，就算是针对数百万字符的文档，所有操作在 CRDT 上的开销也都在一帧内，保证了高上限。在 Loro 上操作字符串的速度比直接操作 JS string 还快。
我们还记录了完整编辑历史，还允许用户创建出分支，支持分支自动合并，支持快速切换到不同的版本。我们的 Demo 还导入了 Loro 自身的完整代码库历史到由 Loro 驱动的版本管理器上。
我们的 CRDT 文档导入速度现在也得到极大提升。现在导入文档的主要开销甚至是在 xxhash32 的完整性验证和解压缩上。
发布之后被偶像转发了，开心 😆
loro.dev
我们花了很大功夫在 API 设计上，现在这可能是同步文档（可支持富文本同步，以及任意 JSON schema 的数据同步）的最简洁易用的方案之一。最少一轮数据交换就能保证任意两个 peers 的文档达到一致性。
并且 Loro 性能非常优秀，就算是针对数百万字符的文档，所有操作在 CRDT 上的开销也都在一帧内，保证了高上限。在 Loro 上操作字符串的速度比直接操作 JS string 还快。
我们还记录了完整编辑历史，还允许用户创建出分支，支持分支自动合并，支持快速切换到不同的版本。我们的 Demo 还导入了 Loro 自身的完整代码库历史到由 Loro 驱动的版本管理器上。
我们的 CRDT 文档导入速度现在也得到极大提升。现在导入文档的主要开销甚至是在 xxhash32 的完整性验证和解压缩上。
发布之后被偶像转发了，开心 😆
loro.dev
26 12
刚看到有人在 ATProtocol 上用很简单的设计支持了给任意网页留评论的能力。bsky.app
这种原本看似有点复杂度的东西现在不仅容易实现，而且还直接能继承用户的 Social Graph（扩展社交应用的场景就不再有社交关系的迁移成本，而且整个协议是开放、不受平台控制的），还能不用专门设计就让用户能掌握对个人数据的控制权。
ATProtocol 能触及的生态和场景太广了，非常期待它开启的未来。
这种原本看似有点复杂度的东西现在不仅容易实现，而且还直接能继承用户的 Social Graph（扩展社交应用的场景就不再有社交关系的迁移成本，而且整个协议是开放、不受平台控制的），还能不用专门设计就让用户能掌握对个人数据的控制权。
ATProtocol 能触及的生态和场景太广了，非常期待它开启的未来。
2 40
github.com 官方整理了一份可以在 AT Proto 上整活的方向 //@水上骑士: 能整点啥花火活呢😂
zxch3n: 这两天研究了下 Bluesky 背后的 AT Protocol。 AT Protocol 当中，每个用户的数据都被放在一个用户仓库里面，这个仓库被称为User Repository。 这个用户仓库是对外完全公开的。这个用户仓库也可以被托管在用户自行选择的 Personal Data Server （PDS）上。社交平台上的用户操作以这个 user repository 为 the source of truth。例如，一个帖子有点赞、评论和转发这些数据，但它其实不是 the source of truth，真正的 source of truth 是每个用户的 repository。像 Bluesky 这样的平台，要去把全网的用户仓库进行 indexing（有点像搜索引擎在做的事情），才能得到一个帖子最终的点赞数量以及有哪些评论。例如转发，它其实真正的 source of truth 在用户仓库里会有一个索引到那个帖子的全局唯一 ID 的转发操作。 AT Protocol 借鉴了 Web 本身的特点：真正的数据源来自网站/用户仓库，类似 Bluesky 这样的应用则类似搜索引擎，在完成需要的索引和内容过滤后给用户提供他们需要的视图。 AT Protocol 也不仅仅是为了类似 Twitter 这样形式的社交媒体构建的，它还可以被扩展支持长文博客、音乐收藏夹、类似 Reddit 的论坛等等。而背后的 user identity，用户的关注/被关注信息，用户存储的数据都可以在这些不同的 apps 上复用。并且他们还专门提供了一种 Schema 定义的语言 Lexicon，来让不同应用之间的数据交换变得更简单并且可靠。但目前的限制是被扩展的应用场景上用户是希望数据公开的，因为每个用户仓库就是全网公开的。 AT Protocol 不是第一个做跨应用数据共享，或者是去中心化身份，以及支持 PDS 的事情的。Solid Project 从六七年前开始就在做类似的事情，但是不接地气，例如它要求应用存数据的格式是一个非常小众的描述语言从而才能更好地跨应用共享数据，和大部分开发者的习惯差距很大，所以很难流行起来。 AT Protocol 还考虑了审核和内容过滤的问题。2021 年 AT Protocol 的设计者之一 Martin Kleppmann 写了一篇文章 Decentralised content moderation。在文中他提出 censorship resistance 的去中心化社交平台的设计太过天真，因为不受控制的内容平台必然会充斥暴力，色情，以及垃圾信息。而真正需要的是去中心化的 moderation 机制。这也成为了 AT Protocol 中首要的设计目标之一。 所以在 AT Protocol 中，社区可以第三方的 Labeler （用于标记垃圾信息，暴力色情内容） 和 Feed generator （生成推荐流）。而每个终端用户能够自行选择自己需要的内容。 Bluesky 虽然目前是最主要的 AT Protocol 的实现者和服务提供平台，但是它没有特权。每个组件都可以由社区构建： - Relay 服务：订阅转发用户的操作的服务 - Personal Data Servers - Feed generators - Labelers - Client 他们还给了很好的文档和工具来让开发者开发基于 AT Protocol 的应用。最近 Bluesky 增长很快，貌似是个好时候整点活。
0 00
这两天研究了下 Bluesky 背后的 AT Protocol。
AT Protocol 当中，每个用户的数据都被放在一个用户仓库里面，这个仓库被称为User Repository。
这个用户仓库是对外完全公开的。这个用户仓库也可以被托管在用户自行选择的 Personal Data Server （PDS）上。社交平台上的用户操作以这个 user repository 为 the source of truth。例如，一个帖子有点赞、评论和转发这些数据，但它其实不是 the source of truth，真正的 source of truth 是每个用户的 repository。像 Bluesky 这样的平台，要去把全网的用户仓库进行 indexing（有点像搜索引擎在做的事情），才能得到一个帖子最终的点赞数量以及有哪些评论。例如转发，它其实真正的 source of truth 在用户仓库里会有一个索引到那个帖子的全局唯一 ID 的转发操作。
AT Protocol 借鉴了 Web 本身的特点：真正的数据源来自网站/用户仓库，类似 Bluesky 这样的应用则类似搜索引擎，在完成需要的索引和内容过滤后给用户提供他们需要的视图。
AT Protocol 也不仅仅是为了类似 Twitter 这样形式的社交媒体构建的，它还可以被扩展支持长文博客、音乐收藏夹、类似 Reddit 的论坛等等。而背后的 user identity，用户的关注/被关注信息，用户存储的数据都可以在这些不同的 apps 上复用。并且他们还专门提供了一种 Schema 定义的语言 Lexicon，来让不同应用之间的数据交换变得更简单并且可靠。但目前的限制是被扩展的应用场景上用户是希望数据公开的，因为每个用户仓库就是全网公开的。
AT Protocol 不是第一个做跨应用数据共享，或者是去中心化身份，以及支持 PDS 的事情的。Solid Project 从六七年前开始就在做类似的事情，但是不接地气，例如它要求应用存数据的格式是一个非常小众的描述语言从而才能更好地跨应用共享数据，和大部分开发者的习惯差距很大，所以很难流行起来。
AT Protocol 还考虑了审核和内容过滤的问题。2021 年 AT Protocol 的设计者之一 Martin Kleppmann 写了一篇文章 Decentralised content moderation。在文中他提出 censorship resistance 的去中心化社交平台的设计太过天真，因为不受控制的内容平台必然会充斥暴力，色情，以及垃圾信息。而真正需要的是去中心化的 moderation 机制。这也成为了 AT Protocol 中首要的设计目标之一。
所以在 AT Protocol 中，社区可以第三方的 Labeler （用于标记垃圾信息，暴力色情内容） 和 Feed generator （生成推荐流）。而每个终端用户能够自行选择自己需要的内容。
Bluesky 虽然目前是最主要的 AT Protocol 的实现者和服务提供平台，但是它没有特权。每个组件都可以由社区构建：
- Relay 服务：订阅转发用户的操作的服务
- Personal Data Servers
- Feed generators
- Labelers
- Client
他们还给了很好的文档和工具来让开发者开发基于 AT Protocol 的应用。最近 Bluesky 增长很快，貌似是个好时候整点活。
AT Protocol 当中，每个用户的数据都被放在一个用户仓库里面，这个仓库被称为User Repository。
这个用户仓库是对外完全公开的。这个用户仓库也可以被托管在用户自行选择的 Personal Data Server （PDS）上。社交平台上的用户操作以这个 user repository 为 the source of truth。例如，一个帖子有点赞、评论和转发这些数据，但它其实不是 the source of truth，真正的 source of truth 是每个用户的 repository。像 Bluesky 这样的平台，要去把全网的用户仓库进行 indexing（有点像搜索引擎在做的事情），才能得到一个帖子最终的点赞数量以及有哪些评论。例如转发，它其实真正的 source of truth 在用户仓库里会有一个索引到那个帖子的全局唯一 ID 的转发操作。
AT Protocol 借鉴了 Web 本身的特点：真正的数据源来自网站/用户仓库，类似 Bluesky 这样的应用则类似搜索引擎，在完成需要的索引和内容过滤后给用户提供他们需要的视图。
AT Protocol 也不仅仅是为了类似 Twitter 这样形式的社交媒体构建的，它还可以被扩展支持长文博客、音乐收藏夹、类似 Reddit 的论坛等等。而背后的 user identity，用户的关注/被关注信息，用户存储的数据都可以在这些不同的 apps 上复用。并且他们还专门提供了一种 Schema 定义的语言 Lexicon，来让不同应用之间的数据交换变得更简单并且可靠。但目前的限制是被扩展的应用场景上用户是希望数据公开的，因为每个用户仓库就是全网公开的。
AT Protocol 不是第一个做跨应用数据共享，或者是去中心化身份，以及支持 PDS 的事情的。Solid Project 从六七年前开始就在做类似的事情，但是不接地气，例如它要求应用存数据的格式是一个非常小众的描述语言从而才能更好地跨应用共享数据，和大部分开发者的习惯差距很大，所以很难流行起来。
AT Protocol 还考虑了审核和内容过滤的问题。2021 年 AT Protocol 的设计者之一 Martin Kleppmann 写了一篇文章 Decentralised content moderation。在文中他提出 censorship resistance 的去中心化社交平台的设计太过天真，因为不受控制的内容平台必然会充斥暴力，色情，以及垃圾信息。而真正需要的是去中心化的 moderation 机制。这也成为了 AT Protocol 中首要的设计目标之一。
所以在 AT Protocol 中，社区可以第三方的 Labeler （用于标记垃圾信息，暴力色情内容） 和 Feed generator （生成推荐流）。而每个终端用户能够自行选择自己需要的内容。
Bluesky 虽然目前是最主要的 AT Protocol 的实现者和服务提供平台，但是它没有特权。每个组件都可以由社区构建：
- Relay 服务：订阅转发用户的操作的服务
- Personal Data Servers
- Feed generators
- Labelers
- Client
他们还给了很好的文档和工具来让开发者开发基于 AT Protocol 的应用。最近 Bluesky 增长很快，貌似是个好时候整点活。
17 63
回顾了一个知乎老问题《实现一个多人协作在线文档有哪些技术难点？》
发现里面提到的难点 Loro 几乎全解决了：
- 并行编辑冲突
- Undo/Redo。Undo 和历史回放还不太一样，它需要只 undo 用户本地自己的操作。为此我们还在 Loro 这 CRDTs Lib 里面再实现了一套 OT，有专门的 Fuzzing Tests 去覆盖 undo/redo 的正确性。
- 光标位置同步。
- 网络状况，离线重连，操作到达顺序（用 Loro 完全不用关心了，本地始终可用，操作乱序 Apply 都能保证一致性）
- 怎么高效存储。Loro 支持很多种导出格式，可以支持用户每输入几个字符就导出对应的 delta updates，也支持导出完整历史+状态的 Snapshot 格式，也有类似 Git Shallow Clone 的导出格式来降低 CRDT 的 overhead。
- 怎么支持版本历史。Loro 上我们有自己的高效的二进制格式来保存完整的编辑历史，这个编辑历史是类似 Git 一样的有向无环图的编辑历史。我们也支持进行类似 Git 那样的分支/Merge。基于高性能的版本切换和版本管理，我们能做出更好用且自然的 undo/redo 以及版本管理的交互体验。
- 离线编辑。本来就是去中心化的算法，天然支持了。
发现里面提到的难点 Loro 几乎全解决了：
- 并行编辑冲突
- Undo/Redo。Undo 和历史回放还不太一样，它需要只 undo 用户本地自己的操作。为此我们还在 Loro 这 CRDTs Lib 里面再实现了一套 OT，有专门的 Fuzzing Tests 去覆盖 undo/redo 的正确性。
- 光标位置同步。
- 网络状况，离线重连，操作到达顺序（用 Loro 完全不用关心了，本地始终可用，操作乱序 Apply 都能保证一致性）
- 怎么高效存储。Loro 支持很多种导出格式，可以支持用户每输入几个字符就导出对应的 delta updates，也支持导出完整历史+状态的 Snapshot 格式，也有类似 Git Shallow Clone 的导出格式来降低 CRDT 的 overhead。
- 怎么支持版本历史。Loro 上我们有自己的高效的二进制格式来保存完整的编辑历史，这个编辑历史是类似 Git 一样的有向无环图的编辑历史。我们也支持进行类似 Git 那样的分支/Merge。基于高性能的版本切换和版本管理，我们能做出更好用且自然的 undo/redo 以及版本管理的交互体验。
- 离线编辑。本来就是去中心化的算法，天然支持了。
17 41
