@evan Yes, in theory I like the concept of JSON data clearly communicating what it means.

But, the fact that it hasn’t *really* caught on makes it a bit of a pain to try to do it right.

@evan@cosocial.ca we adopted JSON-LD for our knowledge graph at work too. Its flexibility and interoperability is a blessing.

@evan@cosocial.ca dems fightin' words

> @cmars@infosec.exchange said:
>
> Is the problem of multiple schemas colliding with contextual ambiguity a real enough problem in practice to require all the complexity of LD up front?

You are not wrong. There are two ways to approach the problem of namespace collisions.

Technically, that's JSON-LD, and socially, which is talking to the other party and sharing the name space or choosing a different name.

Maybe JSON-LD was invented because people don't like confrontation hehe

@evan a lighter weight json-ld-like solution would have been ideal imo... i feel like it pulled in a lot of complexity for the 5-10% that's actually useful for ActivityPub and in actual practice.

@julian @cmars @evan i wasn't there but i suspect it was pulled in to pave the way for a future that hasn't yet arrived, and because retrofitting something like json-ld would be near impossible when that future did eventually arrive. (i'd love to know the official story, however...)

@toddsundsted@epiktistes.com @julian@activitypub.space @cmars@infosec.exchange @evan@cosocial.ca

The real purpose of grotesquely overengineered standards like ActivityStreams — standards so absurdly complex that they needed their own toolchain just to generate the code you were then expected to finish by hand — was never merely interoperability. It was gatekeeping disguised as architecture.

Make the standard complicated enough, verbose enough, and expensive enough to implement, and the lone programmer disappears from the picture. At that point, only a medium-sized company, a large corporation, or some well-funded foundation can realistically afford to build something that actually works.

It is one of the oldest tricks in the corporate playbook: bury a perfectly understandable problem under committees, abstractions, ontologies, tooling, generators, and architectural piety until the jungle of independent hackers — the people who build things because they are curious, stubborn, or simply having fun — is effectively locked out.

Then, of course, everyone solemnly congratulates themselves on having created an “open standard.”

Fortunately, reality had other plans.

The project failed.

@cmars @evan I was considering json-ld for automated email address verification because that’s what the structured email group are working with. But there’s sooooo much boilerplate

@julian @cmars

it's less "people don't like confrontation" and more "people don't universally agree to all terms". it's a real problem *if* you don't want to bludgeon everyone into accepting a de jure or de facto central registry. here, "de jure" is W3C and "de facto" is Mastodon, but make no mistake, you get bludgeoned either way... unless you explicitly allow for disagreements.

@trwnh@mastodon.social whatever happened to "be liberal in what you accept"?

@julian funny thing is people are way less liberal than they think they accept. fedi expects you to share the exact same term definitions as them, with no recognition of even the *possibility* that it might be different.

@gabboman @evan ٠

@evan

@evan No, but I spent several years struggling with XML schemas and it's definitely better than that

@evan Once you get it, it’s amazing. People just don’t have experience with semantic style systems. If the databases they learned first had unique urls to their fields and encouraged reuse of well established types, they would love it.

@spraoi @evan I don't doubt it, but it's not exactly prevalent in this space.

The vast majority of what I've read around various ActivityPub implementations (I'm noodling on my own extremely slowly), is basically "Just stick this value in @ context and move on", there doesn't seem to be a lot of love for it.

@ricci @evan How is it better?

@evan In the "No, but" camp since I'm all for linked data, but not a fan of JSON-LD serialisation.

I didn't use to like it. Now, I think it's great.

Yes, but I wish more people understood it better.