# RUBE/1.0: Ridiculously Universal Byzantine Exchange Protocol
**Document:** `draft-rube-protocol-01`<br>**Category:** Experimental<br>**Intended status:** Internet-Draft-style specification<br>**Version:** 1.0<br>**Date:** 2026-07-22
## Status of This Memo
This document defines RUBE/1.0, a distributed, multi-transport, cryptographically witnessed protocol for communicating one authenticated Boolean value.
Implementation is permitted. Deployment is inadvisable.
The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** in this document are normative.
## 1. Abstract
RUBE/1.0 communicates exactly one Boolean value between an Originator and a Recipient by expanding that value into a canonical transaction capsule, wrapping the capsule through multiple serialization formats, encoding the result as a QR image, erasure-coding the image into shards, distributing those shards through unrelated protocols, publishing locator metadata through DNS, validating possession through an SMTP-to-NTP challenge, reaching agreement among three verifier nodes, recording the result in a Merkle transparency log, obtaining an independent witness signature, printing and rescanning an acknowledgement, applying OCR, and confirming the OCR digest through DTMF tones.
The final application result MUST remain unavailable until every mandatory phase has completed.
The protocol exists to ensure that a function logically equivalent to:
```text<br>bool transmit(bool value)<br>```
requires a distributed, cryptographically witnessed, cross-protocol, print-mediated consensus ceremony.
## 2. Scope
RUBE/1.0 supports exactly two application values:
```text<br>TRUE<br>FALSE<br>```
A transaction MUST carry exactly one Boolean. It MUST NOT carry a string, integer, null, array, map, stream, partial truth value, probability, or additional application payload.
A successfully completed transaction returns an application-level status of `OK` regardless of whether the transmitted Boolean is `TRUE` or `FALSE`. The Boolean itself is returned separately in the authenticated result object.
## 3. Design Requirements
A conforming implementation MUST provide:
1. authenticated origin;<br>2. payload integrity;<br>3. transaction uniqueness;<br>4. replay resistance;<br>5. erasure-coded redundancy;<br>6. cross-protocol distribution;<br>7. verifier consensus;<br>8. append-only transparency logging;<br>9. independent witnessing;<br>10. print-scan-OCR acknowledgement;<br>11. acoustic completion confirmation;<br>12. architectural disproportionality.
A conforming implementation MUST NOT optimize away a mandatory phase merely because the Boolean has already been recovered.
## 4. Conventions and Core ABNF
The notation in this section uses Augmented Backus-Naur Form.
```abnf<br>ALPHA = %x41-5A / %x61-7A<br>DIGIT = %x30-39<br>HEXDIG = DIGIT / %x41-46 / %x61-66<br>SP = %x20<br>HTAB = %x09<br>WSP = SP / HTAB<br>CRLF = %x0D.0A<br>DQUOTE = %x22<br>COLON = %x3A<br>HYPHEN = %x2D<br>DOT = %x2E<br>SLASH = %x2F<br>EQUAL = %x3D<br>SEMICOLON = %x3B<br>COMMA = %x2C
uuid = 8HEXDIG HYPHEN 4HEXDIG HYPHEN 4HEXDIG HYPHEN<br>4HEXDIG HYPHEN 12HEXDIG
bool-token = "TRUE" / "FALSE"<br>result-token = "ACCEPT_TRUE" / "ACCEPT_FALSE" /<br>"REJECT" / "INDETERMINATE"<br>state-token = "NEW" / "NEGOTIATING" / "CAPSULE_CREATED" /<br>"ENVELOPE_CONSTRUCTED" / "GLYPH_GENERATED" /<br>"SHARDS_DISTRIBUTED" / "LOCATORS_PUBLISHED" /<br>"DISCOVERY_ANNOUNCED" / "SHARDS_RETRIEVED" /<br>"PAYLOAD_RECONSTRUCTED" / "CHALLENGE_PENDING" /<br>"CONSENSUS_PENDING" / "LOGGED" / "WITNESSED" /<br>"ACK_PRINTED" / "ACK_SCANNED" / "TONE_PENDING" /<br>"COMPLETE" / "FAILED"
sha256-text = "sha256:" 64HEXDIG<br>base64-char = ALPHA / DIGIT / "+" / "/"<br>base64-text = 1*base64-char *2EQUAL
rfc3339-utc = 4DIGIT HYPHEN 2DIGIT HYPHEN 2DIGIT "T"<br>2DIGIT COLON 2DIGIT COLON 2DIGIT "Z"<br>```
UUID hex digits MUST be lowercase when serialized as text. Comparisons MUST be case-insensitive only at parsing boundaries; all emitted values MUST be lowercase.
All multi-byte integers in binary records MUST use unsigned network byte order unless explicitly stated otherwise.
## 5. Terminology
**Originator:** The endpoint transmitting the Boolean.
**Recipient:** The endpoint receiving the Boolean.
**Verifier:** One of exactly three voting nodes that validates a proposed result.
**Witness:** An entity administratively independent from the Transparency Log that signs a finalized tree head.
**Transaction:** One complete RUBE exchange identified by a UUID version 4.
**Capsule:** The canonical JSON representation of the Boolean and transaction metadata.
**Envelope Stack:** The gzip, Base64, SOAP, MIME, and DKIM representation of the Capsule.
**Glyph:** The lossless QR image containing the Envelope Stack.
**Shard:** An erasure-coded binary fragment of the Glyph.
**Locator Manifest:** A CBOR document describing shard locations without containing shard payload bytes.
**Acknowledgement Artifact:** A printer-ready document containing the authenticated...