到现在为止，并没有找到最合适的解决方案（目前最靠谱的是 Nextcloud Talk 和 Voce Chat）。先把过程中考虑到的一些因素，记录下来，作为借鉴。

我的目的，是如何更便捷地，和墙内小范围的朋友、家人，保持联系，在对话中不受信息审查。现有的聊天软件，能够不翻墙使用的，几乎没有了，即使有，也不是长久之计。所以最靠谱的方式，大概只有通过一台海外的 vps，自建服务，供小范围的人使用。如果传播范围不大，除非 gfw 变成白名单，否则应该都可以长期使用。

下面是选择各种自建聊天工具时，会考虑到的因素。这些因素之间，有些是互相冲突的。对不同需求的人，在这些因素之间考虑的权重，也不一样。对于我上述的需求来说，

• 不需要考虑的因素，用黑色显示；
• 希望能有，但没有也无所谓的因素，用蓝色显示；
• 非常希望能满足的因素，用绿色显示。

首先，我希望这是一个可以挂机的聊天工具，可以在收到信息时，从手机接收到通知；而不仅仅是个网页聊天室，只能在专门打开网站时，才能聊天：

• 可以持续挂机，通过 app 或者「Chrome 把网站添加到桌面」的功能，实时接收来信通知；
• 除了手机外，也能在 pc 的浏览器里使用；

要联系的人，并不擅长电脑技术和操作，因此

• 不需要翻墙使用；
• 操作简便；
• 有中文界面；

这些人，可能并不属于同一个群体。所以，需要为不同的人群，架设不同的服务地址，互相分开。

• 在一台 vps 上，同时部署多个聊天服务。一些功能更加完善的聊天服务如 xmpp，因为需要独占端口，并不能满足这一点；

安全性方面：

• 信息加密；
• 开源；
• 不和中央服务器连接，一些 self-host 的服务，会经常连接开发者的服务器，虽然只是检查升级或校验程序完整性，但还是看着心虚；
• 完全通过域名交互，不向其它服务器暴露 ip 地址；
• 用户之间的私信，对管理员也不可见，否则，其实开个 fediverse 实例，可以满足这里很多条要求；
• 用户之间不会互相暴露信息，譬如很多协同工作平台，可以互相看到所有用户的名单、email……

架设系统的便利程度：

• 支持 docker + nginx 部署，或者直接放进 php 目录就能运行；
• 系统开销小，内存上 G 的那种就算了吧；
• 不需要 mysql 等专门数据库，因为规模不大，sqlite 就足够了；
• 能部署在网站的子目录下，不需要独占一个子域名；

对聊天功能的需求：

• 是否要加入去中心化网络，和其它服务器的用户交流？对我来说，这不是必须的。而且这在部署的便利性、轻量级、安全性、同时部署多个服务……等方面，都会造成冲突；
• 可以群聊，也可以一对一私聊；
• 可以传输文件；
• 支持语音；
• 支持视频；
• 注册过程简洁，可以由管理员直接生成账户；
• 可以关闭对外注册；

……………还有什么要补充的吗？

---

已经考察过的工具

其实最理想的，应该是一个 php 的聊天室……能通过 chrome 在手机桌面接收消息通知就可以。轻量化、可以塞到任何目录下、没有中文我自己汉化也可以。但是，真的没找到靠谱的…………求推荐！！！

ps，如果联系人有一定电脑常识，也懂英文的话，用 mycryptochat 做临时沟通，蛮好用的。

目前最合适的，是 Nextcloud Talk，用 docker + sqlite + nginx，是可以做到快速部署的；占用内存不到 300MB，勉强可以接受（所以开销更高的方案，基本不考虑了）；而 nextcloud 作为一个庞大的办公平台，其 web 界面对于非技术人士，未免有些眼花缭乱。

xmpp 和 matrix 服务器，可以做到开销更小，但也在 100MB 以上，还涉及独占端口的调整，部署起来繁琐很多。似乎也可以把跨实例通信的功能关掉，做成封闭社区，配置和开销会简单一些。但还没仔细研究。

各种协同平台类，如 Mattermost、Rocket.Chat，系统开销过大，就算了。

这两年有个国人开发的 VoceChat 工具，评价很不错。可以 docker + nginx 部署，内存 30MB，有 web 界面和自己的 app。推荐大家可以试试。目前发现的一些问题：

• 免费 license 有 20 个用户的限制。 问题不大；
• nginx 不能反代到子目录，只能独占域名的根目录；
• 可以看到其它用户的 email，但用邀请码注册的话，可以填假的，不用验证；
• 最大的问题：VoceChat 的语音聊天模块，是外挂的 agora.io，——是著名的大陆运营商，当年 clubhouse 因此遭受很大质疑。所以，不要用它的语音功能谈关键的信息。进而，这个软件的文字聊天的安全性，虽然是开源，但使用官方 docker 时，也让人有些嘀咕了。

虽然大家写 blog 的频率都没那么勤了，但是，RSS 还是有其它可以玩的方式的！

很多人都有用各种 read it later、或者书签类工具，把有意思的网页保存下来。在这些工具里，可以通过某些手法，把一些想要分享的网页，生成 rss。其他好友订阅这个 rss 地址，就可以自动刷新，看到你推荐的文章啦！

下面介绍一些，常见的书签网站，生成 rss 的方式。但首先——

• 这些生成的 rss 地址里，大多都内嵌着网站的验证码，容易泄密，也冗长而不简洁。强烈建议：得到 rss 后，先用 Feedburner 之类的网站，转成新的 rss，再分享出来，可以去掉原先网址里的隐私信息。
• 很多网站，并没有专门用来 share 的分类，只能通过曲线手段，把已经 archive 或者 star 的类别分享出来。这可能会影响你原本的使用习惯。
• 一些网站生成的 rss，并没有全文，甚至只有标题和链接地址。没关系，能看到大家的推荐，就已经很好了，自己点开就可以啦。
• 大多数 rss 订阅工具里，也都有发送给 read it later 的功能，可以辗转着，把自己订阅的文章分享给他人。

我的 RSS 分享地址是：

https://feed.fivest.one/readings
或者
https://feeds.feedburner.com/fivestone/readings

有兴趣和我分享的，欢迎留言或私信交换！！

---

Instapaper 免费版

感觉 Instapaper 生成 RSS 的功能是最好用的，可以把特定的文件夹设为公开，直接得到它的 rss，形如：

https://instapaper.com/folder/1234567/rss/123456/Vciysdfsd7mod9B

• 在左边栏创建新的 Folder，存放想要分享的文章；
• 进入这个 Folder，在页面上方选择 Edit，设置成 Public；
• 点击页面右上角的下拉菜单，选择 Download；
• 下载为 RSS Feed，就得到 RSS 地址了。

Pocket 免费版

好像 Pocket 的免费用户，内容都只能是公开的（无语…），只要知道了用户名，就可以通过 RSS 查看全部的内容（所以生成的 rss 需要转录才安全）。而且不能自定义分类，只有默认的：

https://getpocket.com/users/USERNAME/feed/all
https://getpocket.com/users/USERNAME/feed/unread
https://getpocket.com/users/USERNAME/feed/read

最后一条 …/read 会返回所有 Archived 了的文章，可以勉强用它作为分类的手段。

Readwise

这个只有收费版，我就不去试了。有它家的用户，可以帮忙把生成 rss 的方法分享一下？

Wallabag

我在用 Wallabag，可以自建，也有收费的服务可用。生成的 rss 是全文输出，效果很好。在 Config – Feed 里，生成一个 token，然后点开任何一个 tag，点击列表上方的 rss 图标，就可以得到这个 tag 的 rss 订阅（生成的地址里带着统一的 token，所以需要转录才安全）：

https://wallabag.your.domain/feed/USERNAME/asdfghjkl/tags/t:share

趁着服务器搬家，打算把死掉很多年的摄影网站，重新恢复起来。把如今流行的自建图库程序看了一圈：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 上慢慢拼吧……

于是又变成了

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

---

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

本攻略适用于——

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