Conversation

和很多朋友们一样，我也是在 2022 年底 Twitter 大地震的时候了解到 Fediverse 的，当时希望找到一个 Twitter 的替代产品。
考虑到 Fediverse 个性化体系比较丰富，因此计划寻找一个中小规模的 Mastodon 实例加入用于尝鲜，在多方比较之后，最后选定了 bcom.moe 作为我首个 Mastodon 服务器（这里要感谢当时的站长 @billchenchina@bcom.moe ）。在完成注册审核流程后，在 2022-12-24T17:05:03.663Z 我发布了第一篇内容 "你好 Mastodon!" 开启了我的 Fediverse 历程。随后在 8 个月的历程内与各位朋友一起互动，共创建了 58 条嘟文。
然而由于 Mastodon 媒体代理默认只能在 10 分钟只能加载 30 张图片的限制，以及个人关注用户内容发布倾向的原因，我经常会撞到媒体代理对代理媒体的频率限制，从而大量图片处于无法展示的状态。当限制被触发的时候，只能通过 "打开原始页面" 功能看发图内容。为了避免浏览流程被一直打断，通过文字内容脑补图片内容已经成为了刷嘟的必修课。
通过我实测发现，在快速浏览图片数量较多的账户时，浏览器每分钟可以发起 200 余次媒体代理请求。模拟正常用户场景的话，将默认的 10 分钟只能加载 30 张图片调整为 5 分钟允许加载 300 张能够基本保证流畅浏览。为了解决此问题，我于 2023 年 1 月 3 日向 Mastodon 提交了 Change rate limit for media proxy 的 PR 以放松对媒体代理的图片限制，但截至发稿时 PR 仍未被合并。详细信息可以参考 https://github.com/mastodon/mastodon/pull/22919 。
等待半年之后的 2023 年 7 月，我感觉这种无限期等待不是办法，于是计划迁移到一个新的实例来解决此问题。随后我找寻了我 Fediverse 好友中非 Mastodon 的服务器，并重点评估媒体代理频率限制问题。
我于 2023/7/22 22:23:03 在 DVD.Chat 注册了账户（这里要感谢站长 @dvd@dvd.chat ），并积极考虑迁移相关问题。在评估迁移问题时发现 Firefish 只能导入原创嘟文而不能导入转嘟，且导入逻辑存在问题。因此首先由 DVD 于 2023 年 8 月 12 日向 Firefish 提出了导入主题的优化建议，但由于 Firefish 开发人员波动导致 3 个月没有动作。 2023 年 12 月 22 日我决定从被动等待逻辑实现转向自主实施导入逻辑优化，向 Firefish 提交 MR 以增加对转嘟的导入功能。在 Firefish 局势稳定之后，导入功能由 naskya 完成审阅并正常进入发行版本。
在新版本发布之后，我也于 2024 年 2 月 24 日正式完成转嘟数据全量导入和账号迁移，并于 2024/2/24 02:00:59 上发布了 "你好 Firefish!" ，从而展开了与 Firefish 共同走过的历程。在账号迁移完成后，为了进一步优化 Firefish 体验，向 Firefish 程序贡献了三十余个 MR 从而修复既有系统 Bug 和新增部分合理需求。
但由于工作繁忙，自 8 月末至 10 月末无暇关注 Fediverse 和 Firefish ，因此暂离了 Fediverse 和 Firefish 一段时间。没想到短短两个月暂离 Firefish ，再次相见竟只是一纸 Firefish 进入维护模式并在年底终止支持的离别公告。
回想刚才所写的文字，我不禁想起一句更能映照我当下心境的话："已经无法回到过去了。也不知道将来会是什么模样"。我的 Fediverse 经历像一叶扁舟在波涛滚滚的大海中飘荡，不知未来会如何，不知前路在何方。
衷心希望 Fediverse 能行稳致远，陪伴我们走向更加光明的未来。