@julian @mat

Do you know about the backgrounds of the immers project ?
, "no-one's actually using AP to play chess"
the reason that we have noa AP chess service _anymore_ is #uspol …

This all feels very unfair somehow cause I know the backgrounds but anyway …
While we 2 days ago had a long thread about our use of Chess Games I will link the video from the thread https://digitalcourage.social/@sl007/116023149133783002

immers with its federated locations and positional audio etc was supernice for playing chess !
Our use is fairly similar and straightforward like we did the chess Social CG meeting in 2018 and the rc3 (usually 18.000 people physically but here it was virtually cause pandemics) https://socialhub.activitypub.rocks/t/rc3-chaos-communication-congress/1202

Maybe it would really be fair if people are new to look into the 20 years Social CG history where some volunteers really gave much work :)
🧵 1/2

@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

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.

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 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?

@hongminhee

@chomu.dev JSON-LD를 그냥 JSON으로 다뤄도 괜찮다고 보는 사람이 많은 것 같아요.