@me the spec imagines servers to just be dumb inboxes, and as dumb inboxes they would presumably be easy to replace. But that's not how most people actually want their social media apps to behave, so it's not how they're built

@jenniferplusplus @me it's not entirely unreasonable to abstract away a "common core" that handles the delivery concerns at least. mastodon et al could be (and honestly functionally *are*) activitypub Clients. unfortunately, monolithic design. so we end up in a situation where everyone has to write their own mail server from scratch, on top of already having to write their own web browser from scratch.

@trwnh @jenniferplusplus @me thing is, ActivityPub makes it way too hard to abstract away the federation part. I'm purposefully not saying impossible, but the lack of clear separation between layers (here transport and application) makes it... Well, I tried, and I abandoned it. The fact that you can address whatever collection and anything can modify collections, the transport layer can't own them and syncing collections is horrible. At every turn, the spec is making that kind of thing hard.

@joelving @jenniferplusplus @me

> you can address whatever collection

bad idea imo

> At every turn, the spec is making that kind of thing hard.

the spec has a lot of problems but this isn't really one of them; the change basically amounts to "POST to outbox instead of POST to inbox"

actually the harder part is authorization, especially if you want granular scopes on which subsets of activities you can send. that's where i got stuck. the authors assumed very basic HTTP Authorization would do

@joelving @jenniferplusplus @me er, to clarify, the bad part of "addressing collections" is expecting servers to expand collections after the fact. expanding them beforehand is generally fine, because then receiving servers don't have to guess at their contents.

the problem with that is that it's inefficient because it breaks sharedinbox. the solution to *that* is multibox. unfortunately mastodon said sharedinbox was "good enough" because "you know who the followers are" (lol) (lol) (lol) (cry)

@joelving @jenniferplusplus @me *narrator voice* you do not in fact know who the followers are

the insistence on sharedinbox for followers-only posts actually introduced a hard dependency on state synchronization of followers collections, in such a way that you can't just silently remove a follower anymore, you have to let their server know Or Else Consequences

oh what's that, there's no standard way to remove followers? oh. oh no