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ömen.
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]
Announcements go to:
=> maillist
Copyright © 2024-2025 Sergey Matveev <stargrave@stargrave.org>