the challenge in "defining the protocol" for fedi is that
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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".
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
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.
-
thisismissem@hachyderm.ioreplied to trwnh@mastodon.social last edited by
@trwnh @hongminhee didn't we hit exactly this, but from GTS the other day?
-
hongminhee@fosstodon.orgreplied to thisismissem@hachyderm.io last edited by
@thisismissem Yes, the exactly same problem. I guess the earlier versions of GoToSocial had mimicked the earlier versions of Mastodon?
-
trwnh@mastodon.socialreplied to hongminhee@fosstodon.org last edited by
@hongminhee @thisismissem mastodon hasn't fixed the bug in question, btw -- the schema.org prefix is still incorrect
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
anyway here's what i could figure out for now https://gist.github.com/trwnh/d2f6fb1c87465baab8231427013a36a8
-
thisismissem@hachyderm.ioreplied to trwnh@mastodon.social last edited by
@trwnh @hongminhee iirc we just have http://schema.org as a context, instead of something named so it conflicts horribly with AS2
-
trwnh@mastodon.socialreplied to thisismissem@hachyderm.io last edited by
@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