silverpill
>There's no going back.
We absolutely must go back. Either we have a vibrant ecosystem where building stuff is a pleasant experience, or fediverse slowly dies while linked data cultists harass developers about nonresolvable URLs in @context.
JSON-LD adds nothing to ActivityPub, it only creates problems. Time to move on.
silverpill
@lutindiscret @hongminhee I have no idea, it is literally useless. JSON-LD is a form of gatekeeping.
Lutin Discret
@silverpill @hongminhee can someone explain what was it supposed to bring?
It sounds like people are attached to xml with schemas whike everyone is using schemaless json (xmpp vs matrix...).
silverpill
@mariusor @hongminhee The @context is not supposed to be required in the first place, but here we are adding it to every activity and wasting bandwidth because Mastodon developers didn't read the spec.
marius
> while linked data cultists harass developers about nonresolvable URLs
@silverpill I don't consider myself a cultist but I still think that putting invalid URLs in any payload where they are supposed to be meaningful is disrespectful towards anyone that consumes your API. Please don't do that.
silverpill
@phnt @hongminhee @lutindiscret
>Also it was supposed to be entirely optional
Yes, exactly, here's ActivityPub:
https://www.w3.org/TR/activitypub/#obj
Implementers SHOULD include the ActivityPub context in their object definitions.
Here's ActivityStreams:
https://www.w3.org/TR/activitystreams-core/#jsonld
Implementations producing Activity Streams 2.0 documents SHOULD include a @context property with a value that includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition using the URL " https://www.w3.org/ns/activitystreams".
In both cases it's a SHOULD, this means I am allowed to not include @context if I have a good reason to do so.
I have plenty of reasons but Mastodon can't process an activity if there is no @context. its_always_mastodon.jpg
Phantasm
silverpill
@arcanicanis @hongminhee @lutindiscret The trap is real, I barely avoided it myself. I read SocialHub a lot when I was learning about ActivityPub and got an impression that JSON-LD is super important so it was on my to-do list for a long time. Fortunately, I got distracted by other tasks.
arcanicanis
My first ActivityPub project was very literally just wasting my time solely on trying to make a JSON-LD-first ActivityPub library to try to abstract away it from the library consumer (within reason), back around the time before ActivityPub had reached W3C Recommedation status.
I would have saved myself some amount of months by just having not get snagged into that trap, and could have instead actually shipped a usable implementation back then.
Everyone else that actually shipped an ActivityPub implementation in the beginning were the ones that treated it solely as static JSON.
I'm not saying JSON-LD is hard, nor difficult to understand (and there are some niche projects where I do want to use it)---some of it's probably even an upgrade from similar things in the XML world, but it piles on more overhead that everything has to be expanded, checked against context, just to handle different representations, all while you'll still invariably have to interop with implementations that treat it as static JSON anyway.
silverpill
@arcanicanis @hongminhee @lutindiscret Linked data is good for scientific applications, but this is not what we're building here.
silverpill
@sun @phnt @hongminhee @lutindiscret JSON-LD: not even once
Blurry Moon
silverpill
@mariusor I don't remember having such discussion. The SHOULD keyword is defined in RFC-2119:
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
There are many valid reasons to not include @context. We also have almost 10 years of implementation experience and by now full implications are very well understood: by ignoring this recommendation we make messages smaller and developer experience better. No downside at all.
marius
@silverpill aaah, I see. I think we've had this discussion before (or at least I had it with someone else).
For me "SHOULD" falls in the category of the robustness principle: "be conservative in what you do, be liberal in what you accept from others".
So for me if you treat "SHOULD" in a spec as non mandatory you haven't really implemented the spec.
silverpill
@context is a recommendation, not a requirement.
ActivityPub:
https://www.w3.org/TR/activitypub/#obj
Implementers SHOULD include the ActivityPub context in their object definitions.
ActivityStreams:
https://www.w3.org/TR/activitystreams-core/#jsonld
Implementations producing Activity Streams 2.0 documents SHOULD include a @context property with a value that includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition using the URL " https://www.w3.org/ns/activitystreams".
marius
@silverpill I'm sorry, I'm not aware of that and I thought I read the specs pretty thoroughly. Could you point me in the right direction for where you got this information from?
silverpill
@mariusor @hongminhee Authentication is not limited to signature verification. I think fetching from the originating server is an authentication method too
marius
@silverpill lol, that's simply madness to me. See the sibling reply to Julian why I think signatures, which is what I imagine you mean by "authenticated" are an unnecessary contrievance.
I meant "data object" in this context as the end-result binary data type that your application deals with, which for my preference, needs to match the structure of the incoming payload as closely as possible.
silverpill
@mariusor @hongminhee I don't know what is vocabulary data object.
An ActivityPub object is valid if it is authenticated. If a consuming implementation doesn't understand some of its properties, it should just ignore those properties. No coordination is necessary.
marius
@silverpill regarding size, ActivityPub is such a verbose protocol that the hundred or so of raw bytes you save through omitting context, are most likely negligible through the prism of connection compression. So to me that's not entirely a "valid reason".
And as developer myself, I think that contexts, even in a non valid JSON-LD implementation, offer enough guidance for building a data vocabulary for them to have plenty of value.
Do you propose we replace contexts with Open API specifications, or how do we coordinate what's a valid vocabulary data object in a federated network? And how do you propose that others discover these specs?
silverpill
@mariusor Signatures increase message size but reduce the number of network requests. They are optional, too.
marius
@silverpill personally I feel like the various activity/object signing methods that get used in recent FEPs are more egregious from a size point of view, when the in spec behaviour for obtaining canonical versions of a resource is to fetch them from their server, instead of relying on random object signing that introduces so much more friction.
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.