The message degrades and changes with each iteration until it stabilizes at some altered form. This demonstrates that Google Translate is not composable - repeated transformations result in data loss.

By contrast, in a composable system like CESR:

• English represents the text-based, readable domain
• Dutch represents the binary domain
• Data can be concatenated and swapped freely between these "languages"
• No data changes occur regardless of conversion frequency
• Content expressed remains identical in both forms

Historical Context

Traditional binary-to-text encoding schemes like Base64 were designed primarily for transport compatibility - enabling binary data to traverse text-only protocols like email (MIME) or HTTP headers. These schemes focused on:

• Value encoding: Converting binary bytes to printable characters
• Transport safety: Avoiding control characters and protocol delimiters
• Reversibility: Enabling decoding back to original binary

However, traditional schemes had critical limitations:

1. No type information: The encoding itself doesn't indicate what kind of data it represents (key, signature, digest, etc.)
2. No size metadata: Parsers need external information to know where one primitive ends and another begins
3. Lack of composability: Concatenating encoded primitives and converting them as a group doesn't preserve individual boundaries
4. Padding ambiguity: Base64's = padding characters create parsing challenges in concatenated streams

These limitations made traditional encodings unsuitable for streaming protocols where:

• Multiple primitives of different types are concatenated
• Parsers need to process streams without external framing
• Data must be efficiently processed in both text and binary forms
• Cryptographic verification requires bit-perfect reproduction

KERI's Approach

CESR (Composable Event Streaming Representation) was specifically designed to achieve text-binary concatenation composability through several innovations:

24-Bit Boundary Alignment

The foundation of CESR's composability is 24-bit boundary alignment. Every primitive in both domains must be an integer multiple of 24 bits:

• Text domain: Integer multiple of 4 Base64 characters (4 × 6 bits = 24 bits)
• Binary domain: Integer multiple of 3 bytes (3 × 8 bits = 24 bits)

Twenty-four bits is the least common multiple of 6 (Base64 character bit width) and 8 (byte bit width). This alignment ensures that:

• Text-to-binary conversion never requires padding
• Binary-to-text conversion produces clean character boundaries
• Concatenated primitives maintain alignment

Self-Framing Primitives

Every CESR primitive is self-framing - it contains all information needed to parse it without external delimiters. This is achieved through prepended framing codes that encode:

• Type: What kind of primitive (key, signature, digest, etc.)
• Size: Length of the value portion
• Pad size: Implicitly, the padding needed for 24-bit alignment

Self-framing enables stream processing where parsers can:

1. Read the first character(s) to determine primitive type
2. Calculate the total length from the framing code
3. Extract exactly the right number of characters/bytes
4. Continue to the next primitive without ambiguity

Three Domain Model

CESR operates across three domains:

1. Text (T) Domain: Uses URL-safe Base64 characters (A-Z, a-z, 0-9, -, _) for human readability and text-protocol compatibility
2. Binary (B) Domain: Compact byte representation for efficient transmission
3. Raw (R) Domain: Represented as tuple (text_code, raw_binary) where actual cryptographic operations occur

Six transformations connect these domains: T(B), B(T), T(R), R(T), B(R), R(B). The composability property ensures that:

T(B(T(primitive))) = T(primitive)
B(T(B(primitive))) = B(primitive)

For concatenated primitives:

T(cat(B(t[1]), B(t[2]), ..., B(t[n]))) = cat(t[1], t[2], ..., t[n])

Code Tables Architecture

CESR uses multiple code tables optimized for different primitive sizes and types:

• Small fixed raw size tables: 1-2 character codes for common primitives
• Large fixed raw size tables: 4-character codes for less common primitives
• Small variable raw size tables: For primitives with variable-length raw data
• Large variable raw size tables: For larger variable-length primitives

Each table is designed to maintain 24-bit alignment through careful selection of code lengths and padding strategies. The code table selector mechanism allows CESR to support multiple tables while maintaining composability.

Pre-Padding vs. Post-Padding

CESR uses pre-padding (lead bytes) rather than post-padding to achieve alignment:

• Traditional Base64: Uses = characters as post-padding
• CESR: Uses lead bytes that are part of the framing code

This approach eliminates the ambiguity of padding characters in concatenated streams and ensures that every primitive is self-contained and self-framing.

Practical Implications

Stream Processing Efficiency

Composability enables cold start stream parsing - after a reboot or when beginning to process a stream, parsers can immediately identify primitive boundaries without requiring external framing information. This is critical for:

• Network protocols: Where streams may be interrupted or fragmented
• Event logs: Where parsers need to resume processing from arbitrary points
• Distributed systems: Where different components may process the same data in different domains

Domain Flexibility

Applications can choose the most appropriate domain for their needs:

• Text domain: For human readability, debugging, text-based protocols (HTTP, JSON)
• Binary domain: For compact transmission, storage efficiency, binary protocols
• Raw domain: For cryptographic operations that require actual key material

The composability property ensures that this choice doesn't lock the application into a single domain - data can be freely converted as requirements change.

Cryptographic Integrity

For KERI key events and ACDCs, composability is essential because:

• Signatures must verify against the exact signed content
• Digests must match the exact hashed data
• Key material must be bit-perfect for cryptographic operations

Composability guarantees that converting a signed KEL between text and binary domains doesn't invalidate signatures or break cryptographic commitments.

Interoperability

Different KERI implementations may prefer different encodings:

• Browser-based implementations: Often prefer text domain for JavaScript compatibility
• Embedded systems: May prefer binary domain for memory efficiency
• Witness networks: May use binary for network efficiency but text for logging

Composability ensures that these implementations can interoperate seamlessly - a witness can receive events in binary, process them, and return receipts in text without any loss of integrity.

Pipelining and Multiplexing

CESR's composability enables hierarchical composition through count codes and group codes:

• Count codes: Specify how many primitives follow in a group
• Group codes: Enable nested structures and pipelining

This allows complex data structures like key event messages with multiple signatures and attachments to be processed as atomic units while maintaining composability at every level of the hierarchy.

Trade-offs

The 24-bit alignment requirement means that:

• Some primitives require padding: Small primitives may have lead bytes that don't carry information
• Code space is constrained: The number of available codes is limited by alignment requirements
• Implementation complexity: Parsers must handle multiple code tables and padding strategies

However, these trade-offs are justified by the benefits:

• Guaranteed composability: No data loss across domain transformations
• Self-framing: No external framing protocol required
• Efficient streaming: Parsers can process data in a single pass
• Cryptographic integrity: Perfect fidelity for signed and hashed data

Conclusion

Text-binary concatenation composability is not merely a convenience feature but a fundamental architectural property that enables KERI's verifiable data structures to function reliably across diverse computing environments. By ensuring that concatenated primitives can be freely converted between text and binary domains without loss, CESR provides the encoding foundation for a truly interoperable, verifiable internet infrastructure.

Implementations should verify composability through:

• Round-trip tests: Convert primitives through multiple domain transformations and verify identity
• Concatenation tests: Verify that group conversion equals individual conversion
• Boundary tests: Ensure that primitive boundaries are correctly identified after domain conversion
• Cryptographic tests: Verify that signatures and digests remain valid after domain transformations