Post #2346324

2026-05-05 08:19 UTC

@uriel@x.keinpfusch.net > I am now developing my own software for AP instances > Who designed this "standard" A number of people, but @evan@cosocial.ca and @cwebber@social.coop were 2 of them. > The process of getting it interoperable with pleroma, mastodon, and then GtS. is driving me crazy The details are a bit beyond my wheelhouse, but my understanding is that a certain amount of this is caused by major AP projects not actually following the standard. Notably @Mastodon@mastodon.social not implementing the AP client-to-server standard at all.

Replies (1)

@uriel@x.keinpfusch.net 2026-05-05 09:42

@strypey@mastodon.nzoss.nz @evan@cosocial.ca @cwebber@social.coop @Mastodon@mastodon.social I get it. But here's the crux: my perspective may carry some bias from the telco world—think SS7 signaling, MAP, CAP, TCAP, all meticulously defined down to the bit level. In that realm, I never had to wonder if the other side truly adhered to ITU-T standards. If they declare "G.711," that's it—done deal. The same holds for G.722 or G.729 when voice codecs are in play. Contrast this with ActivityPub, where I've implemented the W3C spec faithfully, only for everything to crumble due to some undocumented "variant," or disputes over key propagation. None of this should happen if the presentation layer is rigorously specified. That said, if voice calls à la WhatsApp are on your radar, Article 7 of the DMA is worth a look. Even beyond pure telco, SIP uses SDP to negotiate sessions and codecs dynamically, ensuring smooth interoperability. Yet no one second-guesses the codecs themselves: Opus (RFC 6716, the IETF standard for WebRTC) is crystal clear, with G.711 and G.722 as fallback anchors for legacy compatibility. Nobody dares claim, "Sorry, this is my version" (well, Cisco and Microsoft have a storied history of such mischief, but they're the IT rogues—not role models). Here in the ActivityPub ecosystem, though, "my own take on the standard" is rampant—and the spec simply isn't precise enough to prevent it.

Open ##2346325