mastodon

There are 9 posts tagged mastodon (this is page 1 of 1).

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: 是否要自建实例》

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 这种完全建立在实名上的讨论群体，以及随之关联的发言规范，和我完全就是不同的世界，索性不予评价。