机场

看到 Richard Russell 在西雅图机场偷着开飞机上天的事件，也被一些女性讨论者，总结成「男蛆偷飞机造成森林大火，被男蛆叫好」，突然意识到自己对这个群体的违和感是什么了。

这些人，在「循规蹈矩」这一方面，其实是被加强了的。无论是在通过参政议政实现女性地位提升，还是在女性群体抱团的过程中，其实都在强化着「要在其它方面循规蹈矩，融入群体，才能用群体的力量去改变」这样的认知。于是，从对性别权利的反思，导向对其它权力结构的反思和批判，这样的过程其实未必存在。而是相反地：我已经努力地在这个框架里，混的很好了，如果性别权益能够提升，就更好了。

我并不想用「激进主义」这样的人群标签，而且说话的人，之前这方面的印象不是特别明显，所以这一次才让我印象深刻。但我确实看着一些人，在这个抱团的过程中，言辞渐渐极端化。不知这个过程，是否像兄弟会一样：你也要说出类似的言语，才能融入这个群体，并以此再吸引他人。

而「粉红女权」的存在，从这个角度上，其实也能说通了。以及一些以讨论求职升职为主要氛围的性别社区……当然，这些存在仍然是可以理解，甚至可以共情的。在已经很艰难的状况下，首先能做的是努力向上爬，这有什么不对吗？我也在反思，是不是「已经在框架中享有 privilege 的男性，才有去挣脱这个框架的 privilege」？但我觉得不是这个样子的。

只是又突然寂寥起来。就像那个最终开着飞机想去看鲸鱼的人，每天对着这片机场时的寂寥。这不是《末路狂花》，而是某种相反的东西。

主宾谓

之前聊到，日文、藏文的语序结构，和我们习惯的中文、英文不同，是谓语动词放在句子最后的「主语-宾语-谓语」的形式。

  • 中文、英文，是「主-谓-宾」。譬如：我-是-学生。我-想-你。
  • 日文、藏文，是「主-宾-谓」。类似于：我-学生-是。我-你-想。

：（吐槽）所以人们常说的，日本人懂礼貌，会听人把话说完。其实是因为这样的结构，需要认真听到最后一个词，才知道整个句子要说「是」或「不是」啊。

：对于需要使用不同敬语的日本人，也方便他们先把宾语对象列出来，再根据其身份，决定用什么样的敬语去修饰动词。

另一个 blog 有时候写得少的原因，大概是在「文章是在写给谁？」这方面，无意识地发生了混乱。

除去一部分

  • 技术贴
  • 分享有趣的经历或见闻
  • 对自己状态的描述、分析、展示

的篇目；其它很多文章，应该是（有意识或无意识地）有一个，潜在的写作对象的。他可能是

  • 现实中特定的人，可能是情感相关，也可能只是隔空喊话。当然，对方未必会来看；
  • 一个虚幻的，用来倾诉的对象；
  • 想要吐槽的某些现象，所代表的人群；
  • 预计会来看这个 blog 的读者们，不是特定的人，但有某种同温层特质；
  • 也可能，这个对象还是我自己。

于是，经常写到一半，突然意识到这个对象的存在，然后陷入「我这样写，有什么意义吗」的沮丧，也就不写了。

又或者，吐槽吐到一半，突然意识到，我所吐槽的特质，其实和来看 blog 的人，并不相关。于是反而担心，会不会让读者们对号入座产生误解，或者觉得我这个对空掰扯道理的样子很爹味儿之类的。

——就像在「主-宾-谓」的句子里，谓语写一半了，才意识到，那个预设的宾语的存在。

图床

趁着服务器搬家，打算把死掉很多年的摄影网站，重新恢复起来。把如今流行的自建图库程序看了一圈：piwigo、lychee……仍然没有哪个很靠谱。

其实我在浏览这些程序之前，并没有太多具体的需求，只是期待，快 10 年没看这类东西了，会不会有什么让我惊艳的产品。——并没有。而且，在体验每个程序时，都迅速地发现一些，让我觉得很不爽的点。于是，所谓自己的需求，就是在这个不断吐槽的过程中形成的。

除了最基本的

  • 便捷的上传
  • 并不是难看到很离谱的展示界面

之外，

如果，我要的是一个图床，那么我需要——

照片的 url 和我本地储存的目录结构和文件名是一致的，类似于

https://..../blog/20230909_1.jpg
https://..../blog/20230910_cat.jpg

而不是

https://..../21/27/4c1b46114f8.jpg

这样的东西。前者的文件名，在编辑文章时便于管理。而且，以后迁移图床时，可以统一替换图片 url 的前缀，实现无缝迁移。

如果，我要的是一个摄影作品的展示网站，那么我需要——

！！！不要在网页的任何地方，显示多余的 exif 信息！！！

感觉这十年来，所有的图库程序，都把心思花在，如何去识别各种图片格式的内嵌 exif，然后把它们各种花式归档、搜索、展示……展示在网页边角、在动态的弹出菜单、甚至悬浮在照片上面。——我不需要啊！谁要在摄影作品上，标明照片的 exif 是哪天拍的，甚至是哪天上传的啊！！我连标题都不想展示啊！

甚至，各路图库程序比拼的重点，已经变成了如何调用外部地图软件，然后把照片根据 GPS 信息显示在地图上。（翻白眼

如果，我要的是一个管理图片的工具，能够便捷地挑出一些照片来展示。那么我需要——

在一个相册里，可以便捷地拖动更改，照片之间的顺序。而不是靠手动修改文件名这种粗糙的排序方式。

没有。能够满足这些需求的哪怕其中之一的，都没有。有一些静态网站生成程序，能够把已经彻底整理好的照片，生成看着还行的展示网站。但与其一个个试过来，再试着根据自己需求去魔改各种瑕疵；我觉得我还是在 wordpress 上慢慢拼吧……

于是又变成了

打算做点啥 → 考察相关的工具 → 做不成，开始吐槽各种工具……

以及，在这些干扰下，想趁此机会整理从前照片的希望，大概又落空了……不仅仅是在一些照片里的人，我不想去回顾。也包括，在翻看以前照片时，仍然能够识别出的，自己当年用摄影的视角，去凝视世界的方式，以及对这种方式本身的思考和改变。——我现在是否适合，把这种方式，重新调用起来？

苟富贵

最近好几次在对话里，见到类似的思路。譬如

：你不用担心瓶盖的密封是不是靠谱，泡在洪水里是否受污染。这个工艺已经很成熟了，制造商都在卷。如果某一家做的不靠谱，被人发现了，它家自然会倒闭的。所以大家都会靠谱的。

又或者

：手游公司肯定会出这个角色的，毕竟很多人想要。公司要赚钱的啊。

这样的思路并不难反驳，譬如

  • 把群体趋势和个体行为混淆；
  • 监管都未必能保障的事，「用脚投票」就能做到？
  • 大环境下，是否所有人都以「赚钱」为目的？

但我更关心的，不是这些话题本身是什么答案，而是，说话的人，是怎样不暇思索地，用这种新自由主义的思路，来解决问题的？——或者说，潜意识里以为祭起了这个思路，就可以解决问题的？

毕竟，在这种思路的对话里，近期给我印象最深的是——

：我们（在上海疫情封城期间）过的很好啊。毕竟，只要小区物业想赚钱，他们终归会想方设法提供各种服务，把我们照顾好的啊。

苟日新

突然被人跑来问，是怎么做到写博客坚持这么久的，而且可以持续输出？

（荣幸地，拿起话筒：）啊，我不觉得我这个样子，叫做「持续输出」啦。早就连每月一更都不能保证了，而且那些技术相关的帖子，在我心里都不能算是「更新博客」的，用这些凑数也为我自己所不齿……

但我看到这个问题时，首先想到的，一个很重要的因素：大概是因为，这个站就一直在这儿吧~ 我的技术能力，不需要花什么额外的精力，就能让这个 blog 一直存活下去。于是，想写东西的时候，这里始终有个地方，可以让我写。

——也有很多时期，是完全写不下去的，长时期没法去面对、去反刍自己的生活；然而也没必要因此而关站，就让 blog 存活在那里，终归是个表述的出口。大概是因为，我也是希望，自己能够从那些「无法整理自己」的状态中，渐渐走出来，回复到可以写东西的状态吧。所以站点的持续存在，满重要的，因为确实能感觉到，想写点什么的时候，如果没有这么个站，又或者需要自己重新架一个，可能也就不写了……

这种「随时可以在站点写东西」的状态，也影响着对 blog 平台的选择（怎么又拐到技术贴去了？好吧，之前也一直想吐槽这方面，就顺带提一下）。这些年一直有 〖wordpress vs 各种静态博客〗哪个更好的争论。双方确实各有利弊。总体来说，静态博客最大的优点就是……省钱，可以薅 github、vercel 之类托管网站的羊毛。但另一方面，静态博客每次发布、或者修改一篇文章的过程，其实满折腾的。通常情况下，它需要

  • 一台固定的电脑，安装静态博客编译程序，并且从这台电脑发布到 github 的专门权限。而不是随便打开一台电脑或手机，从浏览器就能编辑发文；
  • 每次发文时的一系列专门操作。

我不乏看到有人，好久没有更新，突然想写一篇文章时，忘了怎么操作，翻出攻略来重温一遍；甚至忘了连接 github 的 ssh-key……可能别人觉得这样的折腾无所谓，或者自我管理优秀的话，不会出现这种情况。但我个人觉得，这是会在主观上，影响发文章的状态的。所以，随便在任何地方任何电脑上都能直观地发文，感觉还是蛮重要的。

好像也是可以通过一系列操作，实现用浏览器某个网站上编辑文章，然后自动编译发布到托管网站的。我没有仔细去关注。但是，如果把 blog 的生命周期，放到 5~10 年这个尺度上，那么这些网站之间的复杂依赖关系，很大程度上是不靠谱的。譬如我已经看到好几个静态 blog 的外挂评论系统，不知为什么不工作了……总之，相比之下，我可能更宁愿去使用那些免费带广告的 blog 平台。

我对写 blog 的新人的推荐，一直是——

  • 如果有技术能力、也有服务器的话，自建 wordpress；
  • 或者找人蹭一个。如果我们比较熟，你可以去买个域名，把 blog 挂在我的服务器上。这并不是很大的负担。（ps，个人 wordpress 小站，是可以不必安装开销很大的 mysql 数据库的）；
  • 如果上面两条都不行，那么，我优先推荐去注册现成的 wordpress.com 或者 blogspot.com，目前看起来，长期靠谱的只有这两家了。虽然免费版界面不好看、还有广告，但长期写着应该没问题的；
  • 当然，我不会给乐于尝试静态博客的人泼冷水。但我会根据你的技术能力和气质，暗戳戳地担心：
    • 你能坚持写多久；
    • 你写出来的，会不会很多都是关于你怎么建站的经历和心得……

转一张图，对于熟悉这十几年来 blog 平台变迁的人，应该会很搞笑：用不同工具写 blog 的人，（写 blog 文章）vs（写关于怎么配置 blog 的文章）的对比。右下角那些术语，都是在各个年代，需要各种不同程度的折腾的，静态 blog 方案：gatsby、org mode、jekyll、hugo、git workflow……

ps，两个月前，用这段代码方案，把我在 twitter 的所有 po 文，都导入到了自建的 mastodon 里。Twitter 那边，应该会随着 Elon Musk 的各种不靠谱折腾，渐渐放弃掉了吧。而每条推文的字数限制，从 twitter 的 140 字，变成 mastodon 的 500 字后，很多几百字的感受，要不要专门写到 blog 这边来，就比从前，更让人犹豫。具体怎么处理，我还没想好。

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 在后台写入媒体文件时，仍然可能出现文件夹权限不足，无法写入的问题。

里世界 – 6

看到年轻人旅行回来，继续打着鸡血，说「____那里很好，想时不时去呆上一阵」，突然意识到，自己最近这几年，纠结的点之一，在于：已经没有那样的地方了。

——任何看上去很好，可以待着很欢乐的地方，或者人群，都需要我放弃一些方面的思考，才能去融入。而能够在这样的环境下安然欢乐，很大程度上，也是因为选择了去无视某些，这个环境里没有被提到的东西。然后，这种「无视」本身，作为一种文化，也会让安然其中的人们，发生变化。

那些没有提到的东西，包括但远远不限于：各种权力的体现（政治、性别、阶层……）、消费主义、对认同感的依赖和屈从、对多样性的接受以及主动探索……这些年研究文化对人的影响，也就对那些「无视」导致的变化，感知更加明显。

可以说，那些坚持去思考的东西，叫做「执念」。但「执念」这种说法，仍然只是为了舒适而放弃某些东西后的自我解释。

而我这些年的变化，也是从「要不要为了在这样的地方快乐生活，而改变呢」；

变成「不想改变的话，就真的没有这样的地方了吗？再努力找找吧」，然后因为找不到而焦虑，渐渐又因为意识到这样的地方不存在而焦虑；

再变成「这样的地方不存在，那又能怎样呢」，然后再分析，那样的一个理想化的环境，——无论是期望现实中存在的，还是在脑海中凭空构造的，——它对我的吸引力，是由哪些因素导致的呢？很多因素，经过这样的分析后，都可以选择从自我身上去剔除（aka 修仙）。

Stop finding neverland，不是因为要脚踏实地了，而是接受「没有」的状态，让自己根本不再需要，任何形式的 land，作为支撑。

当然，能够去玩得很开心的地方，我自信还是能找出很多的。但世界总体，仍然只是旅程。

评论区

如今很多 blog，尤其是这些年新人们搭建的静态 blog，都是没有给文章留言评论的功能的。

（略过 wordpress 和 hexo、hugo 等静态引擎对比若干）
（略过静态 blog 外挂评论系统的技术难度和优劣若干）

最近读的一篇文章，让我想要和作者讨论一些感受，然而却没有评论的地方。——其实我是有作者的其它社交网络账号，甚至在聊天软件上加了好友的。但总感觉，在其它地方，另外开启一串讨论，有些违和。以及和文章的话题也有关系吧，一些和内心情绪相关的话题，反而不适合凑上前和人家私密地聊感受。文章底部的评论区，是个我觉得合适的，或者说在我的认知中习惯了的，豪猪之间的距离。

也许人家就是因为不想有这样的讨论，才不设评论区呢？
——但也许人家并不是这样想的呢？也许他在这篇文章想要有人讨论，而那篇文章则不想，而无论想或不想，和他有没有在 blog 里加评论系统，并没有任何关系。所以那些「想 or 不想」，其实都只是我自己通过臆断，试图对当前状态的一种解释。甚至再从这样的解释，为自己总结出莫须有的规律和准则。

包括我觉得「评论区更舒适」，仍然是一种非常自我的总结。如今连 blog 都没几个人写，仅有的几个用户，也是不同年代不同环境不同引擎。于是，这种自以为的总结，不可能是被很多人共鸣认可的准则。所以真的有存在的必要么？

这种纠结的心态，大概来源于，自己在日常的其它方面，被这种潜在的总结准则所扰。虽然我在反思后，是倾向于让这些准则变得不存在的；但对很多人而言，似乎仍然是存在的（这个我不觉得是臆断），并以此构建出交流的障碍。

当然，即使如此，从权力关系的角度，这也不是让我能够有了感受就可以肆无忌惮地把读后感塞给人家的理由。（这是另一种纠结了……

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