主要观点：

• 常有人称 AT-Protocol 架构的某些核心组件托管成本高且难扩展，如 Bluesky 的 AppView，但作者认为可自行搭建低成本的类似服务。
• AT-Protocol 有循环（单向）数据流向，AppView 可作为典型 http 后端构建，Bluesky 中继开放可自建 AppView 接收全球内容。
• Bluesky 的 AppView 功能复杂，可分解为多个服务，其未过滤的中继输出即火喉（firehose），jetstream 可将事件重发为简化 JSON。
• 无需 AppView 也可在浏览器中获取 Bluesky 数据，通过一些工具可重建关注 feed，但社交互动缺失且速度慢，可通过多种方式加速 feed 生成。
• 可通过组合微 AppView 服务实现自托管 Bluesky 兼容的 AppView 体验，这些服务大多不特定于 Bluesky 内容，可共享。
• 思考这一做法对去中心化的影响，认为既有自下而上也有自上而下的去中心化方式都有希望。

关键信息：

• 作者用 Raspberry Pi 4b 搭建的 AppView 每天处理约 20GB 火喉事件，索引近 10 亿回链。
• 介绍了不同工具如atproto-browser等可直接获取 PDS 数据。
• 提及@alnkq.bsky.social 已实现类似功能的代码AppViewLite。
• 讨论了 moderation 等其他相关问题。

重要细节：

• 数据流向图展示了 PDS、Relay、AppView 和客户端的关系及添加的 firehose 相关部分。
• 详细描述了 Bluesky AppView 内部的各种服务组件。
• 说明了通过监听火喉、预缓存等方式加速 feed 生成的方法。
• 提及 ActivityPub 等其他去中心化协议及 Spritely Institute 的工作。