Egregoros

@icedquinn @coolbean @vic
>afaik the big crime with that is that people are parsing the json as-is and the ld tags are just for show. which means its basically not ld, since namespace resolution isn't being done,

JSON-LD in ActivityPub is entirely optional and always was. You are supposed to be able to use it as plain JSON. If it was forced, most of the implementations would not exist these days, because parsers for JSON-LD barely exist. Those that try to make their own (Friendica and Iceshrimp notably) have constant issues with it especially in performance and when new contexts get added as extensions. It's a shitshow that only the LD fetishists in the WGs support, of which there are few.

This also creates subtle issues with representations for both LD and non-LD consumers. Completely valid ActivityPub documents may look different to LD consumers compared to pure JSON consumers.

What the AP writers did was, replace XML which was much better at this completely unnecessary linked data thing, with something that is far worse at it and almost impossible to implement properly. Honestly, JSON-LD in ActivityPub should just die, there's exactly zero need for it.

@phnt @icedquinn @coolbean @vic

> fully compliant JSON-LD parsers for Python, Ruby, JavaScript and Elixir minimally,

https://json-ld.org/#developers lists all of those and more...

python: https://github.com/RDFLib/rdflib
ruby: https://github.com/ruby-rdf/json-ld/
javascript: https://github.com/digitalbazaar/jsonld.js
elixir: https://github.com/rdf-elixir/jsonld-ex

python and javascript probably have the best library support for this, with java and rust and c# not too far behind. php is lagging behind, though.

> there's exactly zero need for it

there's zero need for it *if you exclusively use only properties defined in activitystreams, exactly as https://www.w3.org/ns/activitystreams.jsonld describes them*. anything not defined there is ambiguous. there are 3 ways to make it unambiguous:

- use a jsonld processor to expand shorthand terms to full identifiers
- use pre-expanded full identifiers
- use a central registry that everyone agrees to use IANA-style, bound to some media type or profile (like how application/activity+json specifies the meaning of terms)

@icedquinn has it correct. mastodon uses properties like "featured" and "discoverable" which by default have no meaning whatsoever in AS2. you can't assume these terms are always being used the same way mastodon uses them. "featured" might be a boolean indicating that the current object should be promoted, instead of a reference to a collection of pinned posts. "discoverable" might imply different things depending on if you follow mastodon's interpretation or not (say for public timelines instead of for profile directories or search results).

the bigger problem is that even the official AS2 terms are being used in ways not according to their definition by mastodon, and other softwares also have different overloading of the terms. "to" being expected to always be an array or not, "attachment" being expected to be ordered when it isn't, etc etc etc etc... there's dozens of papercuts in how the same terms get used differently by different softwares, which should flat-out never happen ideally, but unfortunately linguistics is what it is.

even bigger than that: the vocabulary is only a foundation for describing activities, which don't have consistently agreed-upon behaviors, constraints, or expectations. this is assuming the softwares care about activities at all and aren't just fetching notes or articles from origin. and even *that* assumes they care about the notes and articles and aren't just transforming it into some bespoke internal representation which isn't shared by any other software.

honestly for fedi purposes it is mostly a mistake to try and standardize on one vocabulary and format because all it does is encourage people to bend and twist and break the standard to fit their own purposes, when what they really ought to be doing is developing their own controlled vocabularies to describe what they're *actually* doing -- and map equivalences between that and some eventual standard (that comes from surveying the landscape after it's less experimental). so for example, mastodon should be calling them Accounts and Statuses, namespaced within their own namespace, mirroring their codebase's models in app/models/status.rb and so on. this doesn't preclude them from *also* describing their entities with other vocabularies -- the same thing could be a mastodon:Status, as:Article, sioc:Post, you name it, if it fits it fits. treat it a lot more like an API than letting mastodon hollow out AS2 and use it as a rubberstamp for legitimacy.