之前和人聊到，自建 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. 成本：时间、金钱、服务器开销
即使不考虑技术门槛，和架设、维护站点所花费的时间成本，单纯只是花在域名和服务器上的费用，每年大约需要人民币 ￥500-1000。当然，在这样一台服务器上，除了自建 fediverse 实例外，同时还能做很多其它事情。而有技术能力自建的人，很多也早已购买了 VPS 服务。
4. 额外的身份泄露
在其它实例注册时，虽然你的所有文章和信息，对站长都是技术可见的；但除此之外，站长（以及可能存在的审查人员）能够得知的，也只有你注册时的 email、和访问实例的 ip 地址。如果个人隐私保护的比较妥善，从这些信息，并不会泄露你的真实身份。
而自建服务器，是会泄露更多信息的。包括你注册域名、购买服务器时，所填写的信息（这个可以作假），和信用卡等支付方式。虽然域名可以隐藏在 cloudflare 后面，但你和其它实例交互时，你的实例的 ip 地址，其实是技术可见的。虽然普通网民可能无法继续追查下去；然而，对国家机器（不止是中国）而言，你的个人身份很难被隐藏。所以，如果你需要在 FBI 的层面上也保持匿名，自建并不是好的选择。
5. 你的高权限可能对别人造成困扰
隐私是把双刃剑。有时，做自己的站长，随之拥有的那些更高的权限，可能并不是其它用户希望你拥有的。譬如，你开设了一条投票，你所在实例的站长（也就是你自己），是有能力从数据库里看到，每个人都投了哪个选项的。这样，投票的匿名性，也就无从谈起。有时连开设投票的人也忘了这一点，如果投票的内容敏感一些，就会被怀疑，是不是在猥琐地窥私……这其实很无解。要在什么样的实例上投票，大家才会无视「站长能看到每一票」这种事呢？
6. 对 fediverse 世界造成更多负担
这不是个人选择是否自建时，需要考虑的因素。但我们至少要了解：现有 fediverse 世界的架构，随着实例数量的增加，实例之间通信的开销，会急剧上升。自建个人实例，会增大这种开销。如果 fediverse 的几百万用户，每个人都自建，是现有的结构无法承受的。这也是每个去中心化的网络体系，未来需要面对的问题。
P.S.
- 我不鼓励任何，对 Linux 系统管理没有足够了解的人，去自建 fediverse 实例。这件事的复杂度，已经超过了小白按照攻略 copy 命令的范围。即使按照攻略，成功把实例运行起来了，也有很大可能，在后期的系统维护、数据备份等方面，出现难以预料的状况；甚至影响自己的日常使用和表达。虽然我也见过很多例外，一些技术新人把站点搭建的很好，甚至还写出了很棒的攻略；但总体来说，仍然不鼓励新人贸然尝试。
- 上面提到的每一项，对于不同人的权重是不同的。有的人可能很在意其中的某一点，而完全不介意另一点；甚至会认为我列出的「优点」其实是「缺点」。这些都很正常，所以每个人做的选择都会不同。当然，还是要自我分析一下，为什么每个因素在自己这里的权重是这样的？那些自己看重的，是否包含着「我技术上能做到」而导致的傲慢？而那些不看重的因素，又是否是因为长期「无法做到」，而对自己的妥协？
- 除了自建和注册现有实例外，还存在着其它方式。譬如 masto.host 提供代建实例服务，付费后可以使用自己域名作为账号。所以也会有一些类似于自建实例的特征吧。但具体怎么运作，譬如数据的备份格式和数据库访问权限，我就不清楚了。
Leave a Reply