我好像明白了点什么，之前一直没注意，就是：不少并无过往交流的账号的关注，可能是和实例本身给出的「你可能感兴趣的用户」推荐有关。
但是 #mastodon 的推荐机制应该是十分菜的吧。
#Mastodon 实例管理者如果不是很闲总去看后台数据的话，对自己实例有多少人、这些人都发了哪些内容……很难有直观概念。
因为前台界面里，比如首页、比如本站轴、比如用户目录……之类的地方，新注册的帐号其实默认并不会全都收录其中。
再加上忘记哪个版本大概是 3.4 版本更新之后新注册用户不会默认关注管理员，所以……
这一部分是好是坏还真不好说，毕竟有时候实例管理者需要留意成员数量和发布的内容类型（图片？视频？）来权衡自己在服务器相关设施上的投入。
有什么方便点的方法批量添加大于50k 的表情图吗？
#Mastodon V3.4 之后，图片文件最大尺寸变成 1920×1080 了。
感觉这对实例主来说实在是有些浪费。
毕竟，其实大部分图片，其实发布的时候也不是想着越高清越好，而只是懒得缩小尺寸而已，就保持原始状态发布了。
或许像一些即时通讯软件那样，由发布者选择是否上传「原图」更好些。
说出「禁止转出长毛象」这种话的嘟友应该问一下自己：
和 #Mastodon 互通的 #Pleroma 在不在禁止之列？ #Misskey 在不在禁止之列？安装了联合插件的 Wordpress 在不在禁止之列？
要知道这些都不需要别人转，发布者只要公开发布了，这些「长毛象之外」的地方就有可能自动获得。
去年年初看到数据说全球排名前1000万的网站里有三分之一是用 Wordpress 建站的。
以及，支持 #ActivityPub 协议的网站在不在禁止之列？任何现有网站都可以加入该协议支持：
https://www.w3.org/TR/activitypub/
所以到底是在禁止什么？
----
其实倒也不必纠结，虽然任何有公开链接的内容都可以通过链接形式传播，把链接贴到微博、贴到微信都是很正当的操作，但是打上「禁止转出长毛象」标签的内容，往往也实在没有什么转载的价值。
虽然我效率很低，但是总算还是实现出来了——完整的一套流程：在博客文章页面展示相关嘟文的公开回应内容；匿名添加新的回应。
可以在这个页面查看演示效果：
https://kaix.in/0001/webmention/
给大家表演个手冲 #咖啡 吧：
https://www.bilibili.com/video/BV1Qz4y1U7y3
---
在妳想往 #Mastodon 上传个视频的时候就能发现自建平台还是有其局限性的。
提供本地压缩好再上传的客户端也少，平台本身又有存储和带宽压力。
总之在微博、微信、知乎之类的地方可以轻松上传的视频，在 Mastodon 往往会提示妳「视频太大」。
请教一下，sidekiq 信息里出现大量失败任务：
ActiveRecord::RecordNotFound: Couldn't find Account with 'id'=-99
是怎么回事……
我好像在 postgresql 里手动删了 id 为 -99 的帐号，大概和这个有关？有办法回复吗？🤦🏼♂️
看了一下 #Mastodon 的 CSS 们，倒不难修改，只是略繁琐。
如果要改，我会把输入框放去右下角，而且点击开始输入时要够大，不然即便字数限制好几万，它也不适合长篇书写啊；左栏整体缩窄，放点不常点击的内容……
但是显然我根本就是光说不练而已。
网页版抽奖小助手思路：
打开小助手页面，有输入框可以输入发起抽奖的实例地址；
点击授权，去该实例验证一下身份；
回来之后小助手页面出现抽奖设置选项，比如抽奖活动介绍，奖品是什么，参与的条件是什么（转发？回复？点星星？），中奖人个数，以及活动截止时间，可以附图；
确认后，由小助手自动发布抽奖嘟文。并从发布起，开始记录参与抽奖的嘟友 ID，到上一步设置的活动截止时间，自动发布一条嘟文宣布并艾特随机抽取的中奖者。
---
逻辑好像……十分简单，由小助手（以嘟友的身份）来发布抽奖嘟文，就可以实时记录所有参与者，不像用脚本在最后截止时去获取数据那样有漏掉参与者的风险。
不过为了一个并不常用的功能专门去跑个获取推送通知的服务……似乎有点浪费资源啊。
dimlau 的推荐：
