There’s been a definite tinge of ideology or at least gatekeeping to some of these responses, but that’s to be expected. FOSS has always had a streak of it.

It’s a bit ironic to use ActivityPub to say ActivityPub has no real applications, though.

Happy cake day!

Leaving aside all the work they did making an alternative more to their liking, that kind of implies it’s like a light switch, and it’s not.

Oh? Complicated, fragile, something else?

Yep. What do you think the chances are you could write something that does the job of the router and app view, but in a totally off-standard, more point-to-point way?

In the meanwhile, it’s just a matter of bridging, I guess.

It’s a good blog post, thanks. I made a quick summery elsewhere in the thread.

It’s really unfortunate that we’ve ended up with two populated protocols for federation, both of which have a major flaw. In our case, it’s no established support for moving accounts. In theirs, its a component that’s so bulky the federatability is questionable (and no federated DMs).

Thank you!

TL;DR, the relay bit works as a completely connected network topology, and has the associated quadratic growth issues, which renders it, like you said, hard to host.

Also nasty: Direct messages are just not federated.

Other things are or were at the time of writing janky, but nothing else is quite that egregious. The author is working on a separate project, and recommends this idea as a solution for portable identity on ActivityPub; here’s what “object capability” means in the context.

Bets all in? Okay:

Really? In what way?

Digital identities being cryptographic and independent of any one instance is huge all on it’s own. The rest of it I understand less clearly, but it looks pretty modular.