I ought to say some things about json-ld, because I think a lot of people aren't familiar with the details of it.

- You can play with json-ld live here: json-ld.org/playground/
- JSON-LD lets you have extensions but map them to local "compacted" shorthands, while still allowing to expand out into unambiguous form.
- JSON-LD does allow converting to a RDF graph, but it's not required. (It is interesting, though.)

(cotd ...)

- Unlike most specs, JSON-LD has a complete implementation guide w3.org/TR/json-ld-api/ Some people have been complaining on here that it's non-normative, but of course it's not normative. For example, the algorithms here are imperative, and it's legal to rewrite to a functional style without breaking the spec.
- The JSON-LD test suite is *fantastic* and if you do an implementation, will really catch a lot of things

(cotd ...)

- One of the suggestions in the "litepub" subset of activitypub being proposed (I think it's fine to explore a subset) is that core AS2 terms can be compacted while extensions should be their full URI. That's fine, and is compatible, but
- If you have a json-ld library handy, one thing you can do is just compact incoming data to the context *you* use. It'll do exactly the same thing with terms you don't know but will let you use shorthands for those you do.

- One complaint about json-ld is that it doesn't work nicely with statically compiled languages or ones with fixed records. That's because it's an open world system. But here's news: *any system* that has extensions (including litepub's proposed solution) will have this problem. Litepub won't get rid of this challenge (because records will still be fixed and won't know how to handle extensions). It would mean you wouldn't have to use a json-ld library, but those are two different things

- JSON-LD didn't come from the semantic web world, it even started as a reaction against it in some ways. Here's history from one of the JSON-LD founders, Manu Sporny: "JSON-LD and Why I Hate the Semantic Web" manu.sporny.org/2014/json-ld-o
- JSON-LD's inclusion in ActivityPub had nothing to do with pressure from W3C staff. Most W3C staff barely paid attention to ActivityPub or the SocialWG compared to most other working groups before it took off thanks to Mastodon's adoption

- The W3C has structural problems, and it's membership structure *does* lead to corruption. I've criticized this myself. However the SocialWG which standardized ActivityPub was an outlier: most participants were not corporate members but were "invited experts" from the community. This was rare in the W3C.

- JSON-LD is actually quite easy to use if you have a library that implements it. Most of the time, all you need to do is compact incoming data to the local context you know. *That's it*! It's fast too.
- If you don't have a library, the API doc walks you through it. It's not hard (I've implemented a full json-ld stack myself), just time consuming. Again, the tests are very good though.

There, I just wanted to clear up some things. Happy to answer questions.

Oh one more thing... one thing that was very exhausting about this week was seeing a ton of posts dogpile on like "Whaaaat? The json-ld devs / activitypub devs didn't realize X???? What morons" where X is addressed in a bunch of the things above.

In fact we had talked about basically all of these. Criticism is fine, and we might miss things, but don't assume that we're completely incompetent without even trying to engage in a civil way and *find out*. There may be history you don't know.

I think there's one issue you didn't address - that expanding JSON-LD can lead to denial of service, because it's impossible to predict or limit the amount of memory such expansion will take.

I may be wrong though, maybe some of the things you said means that nobody needs to do the expansion. Tbh, I have no idea how JSON-LD works 😅 Will try to read more about it later tho.

Ok, I read a bit, watched some videos, so I think I now understand what you mean. Still:

>all you need to do is compact incoming data to the local context you know.

Wouldn't that mean that if it comes from some other context, you first need to expand it, before compacting to your own context?

If the expansion can indeed use unbounded memory, that'd be a serious problem.

I think in such situation, comparing incoming context to a hardcoded URI would be the saner of two approaches.

@Wolf480pl Compacting implicitly does an expansion step, so yeah.

In general, expansion shouldn't use unbounded memory (barring a bug in some implementations but not most, being fixed currently, related to contexts) according to the algorithm much more than json itself can use unbounded memory: try handing many json parsers a 5MB file with just [ characters and many will hit a stack limit.

DoS attacks lurk everywhere; in many ways this is why processing incoming data should always be sandboxed


@cwebber that'd mean DJBernstein-style multi-process daemons, which would probably be pretty cumbersome to write in anything other than C.

@cwebber maybe we should ditch JSON and go back to regular languages. There was that talk about why we should make protocols regular or - in the worst case - context-free deterministic. Dunno if it was at C3 or BlackHat... it was by that woman with a red tie... can't find a link :/

Sign in to participate in the conversation

We are a cute and loving international community O(≧▽≦)O !