Hrefna (DHC)
The gist of what I am going for with #JsonLD:
What is a minimal subset that would allow us to treat the @'context object as a _set of extensions_ rather than a _set of processing directives_ while still remaining useful?
Basically, you could have a "mastodon postprocessor" with all of the logic there.
I have a bunch of thoughts and have validated some, but I'm interested in the experience of those who have banged their head against this problem. Any ideas? Does that make sense as a goal?
Hrefna (DHC)
The two people you are talking to are intimately familiar with web protocols, how they work, and how to build and work with these systems in the real world
AP punts significant things to JSON-LD, ergo, if you want to be compliant with anything using those things you need JSON-LD. The "it's just JSON" line is almost pure marketing
Also we're discussing how these systems get used in practice. For instance, how to parse what is returned by https://xoxo.zone/users/KevinMarks
Kevin Marks
@jenniferplusplus @hrefna No it isn't. It's built on JSON, with a sprinkling of LD cruft to placate the LD fans. You do not need to process JSON-LD or any other kind of RDF to use AS2 and AP, indeed this is explicitly stated in the spec, and you can leave the @context out if you want.
https://www.w3.org/TR/activitystreams-core/#syntaxconventions
Jenniferplusplus
@KevinMarks the problem is that activitypub is built on top of json-ld. So the options are to deal with that, or convince the entire fediverse to switch to something else. @hrefna
Kevin Marks
@jenniferplusplus @hrefna if you want a usable translator between different formats, Granary is the most complete https://granary.io/ - as used in https://brid.gy
Empirically, the JSON-LD model is not suited to actual interoperability, in that it has been more than 25 years and everyone who tries has vanished into further abstraction as far as I can see.
Jenniferplusplus
@hrefna
It's handy that several of these AP-but-performant protocols have been tried and failed already. Knowing that path is a dead end is saving me a lot of time and grief
@KevinMarks
Hrefna (DHC)
Yep, that project fits in a different niche than what I'm looking at: it's a different syntax entirely. A replacement for JSON-LD rather than something that interoperates with it as it is used in practice.
Another example is the largely defunct #LitePub: https://litepub.social It was an attempt to clean up and simplify some the semantics around #ActivityPub and provide a little more of a server specification along with it, but it doesn't use AS2 vocab.
Kevin Marks
@jenniferplusplus @hrefna Paul Frazee (of BlueSky fame) came up with an alternative proposal designed for this use case as JSON-LZ a while back https://github.com/pfrazee/json-lz
Jenniferplusplus
@hrefna I suspect that it's not possible in real usage. Maybe if every vocabulary was spectacularly well made, but they're not. The AS vocabulary doc is basically useless. It does nothing more than list the terms, without so much as defining or relating them to anything. And that's before we get to vocabularies that don't even exist. Mastodon's being a notable example.
Hrefna (DHC)
@jenniferplusplus I have tried six different ways (not actually, more like 3) to get some form of code generation or metatemplate or something to work because it looks vaguely viable but every single time it runs into the exact problem that you are describing (along with that contexts themselves are a nightmare to process -.-)
I basically concluded that if I'm going to go down that road I need a grant sufficient to quit my job, if it is even possible to do in the first place.
Jenniferplusplus
@hrefna I think that's generally the right idea. In an ideal world, an ld context would facilitate code generation. But for all of its links, it doesn't actually describe anything with enough to structure for that to be possible, even in the most naive case.
For myself, I'm thinking of it as being advisory, at best. If I could query the @context to check for active extensions, that would be by far the most help it's ever been.
smallcircles (Humanity Now 🕊)
@hrefna @KevinMarks @jenniferplusplus
I proposed on #SocialHub that going forward we (W3C #SocialCG) *might* consider #ActivityPub to be a JSON-first spec, instead of #LinkedData-first. It should be a change of 'stance' and need not break backwards-compat (it likely won't or be low-impact as there aren't many LD impls).
This different approach would entail that JSON-first devs get a sane extension mechanism, and that independent of that LD devs can go the extra mile.
Hrefna (DHC)
Now, I recognize you were around for those parts of it through about Aug 2016, but there seems to be a fundamental disconnect here between /what the spec says/ and /what is being done in reality/.
Between _what guides are telling me I can do_ and _what I need to do in order to effectively interoperate with what is out there_.
I only barely care about the former, I _do_ care about the latter, and what we have now is a weird mishmash that just confuses everyone
Hrefna (DHC)
Here, I'll help.
This is the context object for my account:
https://gist.github.com/dclements/cbb5b19e148a913392af26213a8e5495
Now, you can tell me "but you can omit the context object under the spec" all you like, but _because things other than ActivityPub are being used, other specs also apply_.
I can also point to parts of the minutes for the discussion in building AP in the first place where entire features were punted to JSON-LD such that you need to use JSON-LD for, e.g., _language support_.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.