@bortzmeyer It's both bad and good. Lack of directions for transport and authentication layers means ActivityPub could be used over udp or websockets. Of course that's little use to us, since those layers being incompatible would cut us off.

@bortzmeyer That's us!

@bortzmeyer @Gargron mastodon hasn't complied to the spec in the past

@saxnot @bortzmeyer That's a lieeeee

@bortzmeyer @saxnot That, and the fact I literally was part of the AP design sessions, why would I violate the spec with my implementation if my implementation literally shaped the spec. The lie originates from the OStatus days, and even then it wasn't true, GNU social wasn't 100% compliant with the written specs and I refused to repeat those mistakes.

@bortzmeyer @Gargron oh this was my gut feeling but now it's official ?

@bortzmeyer @Gargron I proposed and volunteered to write Mastodon Client Conventions but it looks like we also need Mastodon ActivityPub profile

@bortzmeyer @saper ActivitySuite

@bortzmeyer I mean, you're kinda right because Mastodon predates ActivityPub and became popular before that. But why is it a failure? We have Mastodon, Misskey, Pleroma and PeerTube talking to each other using ActivityPub, Webfinger and HTTP Signatures. They may not all be written down in the ActivityPub spec because it's "up to the implementers" but they're all real standards!

@bortzmeyer ActivityPub is the language, and to use the language we need a transport layer. The designers of ActivityPub wanted that separation because it would not be possible to push the standard through W3C otherwise. What you're looking for is some kind of ActivityPubSuite standard.