为什么不太看好 Nostr/ActivityPub

肤浅地记录一下为啥不太看好 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 就麻烦得多。

Comments