this pixelfed bug really feels like a design problem at the protocol level to me; it requires way too much unearned trust to expect a network of programs that are highly decoupled and barely trust each other to enforce one another's access controls, especially on the level of individual posts
Conversation
Notices
-
Embed this notice
jcoglan (jcoglan@mastodon.social)'s status on Thursday, 27-Mar-2025 00:06:32 JST jcoglan
- Cassandra Lemmer-Webber repeated this.
-
Embed this notice
Tobbsn (tobbsn@post.lurk.org)'s status on Thursday, 27-Mar-2025 00:06:32 JST Tobbsn
@jcoglan It is. If I understand the current problem correctly, it stems from instances having shared inboxes, which are implemented wrong in PixelFed. Which underscores your point: This shouldn't be a question of implementation...
If one hundred people on one instance follow a person, if that person posts something, it doesn't get delivered to the instance one hundred times, but only once to a shared inbox - and the instance then delivers it to the individual users' inboxes. I have a vague memory of an older podcast by @cwebber where she talked about this, describing them as one of her bigger regrets in an otherwise mostly good protocol. The decision to make them part of the protocol was made when the social web working group ran out of time. Mastodon was already by far the biggest implementation of the activityPub standard back then and pushed heavily for such shared inboxes, since they would use far less computing resources. But they kinda break the actor model of activityPub and create problems like the one PixeFed is facing now.
-
Embed this notice
Cassandra Lemmer-Webber (cwebber@social.coop)'s status on Thursday, 27-Mar-2025 00:07:08 JST Cassandra Lemmer-Webber
@tobbsn @jcoglan yup you got it
I hate the sharedInbox compromise that happened at last moment and I had a very different proposal that I still think would have been better and would have preserved actor semantics