the challenge in "defining the protocol" for fedi is that

- ap is not a protocol
- mastodon is a protocol, but doesn't want to be one

so if you define a protocol and show it to the w3c people, they won't want it. and if you define the "mastodon protocol" then even mastodon itself won't want to signal it.

not to mention that doing so at this stage would only serve to codify bad practices as canon...

really i think the issue goes as deep as as2-core. the as2-vocab is mostly fine, but that's it

i've talked before about as2 as a media type and its inherent issues, like how it's not really json and not really jsonld; the normative context document is not "correct" to say the least, and fixing the context document would make a lot of existing as2 documents no longer compliant with as2. there's a divergence between "what the context says" and "what the producer intended" in most cases. things like `attachment` being unordered in the context, but intended to be ordered by most producers.

the way you normalize the data into the correct semantics is to basically swap out the as2 context for the "fixed" one, whenever you detect that the producer is using those divergent semantics. but the challenge there is exactly that -- how do you detect this? you end up having to guess, based on some other proxy info like whatever you might find in nodeinfo. this is useragent parsing hell

if we were to entertain the "mastodon protocol" thought experiment then we could define a new media type or profile (application/mastodon+json? application/activity+json with a profile of joinmastodon.org/ns?) and then make two statements:

1) the "mastodon protocol" serialization format is not jsonld; it requires certain properties to be compacted into specific shorthand terms.

2) the "mastodon protocol" serialization format can be converted to jsonld with a "corrected" context document.

the problem you run into though, is that some implementations do just enough jsonld for it to be dangerous. how do you fix something like the "schema.org#" prefix being used for profile fields? you might think "oh that's easy, just change to the correct one", but this could actually break profile field parsing, because older versions of mastodon depend on the *incorrect* uri!

Properly resolve schema.org @context by trwnh · Pull Request #18354 · mastodon/mastodon

Fix #18361 If not importing the entire https://schema.org context, then the few cherry-picked definitions will not resolve correctly. The proper IRI is of the form http://schema.org/propertyName, s...

GitHub (github.com)

so you either need to break compat by doing the "correct" thing, or you formalize the "wrong".

so basically any attempt at formalizing a "protocol" will immediately run headfirst into the realities of every single bug, quirk, hack, etc.

at the very least, we can take the idea of "preprocess or normalize the data by swapping out contexts" and do it *twice*: once from as2 to mastodon, and once from mastodon to "correct" jsonld. this leaves as2 context and mastodon context as both "wrong", semantically speaking, but more accurate to the reality of what's being done by impls.

@trwnh @hongminhee didn't we hit exactly this, but from GTS the other day?

@thisismissem Yes, the exactly same problem. I guess the earlier versions of GoToSocial had mimicked the earlier versions of Mastodon?

@hongminhee @thisismissem mastodon hasn't fixed the bug in question, btw -- the schema.org prefix is still incorrect

anyway here's what i could figure out for now https://gist.github.com/trwnh/d2f6fb1c87465baab8231427013a36a8

@trwnh @hongminhee iirc we just have http://schema.org as a context, instead of something named so it conflicts horribly with AS2

@thisismissem @hongminhee context declaration are ordered and scoped so you need to be careful not to override the as2 terms at any point, otherwise you get stuff like schema:name instead of as:name.

also mastodon does something bonkers, the PropertyValue uses as:name instead of schema:name, even after you account for the incorrect prefix/expansion