HN Explorer

Show HN: KSON, a love-letter to the humans maintaining computer configuration (kson.org)

34 points by dmarcotte ↗ HN
Hi friends, I'm really excited to introduce KSON, which just entered public beta!

Anywhere a human is reading or editing YAML/JSON/TOML, KSON may be used as a more effective interface on that data. If you are such a human, we invite you to participate in this beta.

tl;dr Check out the website [1], play with the online playground [2], install the library for your programming language [3], edit in your favorite editor [4], discuss and give feedback [5], contribute to the project [6].

(A personal note about this project: I love software. Machines made of words! Such a wonder. KSON itself, as a collection of words that both make a machine and explain that machine, is an expression of a lot ideas I feel really passionately about around software and our relationship to it. I've put a lot of love into trying to make that expression eloquent and reliable. I hope some of that comes through clearly, and I look forward to discussing this more over time with anyone who's interested)

One of the key things KSON wants to say is: let's keep everything that's great about YAML and JSON as "Configuration User Interfaces", and let's make those interfaces more toolable, robust, and fun. Here's some of the ways we do that:

- KSON is a verified superset of JSON, has native JSON Schema support, transpiles cleanly to YAML (with comments preserved!), and is likely available wherever you want it—current supported platforms: JS/TS, Python, Rust, JVM, and Kotlin Multiplatform.

- KSON is also widely available in developer tools, with support for VS Code, Jetbrains IDEs, and anywhere you can plug in an LSP.

- KSON is fully open source, licensed under Apache-2.0, and you are invited to meet its words and tinker with how they make its machine. A lot of care, craft, attention and joy went into making the KSON project understandable and approachable for developers. We hope to see you around.

PS. This is an HN-friendly version of the official announcement at <https://kson.org/docs/blog/2025/09/17/introducing-kson/>.

[1]: https://kson.org/

[2]: https://kson.org/playground/

[3]: https://kson.org/docs/install/#languages

[4]: https://kson.org/docs/install/#editor-support

[5]: https://kson-org.zulipchat.com/

[6]: https://github.com/kson-org/kson

10 comments

[ 4.7 ms ] story [ 41.4 ms ] thread
nkko
Nice to see this out there! Been playing with the token efficiency, looks like around 10% savings vs regular JSON/YAML. Not massive but it adds up. The embedded code thing is cool. Tired of configs that need weird templating or scripts all over the place just to do basic logic. Will check this out on some projects.
wofo
I met Daniel (creator of KSON) a while ago and have helped out with a few things, working towards this first beta release. I don't want to hijack the comments section, but there's an article I just finished writing that might shed a bit of context into why KSON exists. It's called "Configuration files are user interfaces" (see https://ochagavia.nl/blog/configuration-files-are-user-inter...). Hope it helps folks understand where KSON is coming from!
jared-jesionek
Excited for the GA of KSON! We've been exploring the alpha to help us build a DSL for a data viz tool and it's been really cool.
elviskahoro
So incredibly excited for this to come out! What an improvement in the quality of life for developers! My hunch is that this will also come in handy when sending data into LLMs, being able to reduce input tokens without losing fidelity is becoming an ever more important ordeal.
zahlman
So the point is that you can use the nth competing standard, and transpile it to whatever the other systems need?

What about manipulating the data?

Does it support embedded comments, like TOML does? What happens if you round-trip that through JSON? What about the other superset features?

What does KSON stand for?

There's a lot said about JSON and YAML on the main page, but why is this better than TOML?

h4ch1
The embed block seems interesting, can someone give a concrete example on its' purpose in terms of real-world usage?

Like I understand I'll get syntax highlighting, multi-line formatting; seems great for devex, but why's stopping me from putting code in a single string and parsing it?

Does it offer some benefits while parsing it? Thanks!

the_mungler
I'm not the biggest fan of the embed block syntax, for two reasons. 1. Having `%\\\%` escape to `%\\%` is confusing. Assuming you want to embed kson inside kson it would look like this:

```

%kson: level 1

  %kson: level 2

    %kson: level 3

      - "a list"

      - "of values"

    %\\%

  %\%
%%

```

Note that for each level of nesting, the delimiters inside the block have to increase, instead of the ones outside. In a long embedded block you probably copied from elsewhere, you have to check every escaped delimiter to make sure it has the correct number of back slashes and update it. It would have made more sense to have a varying number of % correspond to a matching set to close it. e.g. %%%kson: foo matches %%% and closes it.

2. It's impossible to represent strings where every line has at least some leading indent, because they "always strip their minimum indent".

I think both these issues are solved by using zig's style of raw string literals. An embed block could start with %tag and each following line with % continues the block. No closing delimiter or delimiter escapes needed.

```

%kson: level 1

  %%kson: level 2

  %  %%kson: level 3

  %  %  %  - "a list"

  %  %  %  - "of values"

  %  %  %  - "indented"
```

Granted, this also kind of looks ugly with percent signs. But the upside is you could paste in each sub level, and a text editor could insert the symbols for you before each line, just like they already do when highlighting text and commenting it out.

dmarcotte
Thanks for trying out KSON and having a look at the embed blocks. When embedding text inside text, the price/tax to delimit it must be paid somewhere, as the "KSON turducken" you've cooked up here demonstrates. We are familiar with this dish! Here's how we considered it in the design:

Our design observes that triple+ embedded KSON embed blocks should be rare and are zany enough information architecture that we do not need to cater to them. We accommodate singly-embedded KSON by offering `$/$$` as an alternative embed delimiter that can be used to minimize escaping (fun: if you paste your example in the playground <https://kson.org/playground/> and format it, the formatter will minimize the escaping for you).

The two-char end-delimiter is important to make it trivial to describe the end of a embed block: a `%` embed block ends if and only if exactly `%%` is encountered. This is designed to make it dead simple for humans and (especially) tools to understand the bounds of an embed.

Zig's manually-managed margin approach is interesting. Paying the embedded text price/tax with a manually managed margin is inventive, and does indeed give good whitespace control and skips all escaping. However, having to always manage that margin goes against our goal of having embed blocks facilitate "pure" embedded editing as much as possible---every block that does not contain `%%` can be edited completely in the block's native language.

Hopefully that helps make some of our goals and design decisions more clear. We've worked hard to minimize the cost of embedding while maximizing the clarity, utility and toolabilty of it. Definitely open to ideas on improving our min/max'ing here if folks see opportunities. Come chat with us on Zulip if you've got thoughts! https://kson-org.zulipchat.com/