Hyper-Protocolization — Endo/Exo Nexus Design
- Hyper-Protocolization — Endo/Exo Nexus Design
Hyper-Protocolization — Endo/Exo Nexus Design
The Core Insight
Every Kapnet interaction is simultaneously TWO protocols:
┌─────────────────────────────────────────────────────────────┐
│ KAPNET INTERACTION │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ EXO-PROTOCOL (External) │ │
│ │ ┌────────────────────────────────────────────────┐ │ │
│ │ │ MLS-encrypted Nostr event (kind-30078) │ │ │
│ │ │ ┌──────────────────────────────────────────┐ │ │ │
│ │ │ │ ENDO-PROTOCOL (Internal) │ │ │ │
│ │ │ │ TXXM envelope: │ │ │ │
│ │ │ │ - type: submission|review|governance │ │ │ │
│ │ │ │ - payload: coordination data │ │ │ │
│ │ │ │ - dependencies: parent TXXM refs │ │ │ │
│ │ │ │ - state transition: braid +1 │ │ │ │
│ │ │ └──────────────────────────────────────────┘ │ │ │
│ │ └────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ Endo = coordination semantics (TXXM, braid, KScript) │
│ Exo = transport encryption (MLS, Nostr, relays) │
│ Bind = the TXXM envelope (fused at the protocol level) │
└─────────────────────────────────────────────────────────────┘
Endo Nexus (Internal Coordination)
The endo-protocol is the “civil” layer — deterministic, consensus-bearing, settlement-relevant.
Primitives
- TXXM Envelope — Atomic coordination act
- Braid — Concurrent ordering surface
- Knot — Checkpoint of braid state
- State Tree — Persistent namespace-separated state
- KScript — Deterministic execution environment
- Hedlbit — Coordination accounting unit
Properties
- Deterministic: Same inputs → same outputs, always
- Consensus-bearing: Braid convergence = agreement
- Settlement-relevant: Can anchor to Bitcoin
- Namespace-scoped: KOR isolation with cross-namespace permeability
Endo Nexus Point
The braid is where all endo-protocol activity converges. Every TXXM submitted, every KScript executed, every state transition — all flow into the braid. The braid IS the endo nexus.
Exo Nexus (External Transport)
The exo-protocol is the “social” layer — encrypted, distributed, censorship-resistant.
Primitives
- Nostr Events — Signed JSON envelopes (kind, content, tags, sig)
- MLS Groups — Messaging Layer Security for group encryption
- Relays — Distributed message routing (anyone can run one)
- Keypair Identity — npub = identity (no passwords)
- Media — Encrypted file sharing
Properties
- Encrypted: MLS forward secrecy + post-compromise security
- Distributed: No single point of failure
- Censorship-resistant: Any relay can carry messages
- Identity-based: Keypair = account
Exo Nexus Point
The relay is where all exo-protocol activity propagates. Every encrypted message, every group key exchange, every media share — all flow through relays. The relay IS the exo nexus.
The Control Bind
The TXXM envelope is the control bind — the point where endo and exo are fused.
TXXM ENVELOPE (Control Bind)
├── Exo layer: Nostr event (kind-30078)
│ ├── MLS encryption (group key)
│ ├── Relay routing (WebSocket)
│ ├── Identity (npub signature)
│ └── Media (encrypted attachments)
│
└── Endo layer: Coordination payload
├── Type (submission, review, governance, etc.)
├── Dependencies (parent TXXM refs)
├── State transition (braid +1)
├── Namespace (KOR scope)
└── Execution (KScript, if applicable)
The TXXM is NOT “wrapped in” Nostr. It IS a Nostr event that carries coordination semantics. The protocols are fused at the envelope level — you cannot separate them without destroying both.
Hyper-Protocolization
“Hyper-protocolization” means every single interaction is multi-protocol by nature. Not layering. Not wrapping. Fusion.
Example: Operator Submits Governance Proposal
1. Operator composes proposal (endo: governance TXXM)
2. TXXM is serialized (endo: KAP-003 canonical encoding)
3. TXXM is signed (exo: npub signature)
4. TXXM is encrypted (exo: MLS group key for governance room)
5. TXXM is published (exo: Nostr relay)
6. Relay propagates (exo: WebSocket to all subscribers)
7. Members receive (exo: MLS decryption)
8. Members validate (endo: TXXM validation rules)
9. Members vote (endo: governance TXXM in response)
10. Votes converge (endo: braid ordering)
11. Proposal passes/fails (endo: governance logic)
12. State updates (endo: state tree transition)
13. Knot checkpoint (endo: braid → knot crystallization)
14. Optional anchoring (endo → Bitcoin: OP_RETURN commitment)
Every step is simultaneously endo AND exo. The operator doesn’t think “now I’m using endo” then “now I’m using exo.” It’s one fused interaction.
Double Paradigm
The “double paradigm” is that Kapnet operates in two modes simultaneously:
Mode 1: Coordination (Endo)
- TXXM submission → braid → knot → state
- Deterministic, consensus-bearing
- Settlement-relevant (Bitcoin-anchored)
- Machine-readable (canonical binary)
Mode 2: Communication (Exo)
- Encrypted message → relay → subscribers
- Social, human-readable
- Censorship-resistant
- Media-rich (files, images, video)
The same TXXM is BOTH a coordination act AND a communication. The double paradigm is not two separate systems — it’s one system viewed from two angles.
Implementation: Fused Protocol Stack
LAYER 7: APPLICATION
├── Kapnet rooms (governance, markets, research)
├── Kapnet documents (Sheet TXXM = collaborative editing)
└── Kapnet agents (souls, workers, validators)
LAYER 6: COORDINATION (Endo)
├── TXXM envelope (KAP-010)
├── Braid ordering (KAP-050)
├── Knot checkpointing (KAP-051)
├── State commitment (KAP-052)
└── KScript execution (KAP-060)
LAYER 5: ENCRYPTION (Exo)
├── MLS group keys (Marmot protocol)
├── Forward secrecy (post-compromise security)
└── External signers (Amber, NIP-55)
LAYER 4: TRANSPORT (Exo)
├── Nostr events (kind-30078 for TXXM)
├── Relay routing (WebSocket)
└── Media sharing (encrypted attachments)
LAYER 3: IDENTITY (Both)
├── Keypair (npub/nsec)
├── KOR namespace (scope + governance)
└── Auth levels (AUTH-0 through AUTH-7)
LAYER 2: SETTLEMENT (Endo → Bitcoin)
├── OP_RETURN anchoring (KAP-140)
├── CoinJoin privacy (Whirlpool)
└── Lightning payments (lnd)
LAYER 1: BASE (Bitcoin)
├── Proof-of-work consensus
├── UTXO model
└── Block space (scarce settlement resource)
The Endo-Exo Feedback Loop
Endo and exo are not independent — they feed each other:
ENDO → EXO:
State changes trigger notifications (TXXM → Nostr event)
Governance decisions update room policies (state → MLS group)
Knot checkpoints anchor to Bitcoin (endo → Bitcoin → exo visibility)
EXO → ENDO:
Incoming messages become TXXM submissions (Nostr → braid)
Group membership changes update KOR scope (MLS → state tree)
Media attachments become blob TXXM (files → braid)
The feedback loop is continuous. Endo state changes propagate via exo. Exo messages trigger endo state changes. The system is alive — constantly cycling between coordination and communication.
Key Design Principles
- Fusion, not layering: TXXM IS a Nostr event. Not “wrapped in” — IS.
- Deterministic endo: Same inputs → same outputs. Always.
- Encrypted exo: All transport is MLS-encrypted. No plaintext.
- Namespace-scoped: KOR isolation with controlled cross-namespace flow.
- Settlement-anchored: Endo state can anchor to Bitcoin. Exo cannot.
- Identity-unified: npub = endo identity = exo identity. One keypair.
- Media-native: Files are first-class TXXM payloads, not afterthoughts.
- Agent-compatible: Souls operate at the endo level. Humans at the exo level. Both use the same TXXMs.
Write a comment