Booz - Binary Oriented cOZ

[zamicol]

A thought experiment that's likely to never be practically implemented. Useful for comparing how efficient Coze can be when compared to an ideal binary form. Coze is already pretty efficient.

We keep our thoughts here for the potential hypothetical.

Proposal: https://github.com/Cyphrme/CozeX/blob/master/proposal/booze.md

[zamicol]

New idea:

JSON5 is already pretty efficient. A "half" measure between being full binary (JSONB/MessagePack) and nearly entirely human readable would be just adding a binary identifier for binary literals. This would still be near-maximal efficient.

The process would be first to add a JSON5 extension to Coz, and then add a very small binary extension to JSON5 and supporting that in Coz.

Just quick thought, the starting delimiter can be b", and possibly a single ending delimiter, ", although we'd want a two character ending delimiter if we expect payload sizes to be larger. Perhaps b"" and "" for longer, b" and " for shorter. The crossover appears to be 256 bytes, most coz binary payload sizes are under 64 bytes, but a big use case of the binary form is supporting very large post-quantum. The canonical form would depend on binary payload size.

Had AI dump a quick table:

Formulas:

• One-byte end: total_avg = 2 (start) + payload_size + (payload_size / 256) + 1 (end) = 3 + payload_size + (payload_size / 256)
• Two-byte end: total_avg = 2 (start) + payload_size + ((payload_size - 1) / 65536) + 2 (end) = 4 + payload_size + ((payload_size - 1) / 65536)

These were computed directly for each payload size. No additional columns were added, as per your instructions.

Payload Size (bytes)	Avg Total Bytes (One Ending Delimiter)	Avg Total Bytes (Two Ending Delimiters)	Winner	Savings (bytes)
32	35.125	36.0005	One	0.8755
64	67.250	68.0010	One	0.7510
128	131.500	132.0019	One	0.5019
256	260.000	260.0039	One	0.0039
512	517.000	516.0078	Two	0.9922
1024	1031.000	1028.0156	Two	2.9844
2048	2059.000	2052.0312	Two	6.9688
4096	4115.000	4100.0625	Two	14.9375