长毛象由于其Fediverse的设计,嘟文的"赞"和"转嘟"数字往往是不准的(这些数字不在时间轴上显示)。原因是长毛象并不会广播一个用户的“点赞”操作,对于“转嘟”而言也仅限于转嘟用户的关注者。

具体来说,实例A的用户点赞了实例B上的一条嘟文。这个信息只有A和B知道,别的实例点赞数并不会+1。

对于转嘟,这个信息除了A和B,还有所有A的关注着所在的实例知道。如果一个第三方实例C没有任何用户关注了A上进行操作的用户,那么嘟文在C的转嘟数就不会+1。

值得一提的是这些数字决定了“探索”页面的内容。如果你的实例的“探索”页面经常空空如也,就是因为这个原因。

这个设计据说是“有意为之”,为了体现其Fedi的特性,而且似乎UI也淡化了这两个数字(时间轴不显示)。从这个角度说确实挺有趣。

不过反过来说,这可能会给用户带来困扰。尤其是对于一个小实例,因为用户少,实例本身的操作就少,而且大概率收不到别的实例的通知,因此数字就会非常小。如果是私人实例,那这个功能就完全无用了。这会导致用户更倾向大实例从而获得更完整的体验,这与Fedi的精神背道而驰。

不过既然程序如此设计,我们也只能做到了解这些细节。如果想看某嘟文最准确的数字,只能点击嘟文的原始实例链接。

https://github.com/mastodon/mastodon/discussions/22627

#站点说明
#长毛象中文使用指南

Boosts and Favourites counts · mastodon mastodon · Discussion #22627

Can someone clarify how exactly boosts and favourites are counted and federated across Mastodon instances? I'm running a 35k+ users instance and do get questions related to these counts regularly. ...

GitHub

仔细想了想,长毛象或多或少是鼓励tribalism的。或者叫搞小圈子。

看英文实例,很多都是有一个特别的主题或者context。吸引兴趣话题接近的人在一起,从而达到——联邦宇宙互联互通,我们的小圈圈更加互通。

很多App都支持同时登录好几个实例,应该也反应了英文用户喜欢注册多个实例账号,在切换实例的时候切换嘟嘟的主题。

但是在中文毛象圈里绝大部分的实例都是不限主题的,顶多就是UI和Mod哲学的细微区别。我想本质上是因为“使用中文”本身就是一个小圈子,而且活跃人数也实在是不多,一旦进一步细分就显得更加冷清,

此外还有个大国特色:对身份安全(也就是账号的匿名性)的担忧和GFW也影响着中文毛象的生态:类似“马斯洛需求层次理论”,当话随便说、站随便上的环境都不能保证时,潜意识的想法就是“有个能安全说话的地方就不错了”,而不会去更进一步的追求“去不同的地方专门聊不同的话题”。没这个心情。

看来中文毛象确实是一个独特而脆弱的生态,值得中文实例们自己好好建设和维护。

#长毛象中文使用指南
#长毛象站长联谊会

所以,我还是希望中文用户都搬到中文实例来。让我们这个小圈子人气旺一点。

如果对于隐私有担忧,可以选择网站和站长都和中国没关系的实例。这样其实和那些英文实例没什么区别。可以参考: https://c7.io/@snullp/113479774456693980

大松鼠 (@snullp@c7.io)

@board@ovo.st 由[1]的启发,说说普通简中用户使用墙外社交网络(包括但不限于长毛象),不同等级的身份安全(匿名性)需要注意的事: 0.不被网友简单人肉:不要使用别的平台相同的ID,不要主动暴露个人信息。了解服务的运营方能看到你与服务的所有交互。 1.不被大数据识别:不要使用大陆手机号、大陆公司的邮箱注册服务。不要使用大陆备案的、服务器处于大陆的服务。不要使用已知会主动记录使用行为的国产手机和软件(e.g. 华为、搜狗输入法)。 2.发表个别敏感言论:不要使用运营人员身处大陆、香港的服务。不要使用运行在大陆、香港的云服务提供方(e.g. 阿里云)在任何地理位置之上的服务。确保服务平台没有已知安全漏洞(运营方活跃,及时更新)。 3.被盯上时不会发现真身:确保服务平台的运营方有足够实力不被收买。确保服务平台的软件有活跃的生态和漏洞反馈机制(反例是Firefish)。确保服务平台的硬件基于大型公有云或由运营方直接拥有(而非租赁)。不要使用人数过少的服务。不要每天都在固定时间地点发消息。不要点击只有你能看到地方(e.g.私信)里的站外链接。 4.超级敏感,世界上任何政府都不能发现:不要使用长毛象等不支持“端到端加密”的服务。(其实我也不知道应该怎么做。) 对于长毛象来说,一般站点都会在关于页面描述运营方面的详情,譬如我的实例 https://c7.io/about [1]: https://c7.io/@snullp/113474035477050432 #长毛象中文使用指南

希奇!
似乎长毛象 v4.4.0更改了这个设定。至少点赞数可以(部分?)同步了。

@snullp
https://github.com/mastodon/mastodon/pull/32007

v4.3.0+ 已经会将点赞转发回复的数量放到 ap 对象里了,例如:
curl 'https://c7.io/@snullp/113440108715329517' -H 'Accept: application/activity+json' | jq
其它站点理论上就能直接获取到最新的状态,不过感觉出于资源考虑也不太可能不停去更新源帖。
估计小实例的要好起来只能等 https://www.fediscovery.org/ 的落地了。

Add reblogs and favourites counts to statuses in ActivityPub by Gargron · Pull Request #32007 · mastodon/mastodon

This adds the likes and shares attributes to the Note object, inlining a Collection with totalItems. Also adds separately resolvable routes for these two collections, but without yet exposing the i...

GitHub
@SouthFox @snullp 这个固然是好的,然而这个数据真的可信吗?如果要把外站federate进来的数据作为本站trend的考虑因素,恶意实例只要把赞转评数量改到很高就能占领所有与之联合的所有实例的热门页面了
@icarus @snullp
所以设计上 mastodon 进入探索的帐号或者实例是需要管理员手动核准的,只是很多管理员觉得麻烦都改成自动放行了(
@SouthFox @icarus @snullp 这个其实还好,即使后端程序数据不造假也可以注册一批账号人工刷数据的。有异常实例或者账号再补拉黑也是可以接受的。
@laozhoubuluo @SouthFox @icarus @snullp
看到有人发的相关讨论
https://w.on-t.work/activitypub/replies-collection
文中提到的正在review的pr
https://github.com/mastodon/mastodon/pull/32615 感觉象很快能实现这个了
make your fedi software small instance friendly with this 1 shocking trick

@Kuria 啊!太好了,这个正是我想要的
@Kuria 不过这个要是也从安全性的角度来考虑,恶意实例可以在reply集合中伪造多条特定实例的status url,来引导其它实例对目标实力事实上发起攻击。我看pr一直在讨论infinite loop的情况,不知道这个有没有被讨论到
@icarus @Kuria 只要没有死循环的话,辅以一定的缓存机制、请求延迟机制应该还是撑得住,哪怕几分钟之内单个接口几百上千次请求量对现代后端来说也是扛得住的。
@SouthFox 嗯,不过这方面的逻辑只要以后一有改动肯定又有是否符合“Fedi原教旨”的争论。
@snullp 那是mastodon自己的问题,你不用mastodon就不会有这个问题。别的ap实现就不会这样啊。