有什么方便点的方法批量添加大于50k 的表情图吗?

V3.4 之后,图片文件最大尺寸变成 1920×1080 了。

感觉这对实例主来说实在是有些浪费。

毕竟,其实大部分图片,其实发布的时候也不是想着越高清越好,而只是懒得缩小尺寸而已,就保持原始状态发布了。

或许像一些即时通讯软件那样,由发布者选择是否上传「原图」更好些。

Emmm...

狠起来连自己都干掉了。

这好像是用 作为博客评论系统的缺陷弊端之一。

访问量太大的时候,会导致 API 访问受限。

说出「禁止转出长毛象」这种话的嘟友应该问一下自己:

互通的 在不在禁止之列? 在不在禁止之列?安装了联合插件的 Wordpress 在不在禁止之列?

要知道这些都不需要别人转,发布者只要公开发布了,这些「长毛象之外」的地方就有可能自动获得。

去年年初看到数据说全球排名前1000万的网站里有三分之一是用 Wordpress 建站的。

以及,支持 协议的网站在不在禁止之列?任何现有网站都可以加入该协议支持:

w3.org/TR/activitypub/

所以到底是在禁止什么?

----

其实倒也不必纠结,虽然任何有公开链接的内容都可以通过链接形式传播,把链接贴到微博、贴到微信都是很正当的操作,但是打上「禁止转出长毛象」标签的内容,往往也实在没有什么转载的价值。

虽然我效率很低,但是总算还是实现出来了——完整的一套流程:在博客文章页面展示相关嘟文的公开回应内容;匿名添加新的回应。

可以在这个页面查看演示效果:
kaix.in/0001/webmention/

在输入框右上角的箭头,下拉菜单里,可以查看被隐藏、屏蔽的人或站。

说实话我是不太明白为什么搞这么复杂,css、js 都搞模块化、框架之类的,乱七八糟,就连换个 logo 都要重新编译全部静态资源(因为 logo 用的 svg 是在编译过程写进页面模板里而不是用文件地址调用…)。

第一次动 的静态资源文件,先临时做了个 logo,费老鼻子劲了:

给大家表演个手冲 吧:

bilibili.com/video/BV1Qz4y1U7y

---

在妳想往 上传个视频的时候就能发现自建平台还是有其局限性的。

提供本地压缩好再上传的客户端也少,平台本身又有存储和带宽压力。

总之在微博、微信、知乎之类的地方可以轻松上传的视频,在 Mastodon 往往会提示妳「视频太大」。

这也太良心了,旧的 Matrix 实例,完全不必操心数据库的问题,直接用部署好的 Dendrite 连接旧数据库,就完成了迁移。

超期待 也来个 go 的实现版本啊。

显示全部对话

请教一下,sidekiq 信息里出现大量失败任务:

ActiveRecord::RecordNotFound: Couldn't find Account with 'id'=-99

是怎么回事……

我好像在 postgresql 里手动删了 id 为 -99 的帐号,大概和这个有关?有办法回复吗?🤦🏼‍♂️

看了一下 的 CSS 们,倒不难修改,只是略繁琐。

如果要改,我会把输入框放去右下角,而且点击开始输入时要够大,不然即便字数限制好几万,它也不适合长篇书写啊;左栏整体缩窄,放点不常点击的内容……

但是显然我根本就是光说不练而已。

网页版抽奖小助手思路:

打开小助手页面,有输入框可以输入发起抽奖的实例地址;

点击授权,去该实例验证一下身份;

回来之后小助手页面出现抽奖设置选项,比如抽奖活动介绍,奖品是什么,参与的条件是什么(转发?回复?点星星?),中奖人个数,以及活动截止时间,可以附图;

确认后,由小助手自动发布抽奖嘟文。并从发布起,开始记录参与抽奖的嘟友 ID,到上一步设置的活动截止时间,自动发布一条嘟文宣布并艾特随机抽取的中奖者。

---

逻辑好像……十分简单,由小助手(以嘟友的身份)来发布抽奖嘟文,就可以实时记录所有参与者,不像用脚本在最后截止时去获取数据那样有漏掉参与者的风险。

不过为了一个并不常用的功能专门去跑个获取推送通知的服务……似乎有点浪费资源啊。

有个想法:搞个小抽奖,就是从转发名单中随机抽一位送个小礼物之类的。

然后就想到另一个问题,这种转发抽奖的行为在 社区受欢迎还是排斥呢?

只是瞎想一下,所以也就不做投票了。

显示更早内容

dimlau 的推荐:

TzCafe

一个畅所欲言的网上咖啡馆,欢迎在这里交流,就像在现实中的咖啡馆里那样。