长毛象为何不适合转发抽奖
长毛象上的转发抽奖好像多了起来,但是由于长毛象的设计,长毛象并不适合转发抽奖。
转发抽奖第一步也是最基础的一步,获取抽奖嘟文所有转发名单。
但就是这第一步,便存在问题。
/api/v1/statuses/:id/reblogged_by API 最多只能读取40名转发者。
我之前写的转发抽奖脚本,为了绕开该限制,改由通知记录获取转发者信息,但是通知记录也有总计400条的数目限制。
计算上抽奖嘟文星星通知,通过通知记录,仅可供200人以下可靠参与转发抽奖。
因此各位嘟友参加转发抽转活动之前,敬请三思。
@bgme 您好!最多 40 名转发者只是一页 40 名,还可以翻页呀!在消息头有一个 link 字段,里面有下一页所需要的 max_id 和上一页所需要的 since_id. 我写了一个简单的 python 程序:
https://gist.github.com/zero-mstd/f2725ae29f8c21939e8d3a1f328934d9
@zero
刚刚试验了一下,没有什么用,从 reblogged_by API 确实是无法获取全量转发信息的。
@bgme 啊?有啥错误提示吗?我成功用这个脚本获取了我的一条嘟文 200+ 的转发者.
@zero
准确的来说是一些转发者并不会出现在 reblogged_by API 上。
以上方的母嘟文为例,当前转发计数是 42。但是通过 reblogged_by API 你只能获取28个转发者。
再比如说:https://bgme.me/@bgme/106874443906503464
这条嘟文显示共有168个转发,但通过 reblogged_by API 只获取了129名转发者。
@zero
你可以多试几条嘟文,据我观察 reblogged_by 列出的转发者,与转发计数大多数情况下是不一致的。
@bgme 这个现象我还真遇到过很多次哎!通知里显示了某用户的转发,但是点进去就发现没有统计进去,我还以为这是我站的 bug,看来是所有实例都有?这是什么原因造成的呢?与安全模式有关吗?
这样说的话还是用通知更靠谱一些?但您原嘟说的通知 400 条的数目限制是否也能突破?我印象中玻璃翼站长搞的那个“时间线守护者”貌似能备份到所有的通知信息,当时我才刚来长毛象,不确定我那时的通知总数是否超过了 400.
说起来还有相反的一种可能,就是在 reblogged_by 里有转发的用户却没有在通知里显示,比如 ovo.st 小组的转发、中继机器人的转发.
---
我最开始的回复只是针对您说的“API 最多只能读取40名转发者”而已,而且还看到您和另一位用户讨论到对先转发的人不公平.