Version: 2.0.0 Last Updated: 2026-01-04 License: CC BY 4.0
Architecture Note: RPP uses two complementary, coexisting address layers — not competing versions. The Semantic Interface Layer (v1.0, 28-bit Shell/Theta/Phi/Harmonic) serves developers and applications. The Transport/Resonance Layer (v2.0, 32-bit Ra-derived θ/φ/h/r) serves the substrate. Both are active. See spec/ADDRESSING-LAYERS.md for the full architecture and rationale.
RPP was created to solve a fundamental mismatch in modern computing:
The Problem:
- Storage systems optimize for bytes, not meaning
- AI systems deal in semantics, but store in blobs
- Access control is binary (allowed/denied), not stateful
- Address = location, never classification
The Insight: What if the address itself carried meaning?
Current Decision: Fixed 32-bit Ra-Canonical address.
The v2.0 format derives field allocations from the Ra System constants:
- θ (5 bits): 27 Repitans (semantic sectors)
- φ (3 bits): 6 RAC access levels
- h (3 bits): 5 Omega coherence tiers
- r (8 bits): Intensity scalar (Ankh-normalized)
- Reserved (13 bits): CRC or future use
Why the change from 28-bit v1.0?
- Ra System provides semantic meaning to field boundaries
- Full 32-bit alignment simplifies hardware implementation
- Reserved bits allow for integrity checking (CRC-13)
- Maintains backward compatibility via migration path
Original Decision: Fixed 28-bit address width.
Alternatives Considered:
| Width | Pros | Cons |
|---|---|---|
| 16-bit | Compact | Too small (65K addresses) |
| 32-bit | Standard | Wastes 4 bits, cache-inefficient |
| 64-bit | Huge space | Overkill, splits registers |
| Variable | Flexible | Parsing overhead, no hardware parity |
Original Rationale (v1.0):
- 28 bits = 268M addresses (sufficient for semantic space)
- Fits in 32-bit register with 4 bits for parity/flags
- Matches historical sweet spots (68000, LISP machines, early ARM)
- SPI-friendly (4 bytes with alignment)
- FPGA register-packable
Decision: Address = (Shell, Theta, Phi, Harmonic)
Alternatives Considered:
| Model | Pros | Cons |
|---|---|---|
| Linear | Simple | No semantic structure |
| Hierarchical (tree) | Familiar | Rigid, deep paths |
| Hash-based | O(1) lookup | No locality, no meaning |
| Cartesian 3D | Intuitive | Unbounded, no natural center |
| Spherical | Bounded, symmetric | Slightly more math |
Rationale:
- No privileged direction (all sectors equal)
- Natural radial hierarchy (shells = depth/temperature)
- Angular locality (similar functions cluster)
- Bounded space (no infinite addressing)
- Rotational symmetry (elegant traversal)
Decision: RPP routes to existing storage; it doesn't replace it.
Alternatives Considered:
| Approach | Pros | Cons |
|---|---|---|
| New filesystem | Full control | Zero adoption, massive risk |
| New database | Optimized semantics | Migration nightmare |
| Overlay/bridge | Zero migration | Less optimization |
Rationale:
- Existing storage is excellent at durability, scale, cost
- RPP adds what's missing: semantic routing, consent, lifecycle
- Zero migration = adoptable today
- "Make the right thing easy" > "Force the new thing"
Decision: Access gating is intrinsic to address resolution.
Alternatives Considered:
| Approach | Pros | Cons |
|---|---|---|
| External ACLs | Standard | Bolted-on, byppassable |
| Capability tokens | Proven | Token management overhead |
| Address-intrinsic | Unforgeable | Requires resolver |
Rationale:
- Traditional ACLs are separate from data location
- RPP embeds consent requirements in the address semantics
- Theta sector + Phi grounding = consent requirements
- Can't access without knowing the address → knowing implies context
Decision: Defensive publication, Apache 2.0, no patent claims.
Alternatives Considered:
| Approach | Pros | Cons |
|---|---|---|
| Patent everything | Revenue, control | Slow adoption, legal costs |
| Patent + license | Some protection | Complexity, distrust |
| Open source | Fast adoption | No exclusivity |
| Defensive publication | Prevents capture | No revenue from IP |
Rationale:
- A consent-based architecture cannot be coercively owned
- Open infrastructure spreads faster than proprietary
- Prior art publication prevents future enclosure by anyone
- Ecosystem value > licensing rent
Why only 4 shells?
- 4 tiers cover 99% of storage temperature needs (hot/warm/cold/frozen)
- More tiers = diminishing returns + complexity
- 2 bits = no wasted space
Why radial?
- Natural metaphor: closer to center = hotter
- Hierarchical without being tree-structured
- Shell transitions are single-dimension moves
Why 9 bits?
- 512 values ≈ 1.4° resolution if mapped to 360°
- Enough for 8 major sectors with 64 sub-divisions each
- Balances precision vs. address space
Why functional sectors?
- Gene, Memory, Witness, Dream, Bridge, Guardian, Emergence, Meta
- These are cognitive/operational categories, not arbitrary
- Inspired by identity systems, not filesystems
Why grounding axis?
- Physical → Abstract is a universal dimension
- Grounded data needs higher consent; ethereal allows flexibility
- Maps to verifiability, not importance
Why same width as Theta?
- Symmetry simplifies encoding
- Angular space should be balanced
- No reason to privilege longitude over latitude
Why "harmonic"?
- Not just version; includes mode, resolution, encoding
- Musical metaphor: frequency/resonance
- 256 values = enough for versioning, compression levels, formats
Why 8 bits?
- Byte-aligned = efficient access
- 256 modes is sufficient for most applications
- Leaves room for future extension via conventions
Once you publish an address format, you cannot change it.
- We chose conservative field widths
- We documented invariants explicitly
- We avoided "clever" encodings that might need revision
Early designs tried to build a complete storage system.
- That path leads to multi-year projects and zero adoption
- Overlay architecture ships in weeks, not years
- "Good enough routing" > "perfect storage"
Designing for FPGA/MRAM/SPI forced simplicity.
- Fixed-width addresses = no parsing
- No variable-length fields = deterministic timing
- Bit-aligned fields = hardware parity
We could have patented this.
- But patents slow adoption
- And this architecture needs ecosystem, not exclusivity
- Defensive publication is stronger than defensive patents
| Decision | Why Avoided |
|---|---|
| Encryption in addresses | Addresses should be transparent |
| Compression of addresses | Fixed width is a feature |
| Dynamic field allocation | Would fragment implementations |
| Blockchain integration | RPP is agnostic to persistence |
| AI/ML in resolution | Determinism is more important |
These are not current features but might be considered:
| Idea | Consideration |
|---|---|
| 32-bit extended format | If 268M addresses insufficient |
| Multi-shell addressing | For cross-tier operations |
| Address encryption layer | For privacy-critical deployments |
| Distributed resolver protocol | For decentralized systems |
Any such extensions must:
- Be backward compatible
- Not change core 28-bit format
- Go through RFC process
RPP exists because:
- Modern systems need semantic routing, not just byte storage
- Consent should be architectural, not bolted-on
- Bridge architectures enable adoption
- Open infrastructure prevents capture
Every design decision optimizes for:
- Simplicity over cleverness
- Adoption over perfection
- Stability over flexibility
- Openness over control
"The best infrastructure is invisible. RPP succeeds when people forget it's there."