锁嘟机制

  1. 就像 twitter 的文章被称为「tweet」,mastodon 的文章被称为「嘟文 toot」。
  2. 虽然这篇在说 fediverse / mastodon,但目前的 twitter、sina……各种社交网络混乱的隐私设置,其实是一样的。

作为自建实例用户,每次我好奇点开一个,我还没有 follow 的用户时:

  • 在我的界面里,看不到他的历史嘟文;
  • 偶尔能看到几条,以前被我 fo 的人转发过的他的嘟文,才会被存储在我的服务器上;
  • 他可能锁嘟;
  • 他的个人页面(以及整个他的实例)可能只显示 10 条;
  • 他的个人页面(以及整个他的实例)可能根本不许访问;
  • 少数情况下,我已经被对方 block 了,但只有当我想 fo 他时,我才会从灰色的 follow 按钮上注意到这一点……

我不知道,有什么便利的流程,来判断对方属于上述哪一种/几种情况;也不知道,面对每一种情况,我

  1. 是否被允许
  2. 如何去

了解一个人。我也不知道,采取了上述每一种措施的人,是否清楚,他在

  1. 和他相同的实例
  2. 和他不同的大实例
  3. 彼此 follow,有着模糊边界的共同好友圈
  4. 其它小实例

的人的眼里,有着怎样的可访问性。他希望打造一个什么样的社交网络架构,以及他的这些选择,最终是否能够如他所愿。

这不是在指责具体的人。我知道,有很多人,对这套复杂的体系,比我更熟悉,更习惯去应对。也知道,如果我往这个方向努力,也会应对的更自如一些(但不知道会进步到什么程度)。但现实中的结局是,fediverse,就像没什么人来看的 blog 一样,渐渐被我当作一个,纯表述的平台。别人如何看到我,如何来交互,对我而言,变成了一个不清楚机制、雾里看花的过程。对这方面的期待,也就渐渐减弱了。

于是,虽然我也会去 follow 别人,去 re 去聊天去点赞。但这些行为对我都是不成体系的。很多人我不知道要不要去 follow,聊天时也不知道什么时候要用一个点赞,或者什么都不用,就可以突兀地结束话题。更不用说,在预设别人掌握了这套体系,以及预设别人预设我掌握了这套体系,的基础上,通过彼此的操作方式而不是内容,来判定对方的态度。——扯远了,这些已经和 fediverse 机制关系不大了,我在实体社交中也不会去折腾这些(而且我对实体社交的潜规则也是雾里看花,不去弄明白)。这篇只是例行吐槽网站隐私机制而已。

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 的时代,所有的转发,都是由用户手动复制一个副本。而最初的推文被删除,完全不会影响这些副本继续存在。所以这里只是提醒大家,有这么一个机制。具体的隐私控制,还要由创作者自行把握。你曾发到网上的东西,可能永远不会真正消失。