Egregoros

@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

Also it was supposed to be entirely optional, but the current spec editors would like you to believe otherwise.

The part I love about the authors to the spec, is that as far as I'm aware, none of them have even made their own complete implementation in any way, and only one of them has made some contributions to Mastodon and Pleroma.

Meanwhile, one of the authors had their own federated microblogging application from the OStatus days (that OStatus was defined from), that they abandoned entirely, and had no interest to even attempt a remake or a fork with ActivityPub at all, despite both being their project.

I don't trust people that can't even follow through implementing their own suggestions/ideas.

I don't even understand how it reached Recommendation status, but then again I don't know all the W3C internal processes.

The hangup point that was holding it back from Recommendation status was that it lacked a test suite; and so one was written that basically [as far as I understood] was just a questionnaire of whether you implemented something or not (how does that even pass?).

I don't know if it even had anything that actually tested application behavior or validated the format or anything. But all of that's buried to the past, because it was written atop a fickle selection of tools, where the test suite codebase isn't even installable anymore. And nobody has lifted a finger for over ~6+ years now, to write a replacement, while the test suite link on the spec goes nowhere.

It's unfathomable how shallow of effort those that hold official status with the spec are.

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.