qt: bgme.me/@bgme/1075353120889963

试了一下,饼站长说的“通知记录也有总计400条的数目限制”也不对……notifications API 每页 15 条,也是可以翻页,而且没有任何限制,我拿我自己做实验,获取到了 7000+ 通知,直到我刚刚来象的第一条通知都能获取到.

饼站长给出的代码(github.com/mastodon/mastodon/b )里的 400 应该是别的什么东西.

这么看来,长毛象并不是不适合抽奖,抽奖在技术上不会有任何问题. 我是不是应该去读读饼站长的抽奖脚本的代码,看看 ta 是怎么写的(?

关注

读完了,抽奖脚本没毛病,并不会对任何人不公平,所有转发者都能获取到,任何人抽奖都可以放心用那个脚本!

我实在是不太明白 ta 为啥前几天突然发那条说长毛象不适合抽奖的嘟,还用了错误的论据来论述,看脚本感觉 ta 也不像是不懂的人啊😯

脚本唯一可以改进的地方是:那个脚本获取了被转发数,当目前获取到的转发者数量不等于被转发数时,就翻页翻到下一页继续获取,直到翻完了所有的通知,nlist.lenth 等于 0 了,才直接 end loop.

实际上,据我观察,从通知里获取到的转发者总数可能是会小于嘟文记录的被转发数的,我猜测原因有二:
1. 有些非长毛象账号的转发会被计数但不会被通知,比如 ovo.st 小组的转发;
2. 可能有些人删号注销后和 ta 有关的通知就都被删掉了,但被转发数没有更新(我猜的,不确定)

所以那个脚本的一个改进思路是:获取嘟文的发嘟时间,循环获取通知时,检测每一页第一条通知的 created_at,如果早于发嘟时间,直接 break.

登录以加入对话
万象千言

本站话题休闲取向,欢迎使用。以下类型用户请勿注册:激进民运人士、左翼爱国者、网络评论员。

访客查看账户公共页面 (1234.as/@username) 仅显示 10 条最新嘟文,如果需要查看更多,请关注或登录。