Long post whining about ActivityPub
I've talked about this a bunch in the past, but thinking about "fediverse improvements" always beings me back to when I learned what ActivityPub actually does and what its design goals were.
The number one goal sure seems like it was "very nearly real-time status updates, like Twitter has, but distributed."
Because that's what they wanted the protocol to do, it required doing things in a fundamentally inefficient way. Every single post you make results in an inherently uncacheable request sent to at minimum the number of instances your followers use, and in some cases, one for every follower on that instance.
The overhead of creating and cryptographically signing unique payloads to send to several thousand different instances in rapid succession, for every post everyone ever makes, is kind of bonkers for a lot of different reasons.
But that the mechanism includes an API request for an "outbox" that lists all the content that remote instances could fetch — but never do — is something I find completely offensive.
Then, anytime anyone brings this up, there's pushback saying doing that would defeat the entire purpose of ActivityPub, because the entire purpose of ActivityPub is realtime messaging.
If you start the conversation saying that the only way a post can end up in a follower's feed is if there's a unique event transfered in about the most network-inefficient way possible, it paints the picture that your concern isn't really about transferring peoples' posts to each other, but to do it with as little delay between clicking send and it appearing in a feed, no matter the consequences.
But here's the thing: because there's so goddamned many requests being sent to so goddamned many places, it's all handled with queues. There's constantly a big backlog of posts still waiting to be sent. If I have 50,000 followers, spread out evenly over the whole fediverse, that's still 10s of thousands of entries in the queue that are causing your new post to have to wait as well.
None of this is frickin' realtime!
In a lot of cases, each instance also has a queue full of incoming requests that need to be processed, which adds further overhead and delay.
The amount of work that needs to be done for every single post in "real time" via ActivityPub is pretty staggering.
@nyquildotorg ever since I first started reading the AP standard documents I had similar hair raising reactions.
This seems to be a system designed by people who have never heard of big O analysis, people more interested in cobbling together off the shelf components rather than thinking about how the whole system would work if it were to scale.
I'm incredibly critical of the engineering behind AP and you're really capturing my attitude.
