构思 - backfill 友好的时序元数据

咱知道 Bluesky 被人批评说“很多东西都是去中心化的”，在 AtmoType 构思架构的时候也考虑到这么一点。于是就想到在 PDS（相当于分离的数据库）上存所谓“时序元数据”，也就是说提供日志式的数据来筛选不必要的评论

没人问你：为什么要这么做？ 因为这 AtmoType 和 Bluesky 最大的区别就是“backfill 友好”。Blacksky 等机构拥有自己的 PDS，现在正在 backfill ATmosphere 上的所有支持数据。但是有很多的数据是 backfill 都 backfill 不了的。

Bluesky 的“控制交互”算一例。控制交互就是指开关嘟文（抱歉这两个字滥用了）引用和回复控制。

Bluesky 的交互控制选项

这里头的逻辑是：当接收到 PDS/中继传来的 app.bsky.feed.threadgate 记录（Record）更改（和主嘟文 app.bsky.feed.post 分离的），AppView（抛开数据之外的后端）会接受更改。

举个简单的例子。我把我的嘟文设置成“评论区已关闭™”后，AppView 这时候只会给试图¹发送评论的人计数，而不在 AppView 的端点显示回复。我再打开评论区一切照常，但是“试图发送评论”的那位的回复不会被展开。

那么，这个记录格式，肯定很复杂吧：

javascript

{
  "post": "at://did:plc:[REDACTED]/app.bsky.feed.post/3mdab332cbk2o", // 记录原嘟文
  "$type": "app.bsky.feed.threadgate", // ATProto 的校验机制，略
  "allow": [], // 允许回复者，没有表示不允许任何人回复
  // 后略
}

这个格式异常简单，完全没考虑到 backfill 需求。

所以，我们应该考虑用“时间—内容”的格式来代替开/关。以下是伪代码：

javascript

{
  post: "at://redacted", // 依旧链接嘟文
  log: [ // 这里头记录从什么时候开始变成怎样
    {
      timestamp: "2026-01-25T11:11:11:111Z", // 时间戳
      content: { allow: [] }, // 内容：评论区已关闭™
    },
    {
      timestamp: "2026-01-25T22:22:22.222Z", // 比评论区关闭那个新
      content: {}, // 评论区又打开了
    },
  ],
}

当然了，作为一个颠佬，这里头有个 ATProto/Schema 不友好的伪代码：

javascript

a = {
  post: "at://redacted",
  log: {
    "2026-01-25T11:11:11:111Z": { allow: [] },
    "2026-01-25T22:22:22.222Z": {},
  },
};

用这样的代码（别用那个颠佬代码，你也用不了），后端在 backfill 的时候，能知道“什么被挡住了，什么没被挡住”，可以保证两个后端的数据等同。

但等同也救不了 Bluesky。Bluesky 在记录新建的时候会存一个副本，然后无论那个记录在你手里怎么改，AppView 还是会显示你第一个副本，除非这个记录被删，连带整个 backlink 关系被丢失。但这不是我考虑到的话题。

Lexicon 呢？ 暂时还没设计出来，不过会有的。主要是 Lexicon 没有一个傻瓜工具，又不想自己造轮子…（说到这里，这不又是一个新坑吗？）

这种人很少，大部分用户都会被 social-app 即官方前端挡住 ↩

构思 - backfill 友好的时序元数据

#Footnotes