Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TSON – A JSON superset with immutable, hash-pinned schemas

tson.io

Post reply on HN
Print view View original

41–50 of 68 posts

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#41

Post by thyristan »

geoah wrote: post #27
kbolino wrote: post #19

Using the query string to carry the sha256 hash but then saying the "hash parameter is verification metadata, not identity" doesn't make much sense. The ?query part of a URL is supposed to be sent to the server. If you want to add client-side (meta)data, you should use the #fragment part of a URL. See RFC 3986, sections 3.4 and 3.5: https://datatracker.ietf.org/doc/html/rfc3986#section-3.4

Was thinking the same. ?v=4#sha111 for defining the version and using fragment for hash verification seemed like a more interesting approach.

Fragments are useless outside a browser and lead to problems. A lot of command line and library HTTP agents ignore the fragment part of an URL, so you often might encounter everything after # stripped. Thus forcing you to invent yet another HTTP client/agent/URL library in a ton of languages.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#42

Post by Retr0id »

ramses0 wrote: post #26
Retr0id wrote: post #17

What's the justification for being a superset of JSON? Being incompatible with most existing JSON tooling and interfaces is a big disadvantage, so there better be a tangible upside. Also, I see mention of hashing, but no mention of canonicalization. Does fiddling with a schema's whitespace change its hash?

"superset" is just marketing mumbo jumbo that says: "I promise to embed an x86 virtual machine inside my spec that'll still parse whatever weird JSON you're currently handling and give it back to you as an object in your programming language" $ echo '{ "Hello": "World" }' | tson --parse ERROR: ...refusing to interoperate w/ JSON b/c we want to be different ...that's a non-starter. If they're trying to replace or supp…

That's not what superset means. Taking it at face value, all JSON is valid TSON, and some TSON happens to be valid JSON but not in the general case.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#45

Post by Yannik_Sc »

I wonder where this should fit in? It introduces itself as

> Data with an immutable schema.

But for what? I don't see a fit for APIs here, maybe config but there are already other languages that are perfectly suited for this job.

Also this feels more like some proposal than a serious attempt to build a new format. Java is widely used but I would at least expect such a new format to at least release with Java-/TypeScript, Go and Python libraries (personal perference: Rust too). But just a Java launch is at best a PoC.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#46

Post by gwbas1c »

What problem is this trying to solve?

> Data with an immutable schema.

> TSON (Typed Schema Object Notation) is a schema system with immutable, hash-pinned schemas whose definitions are themselves data. A document names its schema, the schema names its meta-schema; one hash verifies the whole chain. The finishing touch, TSON's data format is a Unicode-first superset of JSON you'll actually enjoy writing.

I'm not sure what problem this is solving?

I rarely have issues with JSON schema validation; and when I do, the failure patterns aren't something that I want to offload to a 3rd party library.

Basically, how my application fails with poorly formed JSON is part of how I define my application, which means that unexpected JSON needs to be handled on a case-by-case basis.

---

Anyway, the system smells like xsd, which when I used it, wasn't worth the effort.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#47

Post by tomnipotent »

Yannik_Sc wrote: post #45

I wonder where this should fit in? It introduces itself as > Data with an immutable schema. But for what? I don't see a fit for APIs here, maybe config but there are already other languages that are perfectly suited for this job. Also this feels more like some proposal than a serious attempt to build a new format. Java is widely used but I would at least expect such a new format to at least release with Java-/TypeScr…

> I don't see a fit for APIs here

Baically protobuf, Cap’n Proto, msgpack, Avro, or every other serialization approach that versions schemas?

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#48

Post by deepsun »

ramses0 wrote: post #26
Retr0id wrote: post #17

What's the justification for being a superset of JSON? Being incompatible with most existing JSON tooling and interfaces is a big disadvantage, so there better be a tangible upside. Also, I see mention of hashing, but no mention of canonicalization. Does fiddling with a schema's whitespace change its hash?

"superset" is just marketing mumbo jumbo that says: "I promise to embed an x86 virtual machine inside my spec that'll still parse whatever weird JSON you're currently handling and give it back to you as an object in your programming language" $ echo '{ "Hello": "World" }' | tson --parse ERROR: ...refusing to interoperate w/ JSON b/c we want to be different ...that's a non-starter. If they're trying to replace or supp…

> unambiguous

But it's pretty ambiguous when parsing. Like a long number -- is it a floating point, BigInt or i128? Every language is different

JSON was a blessing because it was literally Javascript. It was unambiguous in Javascript only.

A true unambiguous would be "everything is a string", like TCL.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#49

Post by kbolino »

thyristan wrote: post #41
geoah wrote: post #27

Earlier quoted context omitted.

Was thinking the same. ?v=4#sha111 for defining the version and using fragment for hash verification seemed like a more interesting approach.

Fragments are useless outside a browser and lead to problems. A lot of command line and library HTTP agents ignore the fragment part of an URL, so you often might encounter everything after # stripped. Thus forcing you to invent yet another HTTP client/agent/URL library in a ton of languages.

Yes, this is just how fragments work; they're supposed to be stripped before sending the request to the server. This is exactly why, in the context of the thread, the fragment is the correct place to put the TSON hash parameter.
Post reply on HN