WordPress 的 ActivityPub 插件

试用一下 WordPress 的 ActivityPub 插件(官网 / Github)。

主要功能,就是在 wordpress 上,建一个 Fediverse 账号,Mastodon / Pleroma / Misskey / Honk……的用户可以 follow 这个账号。新的 blog 文章发布时,这个账号会发一条嘟文,大家可以转发这条嘟文。followers 对这条嘟文的回复,会自动同步到 blog 文章的评论区。

就像我为这个 blog 建的 fedi 账号:@[email protected]

需要指出的是,并不存在 blog.fivest.one 这样一个 fediverse 实例。陌生人搜索这个账号,看不到任何历史嘟文;这个账号不能去 follow 别人,不能对别人说话,不能回复别人对自己嘟文的回复,也不能看到多少人转发点赞了自己的嘟文。——这些功能也许以后会有,但目前,这个插件所做的,只是在新 blog 发布的那一刻,向所有 follow 这个 id 的账号,push 一条嘟文。这条嘟文,在 blog 服务器上,并没有保存;而只存在于 follow 它的那些实例上,再被人转发到更多实例。

当 blog 的文章被删除时,这个插件也会通知所有的 followers,从他们的实例上删除对应的嘟文。但是就像我说过的,这个机制并不能把那些,被转发到其它实例的嘟文,也一起删除。所以,当你在 blog 按下发布按钮的一刹那,带着你所写的全部内容(或者摘要,可设置)的嘟文,就可能会永远飘在 fediverse 世界里,无从反悔。所以,写完这篇文章后,我还不确定自己是否会继续用这个插件……

所以我只是觉得这个插件运行的机制很有趣,向大家介绍一下而已。它仅仅是通过 ActivityPub 协议,和其它实例通信,而本身并没有创建实例。这个插件在 wordpress 的数据库里,甚至没有新增一个 table,而只是把 followers 的公钥,存到了 wp-options 里(我觉得这么折腾 options 表,有点过犹不及了……)。总而言之,这是个超级轻量化,在 wordpress 基础上,完全不产生多余开销的东西。

我之前吐槽过,目前所有的 Fediverse 引擎,都是用软件工程模块,匆匆拼出来的臃肿怪兽:开销巨大,数据结构不美观,依赖的技术模块未必有长久的生命力,安全性抗冲击性都很差……其实我很期待,一个单用户版的,完全没有 local 功能,支持 ActivityPub 协议的引擎。结构的简洁程度,和资源的开销,要比现在这些要好很多。从这个插件可见一斑(虽然这个插件和完整的个人版 fedi 实例,是完全两回事……


测试了一下。好像只有 follower 的回复(公开 or 私密)才会同步到 blog 的评论区;陌生人的不可以。但目前还没有做 follow 的审核通过机制。所以理论上是可以用这个功能发垃圾评论……

以及目前还没有让用户修改个人简介的功能,图片上那些简介,都是我在插件 templates/author-json.php 里手动改代码的。

关于 fediverse 的删除机制

在当前的很多 fediverse 服务(mastodon、pleroma…)里,当 A 站的用户 a 被另一个实例(譬如:B 站)的用户关注时,他所发的嘟文,会在 B 站的服务器上储存一个副本,B 站的用户,通过访问这个副本,来阅读这条嘟文。当原本的嘟文被删除时,A 站会通知 B 站,删除相应的副本。但这个时候,这条嘟文未必像人们期待的那样,从 fediverse 上彻底消失。

假设存在如下情况:

  • A 站的 a 用户
  • B 站的 b 用户,b 在关注 a
  • C 站的 c 用户,c 在关注 b,但 C 站没有人关注 a
  • a 发了一条公开嘟文,此时 b 可以看到这条嘟文,而 c 是看不到的。
  • b 转发了 a 的这条嘟文,此时 c 可以看到这条嘟文了。C 站的所有人,在查询 a 的时候,也都可以看到 a 的这条嘟文。
  • 如果这个时候,a 再把这条嘟文删除,那么 A 站会通知 B 站这条嘟文已删,而 B 站也会把这条嘟文在 B 站的镜像删除。于是 b 就看不到这条嘟文了。

——然而,似乎并没有一个机制,去通知 C 站,这条嘟文已删?也就是说,这个时候,c 和 C 站的所有人,都仍然可以看到 a 已经删掉的这条嘟文?

如果这个时候 C 站有人再转发这条嘟文,而 B 站甚至 A 站有人关注这个人,那么,B 站和 A 站的人,就又能看到这条嘟文了?甚至连 a 自己,也能看到的?(这个有待验证 — UPDATE:不可以的,见评论区)


听起来似乎很不靠谱,但也不是不能接受。就像 twitter 还没有官方 retweet 的时代,所有的转发,都是由用户手动复制一个副本。而最初的推文被删除,完全不会影响这些副本继续存在。所以这里只是提醒大家,有这么一个机制。具体的隐私控制,还要由创作者自行把握。你曾发到网上的东西,可能永远不会真正消失。

Mastodon 的「去中心化」所导致的……?

看到 @[email protected] 写的论文导读。在 Mastodon 的去中心化网络里,用户之间的关联状况,其实比 twitter 更加高度集中。

Raman, Aravindh, Sagar Joglekar, Emiliano De Cristofaro, Nishanth Sastry, and Gareth Tyson. 2019. “Challenges in the Decentralised Web: The Mastodon Case.” Pp. 217–229 in Proceedings of the Internet Measurement Conference, IMC ’19. New York, NY, USA: Association for Computing Machinery. download
研究人员爬取了在2017年4月到2018年7月期间的1750个实例,涵盖了23.9万用户和六千七百万条嘟嘟。基于这些数据,构建了用户相互关注的网络,以及实例之间的连接网络。

通过分析这些网络,论文发现了长毛象的中心化趋势。以下结果是基于搜集到的样本,不是全长毛象数据。

1. 用户方面,大约50%的用户都集中在10%的实例里面,因此少数的管理员在长毛象联邦中拥有过量的影响力。开放注册的实例拥有的用户比邀请注册实例里的更多,但是,邀请注册实例的用户平均嘟嘟数量差不多是开放实例用户嘟嘟数量的两倍(187嘟/人 vs. 95嘟/人)。不管哪种实例,都有中心化趋势,服从幂律(power law),前5%的实例容纳了约95%的嘟嘟;

2. 内容方面,只要关掉最大的10个实例,跨站时间轴上62.69%的嘟嘟都会消失。有些实例带有话题标签,研究发现,科技相关实例占据了55.2%的实例,却只容纳20.8%的用户和24.5%的嘟嘟。相比之下,虽然只有12.3%的实例是跟色情相关,但是却吸引了61%的全网用户;

3. 服务器方面,大部分实例都集中在少数的自治系统(Autonomous System, AS)上,主要在日美法德四国。最大的三个AS就有62%的实例。比如亚马逊AS上集中了62%的用户,尽管上面只有6%的实例。关注网络上,92%的用户是连接在一起的,但在极端情况下,只要五个AS崩坏,就会把相互连接的用户数量减到46%。

作者还分析了网络结构的强度。虽然长毛象分成了很多独立的实例,但是用户之间是高度连接的,跟推特相比,长毛象的连接更加脆弱,只要破坏少量的重要节点(高关注用户)就能够极大破坏原本的连接,相比之下,推特的关注网络就比较稳健。

伦理声明:研究通过了大学伦理审查,只收集了公共嘟嘟,并进行了匿名处理,论文结果不包括任何的嘟文内容分析。

实际使用中,也有类似的感觉,Mastodon 用户互相 follow 所形成的网络,比 twiiter 更加纵向化。大家相对更集中关注一些较活跃的用户,而在用户网络的末梢,横向的互相关注相对较少,尤其是不同实例之间的关注,更是如此。

但我觉得这种状况,是和 Mastodon(以及整个 ActivityPub)目前的设计机制有关。最近自己架设实例时,看了一下 Mastodon 和 Pleroma 的后台数据库,架构上有一些莫名其妙的地方:

( btw,我的新帐号: @[email protected]

在当前实例里访问其它实例的文章时,系统要先把其它实例的文章(以及图片附件)复制到当前实例的服务器(而且是和本地用户的文章放在同一个数据表里……),才能被本地用户读取。本地用户所看到的,并不是其它实例的原始数据,而是被保存在本地实例的镜像。

当一个实例的用户 follow 其它实例的用户时,两个实例的数据库把外来实例用户的信息和 public key,保存在各自的数据库里(也是本地用户和外来用户存在同一个数据表里……)。当外来实例的用户发布新文章时,外来实例的服务器会把这条新文章,主动 push 到订阅了它的那些服务器里存起来。

我能看出这样做的一些好处,譬如减少了实例之间的重复通信、避免最终用户和外来实例间的翻墙屏蔽、增强安全性……etc。然而,一切外来实例的文字和图片,都要先保存到本地服务器,才能被阅读,由此导致的,就是用户在随意浏览外面实例的历史文章时,体验非常不友好

界面里显示的外部实例用户的 following 和 followers 数量,也仅仅是当前实例里和这个用户有关联的用户的数量,而不是这个用户在所有实例的真正总关联数。

不仅是外面实例陌生人的信息,不能直接看到;连已经 follow 的用户,在 follow 之前所写的文章,也不能在系统里直接看到。一定要再打开一个浏览器页面,访问对方在其自己实例上的页面,才能浏览。对历史信息的转发和回复也非常不便。

当用户在 Mastodon 界面中,点开一个陌生人的帐号时,有三种情况:

  1. 陌生人也在同一个实例。此时用户可以直接看到陌生人的所有历史文章;
  2. 陌生人在其它实例,但之前曾经被用户实例里的其它用户 follow 过。此时用户可以直接看到,从这个实例里第一次有人 follow 开始,陌生人发过的所有文章。再之前的文章,则必须打开外置浏览器才能查看;
  3. 陌生人在其它实例,之前用户所在实例并没有人 follow 过他。此时用户完全不能直接看到陌生人的任何历史文章,只能通过打开外置浏览器查看。

不能方便地查看一个人以前发过的文章,也就自然没有兴趣去 follow 他。这就导致了两种「集中化」的关联:

  1. 在同一实例内部的人,由于可以互相看到历史文章,所以更方便互相 follow;
  2. 一些已经被实例里其它人 follow 过的「热门用户」,他们的文章更容易被这个实例里的其它用户看到,从而更容易被 follow。

而与之相对的,就是不同实例之间从没 follow 过的陌生人之间,其横向关联度急剧下降。

如果换一种架构模式,每个实例把自己用户的文章都做出静态缓存;然后用户访问外来实例时,直接访问对方服务器的页面,这样的话,情况会不会好很多?

我的技术水平不够,不能再深入分析对比这些机制的优劣了。但这些,其实和「去中心化」本身,并没有直接的联系。「去中心化」和「中心化」的区别,其实仅仅是后台服务器由谁去建,以及随之带来的审查和信息自由度方面的不同。普通用户在使用中,其实是不应该感受到 Mastodon 和 Twitter 的差别的。我们所面对的,并不是「去中心化」带来的问题,而是在做一套新的「去中心化」架构时,所没能解决好的技术问题。那些「中心化」的服务,也有很多因为设计的不如 twitter 理想,而最终倒闭了。目前而言,Mastodon 的架构还远称不上完美,有很多不足,或者让用户觉得不习惯的地方。但这些问题,其实只属于某个产品设计上的问题,而不应该归咎于「去中心化」

个人 VPS 上的服务安装(未完稿)

这篇文章要讨论的是,如何在一台轻量级的 VPS 服务器上,基于自己的域名,同时安装如今各种流行,去中心化的网络服务:

  • 个人博客:Wordpress
  • ActivityPub 社交网络:Pleroma 或 Mastodon
  • Matrix 聊天服务器:Synapse 或 Dendrite
  • 个人网盘和在线办公套件:Nextcloud

然而,原本我一直在用 Linode 每月 5 美元,1C1G(1个CPU,1G内存)的服务器,打算安装的服务,也是基于这个级别的配置。然而弄到一半,突然被乔乔推荐了 Contabo 每月 5 欧元(要一次缴一年,不然有额外费用),4C8G 的服务器。虽然实际速度和网速,并不比 Linode 或 Vultr 好多少,但 8G 内存,选择各种服务的余地可就大多了。所以我整理出来的 1C1G 方案,自己并没有在用……原因我后面会说。

之前也犹豫,既然同样价钱都能 4C8G 了,那为啥还要写 1C1G 的方案?很快大家的配置也都会变高级了吧?但想想也未必,还是整理一下吧。


这篇文章讨论如何在轻量级服务器里塞进各种服务。——前提是这台服务器,假定只会有你一个人在用,最多加上你的闺蜜和男朋友。我并不知道几十个用户的 Mastodon 会有怎样的开销,至少在 1C1G 上这样做非常不靠谱。我所面向的,只是两三个好友自用的私人 VPS 而已。

这篇文章不是写给小白用户的。整个系统还是很复杂的。指望有一个教程,或者一个 docker-compose,能够让完全不懂 Linux 的用户,通过逐行复制命令,就能搞定所有的安装,目前还不现实。你至少要有在完全理解的基础上,用 LNMP 搭出 Wordpress 的能力。所以我也没必要把用过的每一条命令,都放在这篇文章里。——对于每一项服务,我会尽量给出相关靠谱攻略的链接,并且讨论一下里面的坑,和我个人所作的选择。

所以,其实这篇文章本质上就一句话:

是的,这些服务都可以装到一台机器上,不冲突。我弄过了,没问题,你们放心慢慢弄吧。


安装环境:一台 1C1G(或更好的) VPS 服务器,一个你自己的域名。

Continue reading

hello fediverse

当我说 mastodon 难部署的时候,并不是作为一个建站小白说的。用自己的域名和大约每月5刀的服务器,我可以很轻松地搭建一个 mastodon 实例,用 docker 部署则更简单。——如果我对这个服务器没其它需求的话。

问题在于,对于大多数有建站情操和能力的人来说,建站优先级最高的未必是 mastodon,而是 wordpress 啊。把这两套系统同时塞进一个服务器,理论上是能做到的,但其麻烦程度让我实在没欲望去折腾。而为这两个系统买两个服务器,又总觉得很耻辱,和小白们每个服务交一份钱有啥区别……

另一方面,尽管 mastodon 存在单用户模式,但真的建了实例只有自己一个人用的话,整套 mastodon 程序功能其实是很冗余的。所以对于个人用户而言,要做的可能并不是自建 mastodon 实例,而是寻找其它可以通过 ActivityPub 协议,和 Fediverse 用户进行沟通的程序。——目前似乎还没有太理想的。 write.as 正在做,我去试了试, 用户可以在 Fediverse 上 follow @[email protected] ;wordpress 也有类似的插件(等我先给自己域名申请 SSL ……)。但似乎都只能让 Fediverse 用户「订阅」这个站点,而不能反向和他们回复沟通。

所以还要继续关注 Fediverse 的新进展。据说 nextcloud 已经可以支持 ActivityPub 和 mastodon 沟通了。——网上的免费服务器没这个功能,需要自建 nextcloud 然后挂载相关服务,哪位愿意折腾试试靠谱不?但似乎 nextcloud 还不支持发布 blog??(怒吼:为什么,明明这个更容易啊)。不然 nextcloud 就已经很一站化了。

社交平台的六围

对各种用户提供内容的平台进行评价和比较时,我觉得大家争吵的,往往是不同维度的东西,而每个人更在意的方向并不相同。我列了一下,大概有这些因素。首先要做的,是自己打个权重,看看你对每个因素是不是真的在意(譬如公众传播度在有些人心中的比重,是远大于帖子是否会被删的——这未必是坏事)。然后就可以像游戏里角色的六围那样(其实列出来的不止六项),给每个平台逐项打分。

  • 思维自由度:你在写东西的时候,多大程度上,会受到其它因素的约束和干扰?这不仅仅指在真理部面前进行自我审查,也包括你所在的社区的发言氛围,以及你是否介意朋友们看到你发言时的反应。
  • 信息存活性:你的发言会不会被删,以及在更大范围上,你所在的平台会不会突然就没了……(或许这两条应该分开算?
  • 信息持续性:一方面是指热度:文章会不会过两天就沉下去,再没人关注(其实所有平台都会这样)。另一方面,哪怕没人关注,你是否希望文章一直存在,被需要的人偶尔搜出来看看?还有一点就是,当你换了平台,或者换了图床的时候,能不能用某种技术手段,让你的外链一直有效?
  • 便于讨论:你的文章是否便于让同好们进行讨论?以及,你所在的平台是否能聚集你的同好?
  • 公众影响:为了赚钱或者社会责任感,你是否宁愿自我阉割,也希望文章尽可能地被更多人看到?
  • 跨平台开放性:文章是否能让平台之外的用户看到?
  • 隐私安全:如果作者没有主动泄露个人信息,平台的架构以及管理人员,能否防止你被喝茶或者被人肉?
  • 技术便利性:建站、管理、日常访问、翻墙……是否方便?(其实我应该把管理员和普通用户分开的)

此外当然还有更多的参考因素(界面美观、用户体验、是否免费……),这里只是提供这样一个比较的思路。

我这里随手列了几个例子。一些网站我不常用没什么发言权:Facebook、Lofter、Matters、AO3、豆瓣……大家可以自行吐槽。

以下是吐槽部分:

  • 虽然 Mastodon 最初是作为避免 twitter 越发严重的政治审查而存在的,但目前各个实例中的用户趋向(或者说他们希望能趋向)同质化,导致目前给我的感觉,在 Mastodon 里说话的自由还不如 twitter。
  • 在 Google Reader 的时代,以及 Disqus 等平台试图统一 blog 评论体系的时代,blog 的讨论性是接近四颗星的,但目前只能用凄惨来形容。虽然每篇文章还是有评论区,但大家宁愿在 twitter 的链接下面回复,而没有人去文章下面留言了。
  • Facebook 这种完全建立在实名上的讨论群体,以及随之关联的发言规范,和我完全就是不同的世界,索性不予评价。