Decide on encoding of circulex messages
Open, To DoPublic


Currently, the encoding is a mixture of artisanal hand-crafted byte-strings and JSON. The former is necessary because it's very hard to define a canonical JSON encoding of an object that you want to hash or sign. And yet, we've still ended up with the situation where a bilateral agreement contains the hashes of invitation messages, which contain JSON, thus forcing instances to keep the exact JSON encodings of objects, rather than simply storing the objects in any convenient form that allows reconstruction of the encoding that was hashed.

To avoid this problem, we could choose a different (easily canonicalizable) encoding and use it for everything, instead of mixing it with bespoke encodings. But which encoding scheme?

Bencode has the property that every object has exactly one valid encoding, so you get canonicity for free. But it encodes integers in decimal, which seems less than ideal (though JSON does the same).

CBOR seems more thoroughly thought-through, and by design is very compact and easy for computers to encode and decode. It lacks canonicity-by-default, but the RFC gives advice on defining a canonical form where necessary, which seems much easier than it would be for JSON. There's even what appears to be a near-standard way of specifying CBOR data structures.


R1:35669953061c: ASN.1 definition of data for generating next key in partial agreement
R1:5abf862f8b7d: Resimplify ASN.1 definition of null relay requests
R1:d299a486e073: Reuse PublicKey in ASN.1 definition of common transaction parameters
R1:3e00b3d15a77: ASN.1 statement can express limit on duration of outstanding transactions
R1:58d7337a5021: Allow path types to have different parameters in ASN.1 definitions
R1:550dc0922112: Timestamps on ASN.1 invitations and statements, in case re-received
R1:a7ed7f5be81c: Add table constraints to custom constraints in ASN.1 open types
R1:b4b77582af1f: ASN.1 definition of a signable object, to avoid ambiguity
R1:7b8718209029: Payment requests specify a paywise target in ASN.1 definitions
R1:e237808ab904: Extensibility of path types in ASN.1 definitions
R1:5a83bf89c178: Constrain key and signature types in ASN.1 code
R1:3a1389b6dfd3: Extensible choice of signature scheme in ASN.1 schema
R1:9c4b6e85b648: Make room in the ASN.1 schema for other hash algorithms
R1:74462a8a183d: Move requestable class to a more relevant position in ASN.1 code
R1:bdfd80860eed: Move misplaced comment in ASN.1 definitions
R1:e7c0193314e6: Reorganized ASN.1 definitions
R1:8bd391ed9c39: ASN.1 definitions of remaining messages
R1:a52a72c9d211: ASN.1 definitions for most messages
R1:68df9c063bd1: ASN.1 definitions for remainder of "Definitions" section
R1:fb1a71bd9e69: Include finality deadline in ASN.1 definition of transaction id
R1:ce2d445856d4: More ASN.1 definitions
R1:32b635f514e2: ASN.1 definition of currency
R1:f134a22f6b29: ASN.1 definitions of instance and participant identities
R1:660d9bc4891a: ASN.1 definitions of port numbers and instance locations
R1:4ec56cacea17: ASN.1 specification of host addresses
R1:148507425358: ASN.1 definitions for cryptographic things
R1:e6900044e908: Simple start of ASN.1 specification

Event Timeline

tim triaged this task as To Do priority.Dec 20 2018, 5:54 PM
tim created this task.