Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Seem to different from JSON to be an easy drop in, while still having the problems of json. I’d rather use something further away like cue.
    by lokar
  • >> Ordering, consensus, and mutability policy are application concerns outside this series. [1]

    Of course, immutable means as-is, but since you're not dealing with ordering etc (that's pretty big), I might as well use existing tech (JSON with a schema) and a policy (simple/naive: hash and compare lowercased data).

    [1] From their spec: 2.2.1 Identity and Content Addressing - https://tson.io/2026/32/tson-part1-data/#

    by al_be_back
  • you can just add schema to json why add new syntax now, especially for json I dont think it makes sense I honestly believe the war is over there won't be a xml to json moment unless we move to a new platform other than browsers which seem rather unlikely, json honestly is fine for something that's somewhat human readable...
    by minraws
  • I think I'm gonna go back to XSLT
    by hmokiguess
  • 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.

    by gwbas1c
  • 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?

    by Retr0id
  • Dislike.

    No comments means that one cannot use it for configuration. Properties repeat the XML mistake of the attribute/content dichotomy.

    And trailing commas as a syntax error prevents easy sorting/appending/editing of arrays.

    And it doesn't fix a ton of JSON problems like strings containing newlines, quotes and the like, while introducing a ton of new problems, like the dependency on obscure Unicode features to elide quotes. This will lead to TSON homoglyph attacks.

    by thyristan
  • 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
    by kbolino

Explore Birbla archives