I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
-
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the
@contextright. Naturally, mistakes creep in.But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
#JSONLD #fedidev
JSON-LD is a trap. Sorry you fell in.
-
JSON-LD is a trap. Sorry you fell in.
> @hongminhee@hollo.social said in I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.:
>
> Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.This asymmetry of blame and credit is a real problem in distributed systems generally, as much economically as emotionally. The system doesn't actually scale to multiple disjoint platforms and orthogonal ecosystems without someone doing the hard work of open-world translation... if everyone hardcodes their preferred JSON shape it quickly becomes a zero-sum game and small players have to do much more work than big players. This has consistently been a challenge for public-benefit funders, who try funding load-bearing infrastructure like fedify to avoid those dynamics, but that often demands funding bigger teams on longer horizons than they are set up to fund by their structure.
-
JSON-LD is a trap. Sorry you fell in.
@rimu@piefed.social we if it's a trap we're all in it because ActivityPub is a JSON-LD serialization fullstop, if the collective action problem results in a majority of projects wanting to abandon that and hardcode to a closed-world JSON model just fork the protocol and call it something else.
-
> 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.
-
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the
@contextright. Naturally, mistakes creep in.But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
#JSONLD #fedidev
@hongminhee@hollo.social I'll give you my take on this... which is that my understanding of JSON-LD is that with JSON-LD you can have two disparate apps using the same property, like
thread, and avoid namespace collision because one is actuallyhttps://example.org/ns/threadand the other's reallyhttps://foobar.com/ns/thread.Great.
I posit that this is a premature optimization, and one that fails because of inadequate adoption. There are likely documented cases of implementations using the same property, and those concern the actual ActivityStreams vocabulary, and the solution to that is to communicate and work together so that you don't step on each others' toes.
I personally feel that it is a technical solution to a problem that can be completely handled by simply talking to one another... but we're coders, we're famously anti-social yes? mmmmm...
-
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the
@contextright. Naturally, mistakes creep in.But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
#JSONLD #fedidev
Great piece of writing, and I agree with lots of what you say here. Building this stuff is super hard, so good for you doing it “the right way.”
I hate not being able to trust the data I receive.
I’m one of those who’s taking the shortcuts, which has plenty of drawbacks, so I’m glad you’re in here fighting the good fight.
-
Great piece of writing, and I agree with lots of what you say here. Building this stuff is super hard, so good for you doing it “the right way.”
I hate not being able to trust the data I receive.
I’m one of those who’s taking the shortcuts, which has plenty of drawbacks, so I’m glad you’re in here fighting the good fight.
@benpate reminder that you can have a trusty library that fulfills more or less the same functionality of fedify any time you want to switch. ;;)
-
@hongminhee@hollo.social I'll give you my take on this... which is that my understanding of JSON-LD is that with JSON-LD you can have two disparate apps using the same property, like
thread, and avoid namespace collision because one is actuallyhttps://example.org/ns/threadand the other's reallyhttps://foobar.com/ns/thread.Great.
I posit that this is a premature optimization, and one that fails because of inadequate adoption. There are likely documented cases of implementations using the same property, and those concern the actual ActivityStreams vocabulary, and the solution to that is to communicate and work together so that you don't step on each others' toes.
I personally feel that it is a technical solution to a problem that can be completely handled by simply talking to one another... but we're coders, we're famously anti-social yes? mmmmm...
@hongminhee @julian I'm a true believer in RDF from back in the day, so I'm hardly neutral. But...
There are essentially no interesting ActivityPub extensions right now. Even Evan's chess example, no-one's actually using AP to play chess. It's just ActivityStreams + a few cute tricks now and then. Even if there were extensions, existing AP servers chop off and throw away data they don't understand. so none of these extensions could work.
I feel like most of the "WTF am I learning JSON-LD for" criticisms are coming from this status quo. That includes "if someone wants to add a gallery thing or whatever, can't they make a FEP?" The way things work now, your extension either a) works only in your software or b) has to be painfully negotiated with the whole community. We're all gonna have a big fight about it on this forum anyway. Let's not pretend JSON-LD helps us.
But if we add two things to the mix, the situation looks different. Those are 1. server software that "keeps all the bits", and 2. a whitelabel extensible app. That would make it very easy to spin up crazy new experiences for a sizeable existing userbase. Developers should not be forced to endure a FEP process, and they should not have to attract a userbase from nothing. They should be able to just build, without even worrying if they're stepping on toes. And of course, Fedify and libraries in other languages are a load-bearing part of that world, including enforcement of the JSON-LD rules.
That world does not exist at all today, but JSON-LD does, so it's pretty valid to describe this design as premature optimisation. I dunno though, we don't seem that far away.
-
@hongminhee@hollo.social I'll give you my take on this... which is that my understanding of JSON-LD is that with JSON-LD you can have two disparate apps using the same property, like
thread, and avoid namespace collision because one is actuallyhttps://example.org/ns/threadand the other's reallyhttps://foobar.com/ns/thread.Great.
I posit that this is a premature optimization, and one that fails because of inadequate adoption. There are likely documented cases of implementations using the same property, and those concern the actual ActivityStreams vocabulary, and the solution to that is to communicate and work together so that you don't step on each others' toes.
I personally feel that it is a technical solution to a problem that can be completely handled by simply talking to one another... but we're coders, we're famously anti-social yes? mmmmm...
@julian I don't think it's premature optimization, but an artefact of ActivityPub being built on top of the Activity Streams vocabulary, which predates it by some time.
-
@hongminhee @julian I'm a true believer in RDF from back in the day, so I'm hardly neutral. But...
There are essentially no interesting ActivityPub extensions right now. Even Evan's chess example, no-one's actually using AP to play chess. It's just ActivityStreams + a few cute tricks now and then. Even if there were extensions, existing AP servers chop off and throw away data they don't understand. so none of these extensions could work.
I feel like most of the "WTF am I learning JSON-LD for" criticisms are coming from this status quo. That includes "if someone wants to add a gallery thing or whatever, can't they make a FEP?" The way things work now, your extension either a) works only in your software or b) has to be painfully negotiated with the whole community. We're all gonna have a big fight about it on this forum anyway. Let's not pretend JSON-LD helps us.
But if we add two things to the mix, the situation looks different. Those are 1. server software that "keeps all the bits", and 2. a whitelabel extensible app. That would make it very easy to spin up crazy new experiences for a sizeable existing userbase. Developers should not be forced to endure a FEP process, and they should not have to attract a userbase from nothing. They should be able to just build, without even worrying if they're stepping on toes. And of course, Fedify and libraries in other languages are a load-bearing part of that world, including enforcement of the JSON-LD rules.
That world does not exist at all today, but JSON-LD does, so it's pretty valid to describe this design as premature optimisation. I dunno though, we don't seem that far away.
@mat@friendica.exon.name that's a really interesting point of view, and has some parallels to how app development on the ATProto side is easier in many ways.
I do think that this is something C2S (aka the ActivityPub API) can enable.
I am critical of JSON-LD but I do certainly recognize I could be very wrong
-
@mat@friendica.exon.name that's a really interesting point of view, and has some parallels to how app development on the ATProto side is easier in many ways.
I do think that this is something C2S (aka the ActivityPub API) can enable.
I am critical of JSON-LD but I do certainly recognize I could be very wrong
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/116023149133783002immers 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/1202Maybe 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 -
@mat@friendica.exon.name that's a really interesting point of view, and has some parallels to how app development on the ATProto side is easier in many ways.
I do think that this is something C2S (aka the ActivityPub API) can enable.
I am critical of JSON-LD but I do certainly recognize I could be very wrong
@julian I don't know as much as I'd like about AT Lexicons. That is, not so much how they work, but what the grand idea is? I don't even understand if Bluesky imagines them being mixed and matched JSON-LD style. I think not? -
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/116023149133783002immers 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/1202Maybe 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/2We implemented this standard and you can create / describe your rooms [Place, `redaktor:fictional`] and the chessboard is just a geohash as described in the geosocial CG so the use is the same, just `redaktor:fictional` too,
You load the Collection of Chessfigures (pawn1 ...) can name them, they `Travel` over the chessboard ant the `Arrive` describes the `result`.
As always you can get very detailed with wikidata properties and entities but bare AS Vocabulary is enough.
In the end you have a Collection for the Travels which is your played game which you can replay or do whatever with.But you can still install immers - it is worth a try https://github.com/immers-space
The reason for its end are the same as for the gup.pe groups and I hope people konw about it …
-
We implemented this standard and you can create / describe your rooms [Place, `redaktor:fictional`] and the chessboard is just a geohash as described in the geosocial CG so the use is the same, just `redaktor:fictional` too,
You load the Collection of Chessfigures (pawn1 ...) can name them, they `Travel` over the chessboard ant the `Arrive` describes the `result`.
As always you can get very detailed with wikidata properties and entities but bare AS Vocabulary is enough.
In the end you have a Collection for the Travels which is your played game which you can replay or do whatever with.But you can still install immers - it is worth a try https://github.com/immers-space
The reason for its end are the same as for the gup.pe groups and I hope people konw about it …
@sl007 @julian I admit I didn't pay attention to immers at the time - I don't play games, not even chess. I was just using chess as an example, didn't mean to trigger anyone's trauma!
Still, it kinda proves my point. You have to use standard AS vocabulary because Mastodon, and if you squint then sure,
TravelandArrive, why not? But given some of the conversations I've seen on this forum, I shudder to think how that would go down if you tried to get approval for that usage from "the community" first. -
@sl007 @julian I admit I didn't pay attention to immers at the time - I don't play games, not even chess. I was just using chess as an example, didn't mean to trigger anyone's trauma!
Still, it kinda proves my point. You have to use standard AS vocabulary because Mastodon, and if you squint then sure,
TravelandArrive, why not? But given some of the conversations I've seen on this forum, I shudder to think how that would go down if you tried to get approval for that usage from "the community" first.@mat Has a reason, just wrote it to @julian in a DM, just didn't want to post public.
Not sure if you visited the link. This _was_ the community approval …
Immers was famous and we had some official Social CG meetings where I linked one where thousands of community people attended (?)
The W3C Social CG _is_ the Community (?)
Meanwhile even Public Spaces Incubator uses it which is to my best knowledge the largest upcoming iimplementor by far.
I mean apart from that it is pretty obvious after the meeting where we talked about "factual" vs "fictional".
mastodon has nothing to do with this. The majority of projects count in a democracy. We had a demo playing chess between 4 softwares.Doing the official AP Conf and becoming elected Policy Lead, I had always asked the community. For 20 years
https://conf.tube/c/apconf_channel/videosNot sure if anyone did read the "Conformance Section" of ActivityPub. https://www.w3.org/TR/activitypub/#conformance
It is section 2 - You have to support "The Entirety"...
If mastodon does not it is not ActivityPub. -
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the
@contextright. Naturally, mistakes creep in.But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
#JSONLD #fedidev
@hongminhee @jalefkowit huh. I’ve been pondering using it for some projects of mine, so this is good to know.
Is it a fundamental problem with JSON-LD, such that it should just be avoided, or a problem with how ActivityPub uses it?
And is there something else you’d recommend that fulfills the same goals?
-
@sl007 @julian I admit I didn't pay attention to immers at the time - I don't play games, not even chess. I was just using chess as an example, didn't mean to trigger anyone's trauma!
Still, it kinda proves my point. You have to use standard AS vocabulary because Mastodon, and if you squint then sure,
TravelandArrive, why not? But given some of the conversations I've seen on this forum, I shudder to think how that would go down if you tried to get approval for that usage from "the community" first.@mat
Just btw, this is 7 years old https://www.reddit.com/r/chess/comments/94ubnd/chess_over_activitypub/ but anywayHowever, given that I have, including immers and redaktor, at least 3 apps where I can use the first chess spec.:
if more than 2 implementations will also support this second chess specification, I will do so too. -
@hongminhee @jalefkowit huh. I’ve been pondering using it for some projects of mine, so this is good to know.
Is it a fundamental problem with JSON-LD, such that it should just be avoided, or a problem with how ActivityPub uses it?
And is there something else you’d recommend that fulfills the same goals?
@lkanies@hachyderm.io @jalefkowit@vmst.io To be honest, I'm not too sure myself. I just know that JSON-LD was originally planned as a foundation for the Semantic Web. I can only guess that if ontology is useful in a certain area, then JSON-LD would probably be useful there too.
-
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the
@contextright. Naturally, mistakes creep in.But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
#JSONLD #fedidev
@hongminhee do you use the activitystrea.ms module from npm? It takes a lot of the pain out.
-
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the
@contextright. Naturally, mistakes creep in.But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
#JSONLD #fedidev
@hongminhee I agree that new developers should use a JSON-LD processor. It saves a lot of heartache.
