RON relies heavily on UUIDs to globally and unambigously identify its every construct: operations, objects, patches, versions, branches, snapshots etc. The RON UUID is one of several building blocks that lead to the immutable op.
Because RON employs UUIDs so heavily, it benefits greatly from using its own variant of UUID. The RON UUID bit layout is backwards-compatible with RFC 4122 (128 bits, RFC4122-reserved flag values). But unlike RFC 4122, time-based RON UUIDs can function as Lamport/logical/hybrid timestamps – this nuance is critical for RON and CRDTs in general.
Additionally, the textual RON UUID serialization has some nice features too.
rga, etc. The same applies to error identifiers (e.g.
NOTFOUND$~~~~~~~~~~) and other global/transcendent constants.
To minimize the confusion, RON UUID bit layout is defined in terms of two 64-bit words. The most significant word is value while the least-significant is origin. Each word’s most-significant four bits are flags, the rest is payload. In accordance with RFC4122 (as much as it is possible), two most-significant bits of the origin are set to zero. That corresponds to RFC4122 variant bits 00, thus overriding the RFC4122-reserved value “NCS backward compatibility”. We assume there are no Apollo NCS UUIDs left in circulation. The following two bits of the origin denote the RON UUID version. Flag bits of the most-significant word denote the variety, see below. Interpretation of the payload depends on the flag bits. Most often, value is the actual value (e.g. a timestamp), while origin is a replica id.
value: vvvv.... ........ ........ ........ ........ ........ ........ ........ origin: 00VV.... ........ ........ ........ ........ ........ ........ ........ flag bits: 00 RFC4122 variant VV version bits vvvv variety bits
In the textual form, two version bits are encoded as a middle separator e.g.
00: human readable names,
01: numbers and hashes,
10: events (Lamport timestamp, and origin),
11: derived events (same as event).
Four variety bits are encoded using single hex digit
F followed by a slash
Variety of zero
0 can be omitted.
Interpretation of varieties depends on the version.
Varieties for version
$ (names) are:
0000: transcendental/hardcoded name (
rga) or a scoped name (
0001: ISBN (
0011: EAN-13 bar code (
0100: SI units (
0101: zip codes (
1010: IATA airport code (
1011: ticker name (
1100: ISO 4217 currency code (
1101: short DNS name (
1110: E.164 intl phone num (
1111: ISO 3166 country code (
Varieties for version
% (numbers and hashes) are:
0011: Decimal index (up to
9999999999%, also 2D indices
0100: SHA-2, plain chunk hash, first 120 bits,
0101: SHA-3, plain chunk hash,
0110: SHA-2 based RFC 7574 Merkle hash,
0111: SHA-3 based RFC 7574 Merkle hash,
1011: Random number (
1111: Crypto id, public key fingerprint.
Varieties for versions
- (events) are a combination of timestamp variety (m.s.bits) and origin variety:
Timestamp varieties are:
00__: Base64 calendar (
01__: Logical (
10__: Epoch (RFC 4122 epoch, 100ns since 1582),
Origin varieties are:
Most of RON UUIDs can be efficiently compressed by only encoding highest significant bits.
Base 64×64 tailing zeroes can be omitted:
A/LED0000000+0000000000 = A/LED+0 A/LED0000000$123 = A/LED$123
If version is
$ and second component is zero, it can be fully omitted:
A/LED0000000$0000000000 = A/LED$0 = A/LED
If variety is
0, it can be omitted as well:
0/lww0000000$0000000000 = lww0000000$0000000000 = lww$0 = lww
Integer encoding scheme: Base 64×64.
Replica assignments rules.
Calendar-aware timestamp encoding.