Mastodon: 将媒体文件存放在本地(docker 版)

本攻略适用于——

  • 自建 mastodon(非大站)
  • 使用 docker compose
  • 将媒体文件直接保存在服务器上,而不使用 s3 外部存储

这个搭配虽然不多见,但其实用起来满爽的。很多人用的 s3 服务都是在薅羊毛,而 mastodon 那个变态的,把别人家的媒体文件缓存到自家的架构,流量的吞吐其实很大的(开了 relay 就更夸张),薅羊毛时很容易就超出了。反而是 vps 本身的流量上限很高。对于个人建站而言,媒体文件总量通常 <50GB,某些 vps 自带 200GB 硬盘,足够用了。

缺点是,除了数据库定期备份外,也要考虑媒体文件的异地备份问题。但其实只需要备份存储本地附件的 media_attachments,而 cache 是不需要备份的,所以工作量也不大。

两年前我把媒体文件转移到本地时,参照了 antisocial science 的设置。但因为我用 docker,官方默认的设置,docker 内外权限不一致,无法将媒体文件写到本地。于是匆匆又在本地建了个 minio s3 来中转……这样其实很浪费资源了,minio 的开销也不小。所以最近趁着搬家,又试了一下,终于把 docker + 本地存储 跑通了。


1. 在 docker-compose.yml 里,

web 和 sidekiq 容器中,已经预设了媒体文件的卷映射

volumes:
- ./public/system:/mastodon/public/system

这个不用动。——也可以改成其它的路径,但要和后面的设置一致(本文用相同的颜色标明)。

2. 修改 .env.production

S3_ENABLED=false
PAPERCLIP_ROOT_PATH=/mastodon/public/system
PAPERCLIP_ROOT_URL=/fivestone-mastodon-media

PAPERCLIP_ROOT_URL 是服务器的所有媒体文件链接的子文件夹名称,形如:

https://mastodon.fivest.one/fivestone-mastodon-media/media_attachments/.../x.jpg

默认值是 /system;但是建议改成独特一些的名字,而且建议和 S3_BUCKET 一致。以后需要在本地存储和 s3 之间转换时,可以省一点心。(所以要独特一些,防止回头在 s3 上和别人撞名)

3. 修改 nginx 的域名配置文件

参照官方的配置,把域名文件夹里的 proxy_pass ,直接改成本地的 alias

server 
{
  server_name mastodon.fivest.one;
# ......

  location /fivestone-mastodon-media/
  {
    alias /path-to...docker-compose-folder/public/system/ ;

    proxy_cache CACHE;
    proxy_cache_valid 200 48h;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_lock on;

    expires 1y;
    add_header Cache-Control public;
    add_header 'Access-Control-Allow-Origin' '*';
    add_header X-Cache-Status $upstream_cache_status;
    add_header X-Content-Type-Options nosniff;
    add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
  }
}

然后重启 nginx

sudo systemctl reload nginx.service

4. 通过 docker 设置媒体文件夹的权限

在 docker 内部,是以 mastodon 用户的身份,来运行程序的,所以要把媒体文件夹的所有者改成(docker 内部的)mastodon:

sudo docker-compose run --user=root --rm web chown -R mastodon /mastodon/public/system

如果是从 s3 迁移到本地,把媒体文件移入这个本地文件夹(/path-to…docker-compose-folder/public/system/)后,也要再执行一遍上面这条命令。

或者在 mastodon docker 服务已经启动的情况下,执行:

sudo docker exec -u 0 mastodon_container_web chown -R mastodon /mastodon/public/system

但在这条命令执行结束之前,mastodon 在后台写入媒体文件时,仍然可能出现文件夹权限不足,无法写入的问题。

Fediverse: 是否要自建实例?

之前和人聊到,自建 fediverse 实例时,和在其它实例做注册用户相比,一些不同的体验。然后发现,谈到的许多东西,对于没有自建经历的网友,还是很新鲜的。所以索性在这里列出来,让大家了解一下。

  • 本文是在「技术能力并不是障碍」的前提下,比较(自建实例 vs 注册现有实例)的利弊。所以,「技术门槛很高」这件事本身,并不能成为建站的缺点……
  • 本文主要讨论「建实例自己用」的情况,最多和一两个亲密好友共享;而不是「当站长,开放给大家注册」。

自建实例的优点

1. (可能)更好的稳定性

是的,自建并不是「不稳定」的代名词;恰恰相反,如果技术能力达标,个人实例因为开销相对较少,稳定性反而比很多中小型实例要高。即使我完全有能力,担任几百名用户的实例管理员;和维护一个我自己用的实例相比,我也是对后者的稳定性更有信心的。

而另一方面,现有实例的站长们,也未必都是很靠谱的。他们会因为各种技术、非技术、甚至搞笑的原因,导致站点无法访问。常见例子包括:

  • 媒体文件占满存储空间
  • 域名或服务器忘记续费
  • 站长被喝茶
  • 站长不开心了,突然关站

目前 fediverse 更换一次账号,还是满麻烦的;也并没有旧帐号数据的导入功能。所以,如果想要让自己的账号,长久地存在下去,自建可能是更好的选择。

以及,自建实例有更好的安全性。——像 fediverse 这类的程序,暴露出的系统漏洞,其中相当大一部分,都是通过「站内用户的恶意攻击」来触发的(譬如上传会包含代码的媒体文件)。如果这个站点只有你自己在使用,那么,这类漏洞,对你来说是无关紧要的。

2. 更好的隐私控制

之前写过一篇《Fediverse 站长都能看到什么?》。普通用户的很多未公开信息,对于所在实例的站长,技术上都是可见的。如果你在这些隐私方面有所顾虑,或者打算把 fediverse 账号当成私密日记来用,那么,自己建站,信息被不相干的人看到的可能性,会更少一些。

3. 管理自己的全部数据

现有的 fediverse 服务程序,为普通用户提供了数据导出功能,但导出的数据内容很有限。譬如 mastodon 导出的数据中,包括:

  • 你发出的内容
  • 你的 following / mute / block 列表
  • 你保存(bookmark)的嘟文的链接(而不是内容)

但并不包括:

  • 别人回复给你的内容,——当然,「别人的作品」你是否有权保存,就见仁见智了
  • 别人对你的点赞(favourates)
  • 你转发的消息
  • 你点赞的消息

其它程序的数据导出,也都大同小异(twitter 也差不多);有的甚至会更少,譬如支持和 fedi 账号互 fo 的,图书管理程序 bookwyrm,用户能导出的,只能用惨烈来形容(只有书的链接;没有书的标题和简介!没有你的书评!)。如果你希望未来也能够看到这些自己交互过的信息,而不是随着网站的消失而听天由命,那么,可能一开始就选择自建比较好。

另外,mastodon 的搜索功能,做的很差劲的(尤其是中文)。elastic search 的开销极其巨大,效果也不好。虽然我也很少用搜索功能,但一旦真的有什么信息,需要精确查找,直接在自己建的站里用 SQL 搜索数据库,要舒适很多。

4. 更少的站内约束

很多 fediverse 实例,是有其内部的聊天「氛围」的。一些和氛围不合拍的发言,可能会遭到实例其它用户的抵制,甚至举报。很多时候,这样的分歧可能无关对错,但多少会对发言者产生困扰和拘束。又或者,站长决定,或者通过「民主表决」的方式,让全站屏蔽了某个实例,而你可能并不希望这样。如果是自建的话,做自己的站长,这样的约束可能会少一些。——虽然偶尔还是会看到一些来自外站的举报,但跨站举报本来就没有相应的处理和交互机制,无视就可以了。以及,我并不是指,自建站就可以肆无忌惮地发色情或者仇恨言论,那可能会让你的整个站点,被其它实例屏蔽的。

5. 使用自己的个性域名作为账号

这样看起来比较酷。但也仅仅是比较酷而已。

6. 免翻墙

随着 fediverse 逐渐进入某国审查机构的视野,那些几百甚至几十人的实例,未来被封杀的可能性也会急剧增加。相对来说,用个人域名在海外服务器搭建的,个人使用的实例,短期内被封的可能性,还不是很大。自建站的用户不必翻墙,就可以直接通过自己的实例,访问到其它被封实例的内容。——当然,翻墙属于必备技能,所以这也算不上是多大的优点。


自建实例的缺点

1. 没有了实例内部的聊天氛围

相当大比例的用户,被 fediverse 吸引的主要原因,是在实例内部的聊天氛围。他们精心挑选舒适的实例,在有着相同喜好的人群中交流,甚至把本地时间轴当作了聊天室。对他们而言,在一个人的实例里唱独角戏,大概是不能接受的吧。

2. 别人看不见你 / 你看不见别人

现有 fediverse 体系,最不方便的一点是:如果账号 a 和 b 是在不同的实例 A 和 B,那么,只有当 B 实例里有人 follow a 之后,a 发的内容,才会出现在实例 B,从而有更多的机会,被 B 里面的其它用户看到。

这样的状况,对于实例之间的互相探索,构成了很大障碍。也使得这种去中心化模式的用户关系网,展现出了与 twitter 不同的结构(我之前写过这方面的介绍)。——其实这样的障碍,对于非自建的用户,同样存在;只是对于个人实例,会更严重一些。

可以通过加入 relay 来改善这种状况;但这样需要占用更多服务器性能,以及很大一笔额外的媒体文件流量,需要谨慎使用。

另外,你使用 fediverse 一段时间后,渐渐地在不同的实例里都有 followers,你的文章也会渐渐被镜像到这些实例里,「别人看不见你」的情况会得以改善。但「你看不见别人」的情况会始终存在。尤其是对方账号不公开,同时它所在的实例,不允许从浏览器直接访问个人页面,那么,你几乎没有途径,可以发现对方的文字。

3. 成本:时间、金钱、服务器开销

即使不考虑技术门槛,和架设、维护站点所花费的时间成本,单纯只是花在域名和服务器上的费用,每年大概在人民币 ¥600 元左右。当然,在这样一台服务器上,除了自建 fediverse 实例外,同时还能做很多其它事情。

4. 额外的身份泄露

在其它实例注册时,虽然你的所有文章和信息,对站长都是技术可见的;但除此之外,站长(以及可能存在的审查人员)能够得知的,也只有你注册时的 email、和访问实例的 ip 地址。如果个人隐私保护的比较妥善,从这些信息,并不会泄露你的真实身份。

而自建服务器,是会泄露更多信息的。包括你注册域名、购买服务器时,所填写的信息(这个可以作假),和信用卡等支付方式。虽然域名可以隐藏在 cloudflare 后面,但你和其它实例交互时,你的实例的 ip 地址,其实是技术可见的。虽然普通网民可能无法继续追查下去;然而,对国家机器(不止是中国)而言,你的个人身份很难被隐藏。所以,如果你需要在 FBI 的层面上也保持匿名,自建并不是好的选择。

5. 你的高权限可能对别人造成困扰

隐私是把双刃剑。有时,做自己的站长,随之拥有的那些更高的权限,可能并不是其它用户希望你拥有的。譬如,你开设了一条投票,你所在实例的站长(也就是你自己),是有能力从数据库里看到,每个人都投了哪个选项的。这样,投票的匿名性,也就无从谈起。有时连开设投票的人也忘了这一点,如果投票的内容敏感一些,就会被怀疑,是不是在猥琐地窥私……这其实很无解。要在什么样的实例上投票,大家才会无视「站长能看到每一票」这种事呢?

6. 对 fediverse 世界造成更多负担

这不是个人选择是否自建时,需要考虑的因素。但我们至少要了解:现有 fediverse 世界的架构,随着实例数量的增加,实例之间通信的开销,会急剧上升。自建个人实例,会增大这种开销。如果 fediverse 的几百万用户,每个人都自建,是现有的结构无法承受的。这也是每个去中心化的网络体系,未来需要面对的问题。


P.S.

  1. 我不鼓励任何,对 Linux 系统管理没有足够了解的人,去自建 fediverse 实例。这件事的复杂度,已经超过了小白按照攻略 copy 命令的范围。即使按照攻略,成功把实例运行起来了,也有很大可能,在后期的系统维护、数据备份等方面,出现难以预料的状况;甚至影响自己的日常使用和表达。所以,虽然我也见过很多例外,一些技术新人把站点搭建的很好,甚至还写出了很棒的攻略;但总体来说,仍然不鼓励新人贸然尝试。
  2. 上面提到的每一项,对于不同人的权重是不同的。有的人可能很在意其中的某一点,而完全不介意另一点;甚至会认为我列出的「优点」其实是「缺点」。这些都很正常,所以每个人做的选择都会不同。当然,还是要自我分析一下,为什么每个因素在自己这里的权重是这样的?那些自己看重的,是否包含着「我技术上能做到」而导致的傲慢?而那些不看重的因素,又是否是因为长期「无法做到」,而对自己的妥协?
  3. 除了自建和注册现有实例外,还存在着其它方式。譬如 masto.host 提供代建实例服务,付费后可以使用自己域名作为账号。所以也会有一些类似于自建实例的特征吧。但具体怎么运作,譬如数据的备份格式和数据库访问权限,我就不清楚了。

Fediverse: 你的站长都能看到什么?

当你注册成为某个 fediverse 实例(mastodon pleroma misskey …)的用户时,你所在的实例,可能是几十万用户的大站,站长离你遥不可及;也可能是几十个甚至几个用户的小站,站长和你关系密切,每天一起聊天玩耍。但无论是哪种,你的站长,都能看到和你有关的哪些内容呢?我觉得这是你应该知道的。

首先,所有人都能看到的:

  • 你的个人介绍、和所有的公开文章
  • 你的文章被哪些人转发、点赞
  • 你收到的公开回复
  • 你的 following 和 followers,——在一些实例里可以设置,把你的 follow 列表对其它用户隐藏,但无论是否隐藏,你的站长终归能看到

然后,是你能看到,其它用户看不到,而且你可能也不希望别人看到的:

  • 你的所有非公开文章
  • 你的私信,——不光你的站长能看到,收信方的实例站长也能看到
  • 你的转发、点赞、书签,——和 twitter 不同,在 mastodon 里,你的点赞列表,其它人是看不到的
  • 你的注册邮箱,——再次建议,注册时不要使用公司学校邮箱、或 id 有明显个人信息的邮箱
  • 你每次访问实例的 ip 地址,——用户可以通过使用 vpn 来隐藏
  • 你 block / mute 了哪些人
  • 你给其它用户添加的个人备注
  • 你 follow 的人的文章,——即使对方设置了 follow request,文章默认对其它用户不可见,从你 follow 他的那一刻开始,所有你能够看到的他的文章,你的站长同样能看到

最后,是你作为普通用户也看不到,但你的站长能看到的:

  • 你开设的投票,参与的每一个人,都选了哪个选项
  • 哪些人 block 了你,——你只能一个个地猜测并确认,但站长能直接得到全部名单

还有哪些?欢迎大家补充~


P.S.

  1. 所有这些 fediverse 站长能看到的东西,当你用 twitter、facebook、或者新浪微博的时候,它们的管理员,当然也能看到。
  2. 当我说「站长能看到」的时候,我的意思是「站长有权限做到」。——大多数隐私内容,并没有一个管理界面,让站长简单地点击鼠标就能看见;而是需要在后台数据库里搜索,稍微有一点技术含量(不会比建站本身更难)。所以,有的站长可能根本不知道这些东西;更多的站长,我相信他们即使知道也不会去看这些东西。但他们终归有这样的权限。
  3. 我列出这些,并不是在论证,什么样的站长可以信任、什么样的站长需要警惕。——这是你自己要去判断、去抉择的事。我只是在告诉你,判断时需要知道哪些事。
  4. 一些其它的社交网络,是可以通过加密,让站长看不到这些信息的,譬如 nostr,但目前还没有广泛流行。——而且,「站长看不到」,并不意味着这个工具「更好」。整个 twitter 类型网站的结构,是建立在所有人所有文字都公开的基础上的。所有这些隐私设置,可以说,都是后来添加的功能补丁,不可能满足所有人不同的期待。所以,我只是在让你,更清楚「它能做到什么」,在此基础上,去思考怎样使用它。
  5. 列出来的这些隐私项目,其中相当一部分,是可以通过自建实例来避免的。但是一方面,自建的技术门槛比较高;另一方面,自己做自己的站长后,拥有的那些更高的权限,或许并不是其它用户愿意让你拥有的。更多这方面的讨论,可以看另一篇《Fediverse: 是否要自建实例

锁嘟机制

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