do not use yaml. do not support the propagation of yaml. say no to 300 page specs for fucking plain text storage god damnRE: https://w3c.social/@w3c/116216070362563670
Timeline
Post
Remote status
Context
4 do not use yaml. do not support the propagation of yaml. say no to 300 page specs for fucking plain text storage god damnRE: https://w3c.social/@w3c/116216070362563670
We need to shut down all working groups until we can figure out what's going on.
@vic i had an anneurism seeing this. the spec for json is like 1 page.
if you must go whitespace then consider nestedtext. it doesn't have embarassing issues like the norway problem.
if you must go whitespace then consider nestedtext. it doesn't have embarassing issues like the norway problem.
@icedquinn @vic AND json5 already exists to fill this exact niche while also having other neat upsides (backwards compatibility with regular json data and using perfectly valid ecmascript syntax)
@icedquinn @vic i mean fuck its the json-ld working group i shouldve expected this they're the reason activitypub is impossible to implement right
Replies
19
@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, which is also basically what happened to xmlns.
there is more spec than i like to json-ld but its also basically working around json's lack of metadata and trying to tape namespacing on in a couple ways, so.
if it were up to me we would just store the triplets and maybe a prefix reference.
there is more spec than i like to json-ld but its also basically working around json's lack of metadata and trying to tape namespacing on in a couple ways, so.
if it were up to me we would just store the triplets and maybe a prefix reference.
@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.
>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.
@coolbean @phnt @vic the problem with XML is that it makes sense within the SGML lineage which is not how most people experienced it.
SGML was this massive gigaspec where the culture developed a self awareness that you kind of cherry pick which parts fit your budget. it had a lot of human aids to make ex. writing recipes easier. but because it was a gigaspec, and not everyone implements all of it, they decided what if we removed a lot of the customization and just made a dialect with a lot of fixed decisions that people could implement as an exchange format.
that format is XML.
the correct use of XML per greybeards is in the middle of conversion tools. like i posted last year, its like this:
- my cool key checking daemon only supports a single hardened XML parser for configs
- some domain specific language gets used to actually configure it or a GUI
- a translator turns the cool human version in to the XML document, after processing out all of the aids in to a single verbose document that is plainly (if tediously) understood
Sun didn't follow instructions and everyone else met XML through Sun. Thus begins the generational trauma to reinvent XML-but-Worse (JSON) or XML-but-cute (KDL)
SGML was this massive gigaspec where the culture developed a self awareness that you kind of cherry pick which parts fit your budget. it had a lot of human aids to make ex. writing recipes easier. but because it was a gigaspec, and not everyone implements all of it, they decided what if we removed a lot of the customization and just made a dialect with a lot of fixed decisions that people could implement as an exchange format.
that format is XML.
the correct use of XML per greybeards is in the middle of conversion tools. like i posted last year, its like this:
- my cool key checking daemon only supports a single hardened XML parser for configs
- some domain specific language gets used to actually configure it or a GUI
- a translator turns the cool human version in to the XML document, after processing out all of the aids in to a single verbose document that is plainly (if tediously) understood
Sun didn't follow instructions and everyone else met XML through Sun. Thus begins the generational trauma to reinvent XML-but-Worse (JSON) or XML-but-cute (KDL)
@icedquinn @coolbean @vic Unless someone can give me fully compliant JSON-LD parsers for Python, Ruby, JavaScript and Elixir minimally, I consider the format as a dead format that should never be used in the ActivityPub context.
@phnt @icedquinn @coolbean @vic you know what else would be great:
a floss triple store that supports json-ld and is generically queryable (and DOES NOT SUCK)
a floss triple store that supports json-ld and is generically queryable (and DOES NOT SUCK)
@sun @icedquinn @coolbean @vic Brb, making another PostgreSQL extension. This one will be it, I promise.
@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.
> 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.
@a @icedquinn @coolbean @phnt @vic I was building a system in elixir and the json-ld lib there isn't sufficient for various reasons.
@sun @icedquinn @coolbean @a @vic At least you can use it on top of Jason. I expected some complete abomination. Still would be interesting to look at how those listed were fully compliant or even usable at the time AP was finalized.
@phnt @icedquinn @vic there we go, someone thats felt the pain
may i ask you how do you feel about websub and using it to enable like minimal federation on a more self-hosted level
may i ask you how do you feel about websub and using it to enable like minimal federation on a more self-hosted level
@phnt @icedquinn @vic cause in my brain i always go "websub would fix this" but im actually fucking clueless on this topic i dont know what im doing
@icedquinn @coolbean @vic activitypub is impossible to implement because it's incomplete and everything you need to complete it is out of scope (authentication/authorization, trust model, etc etc)
fedi is a nightmare to interop with because everyone filled in the gaps differently and even worse they use the little that *was* specced in ambiguous and nonspecific ways instead of defining their own terms or using the terms as officially defined (and then the behaviors are basically totally undefined)
json-ld group is doing yaml-ld because believe it or not, some people actually asked for it and intend to implement it (as well as cbor-ld) so they have an actual mandate for doing this and didn't just decide to do it on their own
fedi is a nightmare to interop with because everyone filled in the gaps differently and even worse they use the little that *was* specced in ambiguous and nonspecific ways instead of defining their own terms or using the terms as officially defined (and then the behaviors are basically totally undefined)
json-ld group is doing yaml-ld because believe it or not, some people actually asked for it and intend to implement it (as well as cbor-ld) so they have an actual mandate for doing this and didn't just decide to do it on their own