肤浅地记录一下为啥不太看好 Mastodon/nostr 等 fediverse。
Scalability:
对于千万活跃用户来说,如何展示时间线是个很古老的问题,highscalability 和 微博 都有关于 push/pull 模式的讨论。简单的说:
- 读多写少
- 大V的巨型分发量压力
- 热点读的 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 就麻烦得多。