KEKS is compact, deterministic, concise and streaming binary
serialisation format. It is aimed to be lightweight in terms of CPU,
memory, storage and codec implementation size usage. It supports wide
range of data types, making it able to transparently replace JSON.

KEKS means: kompakt, entschlossen, knapp, strömend.

But why!? Because there is no satisfiable codec for all set of
requirements below.

* It *must* be schema-less format. Schema-aware ones have their definite
  valuable advantages, but also a complication drawbacks and
  non-friendliness to humans.
* Its encoder/decoder *must* be very compact and small in terms of code
  and branches amount, to reduce attack surface on the codec itself.
* It *must* support enough data types for being able at least to replace
  JSON transparently.
* Its encoding *must* be deterministic -- there must be only a single
  representation of the structured data, allowing its usage in
  cryptography-related contexts.
* Its encoder *should* be streaming-friendly, making encoder
  simpler and allowing memory-constrained systems workability.
* Its encoding *should* be reasonably compact, to be friendly to
  storage space constrained systems.
* It *should* be frugal to CPU usage for both performance/memory
  constrained and high data volume applications.
* It *should* differentiate binary and human-readable strings.
* It *would* be nice to have human-editable intermediate representation.

Are not there any satisfiable [codecs]?

            | simple | deterministic | streamable | compact
------------+--------+---------------+------------+--------
ASN.1 DER   | N      | Y             | N          | N
ASN.1 CER   | N      | Y             | Y          | N
JSON        | N      | N             | Y          | N
BSON        | Y      | N             | N          | N
MessagePack | Y      | N             | N          | Y
CBOR        | N      | N             | Y          | Y
dCBOR       | N      | Y             | N          | Y
Netstrings  | Y      | Y             | N          | ~
Bencode     | Y      | Y             | Y          | ~
CSExp       | Y      | Y             | Y          | ~
KEKS        | Y      | Y             | Y          | Y

            | big | bin | UTF |     | big |      |     |
            | str | str | str | int | int | list | map | time
------------+-----+-----+-----+-----+-----+------+-----+-----
ASN.1 DER   | Y   | Y   | Y   | Y   | Y   | Y    | Y   | Y
ASN.1 CER   | Y   | Y   | Y   | Y   | Y   | Y    | Y   | Y
JSON        | Y   | N   | Y   | Y   | Y   | Y    | Y   | N
BSON        | N   | Y   | Y   | Y   | N   | Y    | Y   | Y
MessagePack | N   | Y   | Y   | Y   | N   | Y    | Y   | N
CBOR        | Y   | Y   | Y   | Y   | N   | Y    | Y   | N
dCBOR       | Y   | Y   | Y   | Y   | N   | Y    | Y   | N
Netstrings  | Y   | Y   | N   | N   | N   | N    | N   | N
Bencode     | Y   | Y   | N   | Y   | Y   | Y    | Y   | N
CSExp       | Y   | Y   | N   | N   | N   | Y    | N   | N
KEKS        | Y   | Y   | Y   | Y   | Y   | Y    | Y   | Y

Note about CBOR:

* Hardly you will find wide range of CBOR libraries supporting strict
  validation of deterministically encoded CBOR structures.
* Tagged string/integer can not be taken as a viable first-class
  bigint/datetime data support, because many decoders do not support
  tags and won't be able to interpret/validate them.
* Non-string map keys very complicates representation process for
  dynamically types languages.

  [INSTALL]
[encoding/]
  [schema/] -- Structure validation against schemas
      [cm/] -- Cryptographic Messages
      [RPC] -- Remote Procedure Call
   [THANKS]

Copyright © 2024-2025 Sergey Matveev <stargrave@stargrave.org>