肤浅地记录一下为啥不太看好 Mastodon/nostr 等 fediverse。

Scalability:

对于千万活跃用户来说，如何展示时间线是个很古老的问题，highscalability 和 微博 都有关于 push/pull 模式的讨论。简单的说：

1. 读多写少
2. 大V的巨型分发量压力
3. 热点读的 materialization 太慢

一般的解决方案是 fanout-write。也就是如果大V发一条微博，那么他所有 follower 的专用timeline 队列都会被写入一条微博id

这个问题放在 fediverse 会更加复杂。目前我了解的情况是，没有专门解决这个问题。如果哪天真有个用户量巨大的网络形成了，同步全量数据都超过百兆带宽，那么其他普通 vps 上的节点也就几乎无法同步全量数据了。所以需要部分同步，那么如何联机设计就会变得很复杂，每个节点都是选择性的同步一些用户的一些时间内的消息，就会产生上面 twitter 和 weibo 的问题。这两家公司内部db 和 es 内网查询都不能很好解决，我不太相信在公网做同步能更容易解决。

基于这个判断，我觉得这些网络都不可能做大，因为这个技术问题（据我所知）还没解决；社交网络的「六度分隔理论」，是建立在 「supernode」也就是超级大V基础上的。所以如果这个技术问题没解决，fediverse 发展到天花板，人缘必定是很疏散的。无法形成 twitter/weibo 那种排山倒海的全行业舆论压力。

客户端太丑

这个是个主观判断。signal 和 matrix 都是因为客户端太丑，所以不如 telegram 好用。

言论压制

题外话1：我觉得 censorship 翻译成「审查」不太对。审查明明是 review 或者 moderation 。

目前逃离 twitter/weibo 最大的动机就是平台删帖，但是 fediverse 这个问题其实并没有解决，而是把责任下方给各个提供方了。提供方可以决定是否删帖怎么删以什么标准删。而靠 hobby 热情支撑的 fediverse 服务我觉得不是长久之计。站方的财政比较正向，才比较健康。所以要完全自由就一个人建一个站。。这样其实从系统设计角度来说效率太低。摄像你 follow 了100个人，每次冷更新 timeline 就得至少发起100个请求。

题外话2：我觉得 mastodon 的双 @ 太难看了。 @est@mastodon.social 为啥不去掉第一个 @ 变成 est@mastodon.social 呢？有人说这样容易被不懂技术的识别成 email 。啊，还有这种好事？设想如果 mastodon 支持一下 SMTP 其实很不错呢。

静态建站

据我所知，ActivityPub 基础交互都需要 HTTP POST。我特别希望有一个 fediverse 协议能设计成比如 github pages 就能托管。站方时不时更新一个 比如旧时代的 feed.rss 之类的文件就完成发布，每次更新的时候ping(HTTP GET)一个网址表示有更新让爬虫来取一下。这样的轮询简单粗暴，推广成本最低，不需要复杂的 RoR 或者 nodejs 搭建技能。

如果站点流量实在太大，需要长连接同步，可以采用 EventSource 之类的单向流就行。使之基于 serverless/lambda 服务比如cloudflare worker就能跑，不要搞得太复杂。nostr 的 websocket 就麻烦得多。