我的 Misskey 帐号
如果不关心我搭建 Misskey 的过程，只是想观察我表达欲过旺的产物的话，可以直接关注我的 Misskey。移步 https://m.chariri.moe/@chariri ，或使用任意 Fediverse/ActivityPub 社交平台实例，如任一Mastodon、Misskey或Pleroma实例，关注 @chariri@m.chariri.moe 即可。我会把我的一些日常和想法
发在上面。
因为此实例为个人实例，暂不开通注册。
关于本系列
本文是笔者计划写的系列《自建折腾记》的第一篇。此系列记录了笔者在自己刚租的服务器上折腾三个自搭建（self-hosting）服务的过程。这三个服务分别是分布式短文社交平台 Misskey、分布式即时通讯工具 Matrix（实际上用的 Dendrite 作为服务器软件）与密码管理器 Bitwarden（实际上用的 Vaultwarden 作为服务端）。
什么是 Misskey
Misskey 是一个兼容 ActivityPub 协议的 Fediverse 短文社交平台。简单地说，它就像去中心化的 Twitter 或 微博。这些平台的“分布性”体现在：互联网上有许多服务器，运行着这些平台软件。这些服务器相对独立，而用户就注册在这些服务器（为讨论方便，把用户注册的服务器称为其的Homeserver）上，他们可以在服务器上发类似推文或微博的短文，体验和 Twitter 类似。然而，如果用户只能和 Homeserver上的人社交，那就太无聊了（当然，也不是不可以，后面会提到）。
因此，上述问题就引出了“联邦”的概念。在 Fediverse（联邦宇宙）中，各服务器之间使用统一的协议进行沟通，建立起了“联邦”关系。联邦关系让一台服务器可以将用户发的内容（有条件地）同步到网络中的其它服务器。这样，我可以在自己的服务器上关注其它服务器的用户，在我的时间线上看到他们发的短文，并评论、转发、点赞。甚至，我可以在全局时间线上看到所有和我的Homeserver联邦的服务器发来的内容（Misskey 世界称为 Note，对标 Twitter 的推文、微博的微博和Mastodon的嘟文）。
当然，数据的同步是有条件的，一般服务器并不会把所有本地用户的动态转发到所有服务器。后方会详细讨论这带来的问题。
那么，为什么要离开 Twitter 或者微博这样的中心化的社交工具，而转而使用一个更复杂的方案呢？答案是显而易见的——为了掌握数据的控制权与规避平台对内容的影响。
通过去中心化社交，个人的数据的掌控权从 Twitter 或微博转移到了他们的 Homeserver。同时很多平台软件提供了方便的将 Homeserver 导出的工具，进一步让用户在各个 Homeserver 的迁移成为了可能。至于平台，Twitter 在被 Elon Musk 收购后开始高强度发病，而夹总就众所周知了。同时，这些平台也让我们逃离推荐算法成为了可能，一定程序上避免了被动信息茧房的形成。另外这些平台也对 Bot 更友好。
实际上，Fediverse 的短文软件远不止 Misskey。短文平台还包括最成熟、用户最多的 Mastodon、Pleroma和轻量的 Soapbox。还有一些非短文性质（如分享视频）的平台，如PeerTube。更多常用平台可以去 https://fediverse.party/ 了解。而相较于自建平台的人，远远更多的人会选择加入一个已经有很多人的 Fediverse 平台。一些常见的实例包括：
- Misskey.io：Misskey社区最大实例，日语为主
- Misskey.cf：Misskey社区比较大的日语实例
- mstdn.jp：Mastodon日语比较大的实例
- m.cmx.im：长毛象中文站，Mastodon简中最大实例，巨量键政内容
- o3o.ca：嘟站，Mastondon简中较大实例
- wxw.moe：呜呜站，Mastodon简中较大实例，ACGN主题，一般禁键政
- hello.2heng.xin：小森林，Mastodon简中的中小实例，ACGN/萌宠主题，一般禁键政——笔者在建设自己的实例之前，就在这个实例上玩
- nya.one：喵窝，Misskey简中中小实例，ACGN主题
可以注意到很多实例有比较明显的“主题”。在这些实例的“本地”（即所有本服务器内的用户的动态）会和这些主题强贴合，适合对这些主题有兴趣的人加入。在足够大的实例上，有很多人会检查自己Homeserver的本地时间线。
另外，笔者希望避免任何Web3.0、区块链相关的的讨论，因为熟悉我的人可能知道，我一向是对这些东西相当敌视的。
机器信息
这个系列中的三个服务均部署在笔者新租的 AWS Lightsail 服务器上，配置是 2 vCPUs, 4 GB RAM, 80 GB SSD，20刀一个月。目前看来略显捉襟见肘，后续如果有严重的性能不足的情况，会考虑升配。
机器系统使用 Ubuntu 22.04 LTS。
安装
本体安装
这部分的官方教程：https://misskey-hub.net/docs/install/docker.html
笔者基本所有的服务部署都用的 Docker Compose，实在是太好用辣 (`ヮ´ ) 当然 Compose 也是 Misskey 官方推荐的安装方式。
Misskey 需要用 Redis 和 PostgreSQL 存储会话和持久化数据，要一并安装所有服务，只需要 clone 下 Misskey 的仓库（https://github.com/misskey-dev/misskey.git），并将 docker-compose.yml.example 文件复制为 docker-compose.yml 文件，编辑即可（实际上，笔者就留着默认基本没动，除了调整监听设置让 Misskey 不监听在公网上）。
默认情况下，Misskey 并不会启用 Elasticsearch，我大概没有用 ES 的必要，因此也没有启用。
除了 docker-compose 文件，还有两个文件需要编辑：
- 将
.config/docker_example.env文件复制为.config/docker.env（这里的文件和docker-compose.yml里的db节中的环境变量文件名一致），调整里面的数据库信息。 - 将
.config/docker_example.yml文件复制为.config/default.yml，并进行设置（笔者只调整了url和数据库设置）。
在这之后，就可以执行以下命令构建镜像、初始化数据库和启动实例了。
sudo docker compose build
sudo docker compose run --rm web pnpm run init
sudo docker compose up -d笔者习惯在最后一条命令上不加 -d 参数，先运行一次确保能正常启动，再换成 -d 参数放到后台执行。
反向代理配置
在配置文件样例中有提到，Misskey本体并未包括SSL功能，因此必须配置一个反向代理来提供 HTTPS 服务。笔者使用的是 Caddy，因为其配置方便直观，自带 SSL证书自动申请，同时笔者也用不上nginx那么高的性能（实际上，笔者已经把blog也迁移到了Caddy上了，因为事不是特别多就不单独写一篇文章了）。
笔者的 Caddyfile 中关于 Misskey 的配置十分简短，如下：
m.chariri.moe {
reverse_proxy 127.0.0.1:3010
encode zstd gzip
}注意我的端口换过了，因为冲突问题。默认应该为 3000 端口。当然，域名和DNS也要相应配置。按理说，这里应该配置一个 Cloudflare 保护，但笔者不是很想挂减速器，也不太喜欢 Cloudflare。如果哪天被DDoS打了就关站吧（sigh。
配置好后，重载 Caddy 配置，等待SSL证书自动申领后，就应该能进入第一次安装界面了。
（此处应该有张截图，但当时装的时候忘截了）
服务器配置
注册管理员帐户后，第一件事当然是去左侧的控制面板完善服务器设置。第一次配置的重点在“设置”节的“常规设置”等。
值得一提的是“常规设置”里有一项“远程文件缓存”。笔者最开始没有启动，结果在接了一些大服务器后发现服务器硬盘迅速地被来自各大站的图片灌满了……还是关了为妙
外部服务而言，笔者的配置很简单，没有 S3 等资源服务器或 DeepL 翻译，仅仅配置了SMTP邮件服务器和Turnstile验证码服务，以及喵窝的喵家中继（后面会提到中继服务器的作用）。
最后，笔者更新了自己的个人 Profile，即算配置完成了。(*ﾟ∇ﾟ)
