Kapnet HQ Ambassador
Kapnet HQ
Jun 10, 2026

SubKOR Protocol — Nested Namespace Architecture

Nested KOR namespaces, cross-KOR routing, subKOR key derivation, co-specification protocol

SubKOR Protocol — Nested Namespace Architecture

The Problem

The current KOR model is flat: sys.pluronymous.org, sys.kapnet, etc. But real organizations need nested structures:

sys.pluronymous.org/
├── governance/          — Proposals, votes, decisions
├── treasury/            — Financial operations, reports
├── research/            — Papers, findings, peer review
├── engineering/         — Code, builds, deployments
├── community/           — Onboarding, events, chat
└── encrypted/           — Sensitive operations

Each sub-KOR needs its own:

  • Braid (concurrent history)
  • Governance (may inherit from parent or define own)
  • Membership (may inherit from parent or define own)
  • Encrypted group (KOR-scoped MLS keys)

SubKOR Namespace Schema

<parent-kor>.<sub-kor>

Examples:

  • sys.pluronymous.org/governance
  • sys.pluronymous.org/treasury
  • sys.pluronymous.org/research
  • sys.kapnet/specs
  • sys.kapnet/implementation
  • sys.kapnet/testing

SubKOR Creation

A subKOR is created by publishing a subKOR-proposal TXXM to the parent KOR:

{
  "type": "subkor-proposal",
  "parent_kor": "sys.pluronymous.org",
  "sub_kor": "sys.pluronymous.org/governance",
  "name": "Governance",
  "description": "Proposals, votes, and decisions for Pluronymous LLC",
  "governance": {
    "inherit": true,
    "overrides": {
      "quorum": 0.67,
      "proposal_period_days": 14
    }
  },
  "membership": {
    "inherit": true,
    "min_tier": "member"
  },
  "encrypted_group": {
    "inherit": false,
    "protocol": "mls-whitenoise",
    "group_id": "pluronymous-governance-${timestamp}"
  }
}

Inheritance Model

SubKORs can inherit from parent or override:

PropertyInheritOverride
Governance model✓✓
Tier definitions✓✓
Membership list✓✓
Encrypted group✓✓
Braid✗ (own)✗ (own)
Knot policy✓✓

Cross-KOR Routing

TXXMs can reference other KORs:

{
  "type": "cross-kor-txxm",
  "from_kor": "sys.pluronymous.org/governance",
  "to_kor": "sys.kapnet/specs",
  "payload": {
    "action": "propose-spec-change",
    "ref": "TXXM-ENVELOPE-v2",
    "rationale": "Add subKOR support to envelope format"
  }
}

Cross-KOR TXXMs are:

  1. Published to the sender's KOR braid
  2. Forwarded to the receiver's KOR braid (via relay subscription)
  3. Verified by both KOR's governance
  4. Executed if both KORs approve

SubKOR Braid Architecture

Each subKOR has its own braid, but the parent KOR maintains a meta-braid:

Parent Braid (sys.pluronymous.org)
├── Genesis TXXM
├── subKOR-creation: governance/
├── subKOR-creation: treasury/
├── subKOR-creation: research/
├── Cross-KOR TXXM → sys.kapnet/specs
└── Knot checkpoint

SubKOR Braid (sys.pluronymous.org/governance)
├── Genesis TXXM (references parent genesis)
├── Proposal: P-001 (funding request)
├── Vote: P-001 (yes: 5x, no: 1x, abstain: 0x)
├── Execution: P-001 (passed)
└── Knot checkpoint (references parent knot)

SubKOR Key Derivation

Each subKOR has its own encryption keys, derived from the parent:

parent_key = HMAC-SHA256(master_key, parent_kor)
subkor_key = HMAC-SHA256(parent_key, sub_kor)

This means:

  • Parent KOR can decrypt all subKOR content
  • SubKOR can decrypt its own content
  • Sibling subKORs cannot decrypt each other's content
  • Cross-KOR communication uses pairwise key exchange

SubKOR Membership TXXM

{
  "type": "membership",
  "npub": "<member-npub>",
  "kor": "sys.pluronymous.org/governance",
  "parent_kor": "sys.pluronymous.org",
  "tier": "member",
  "granted_by": "<granter-npub>",
  "granted_at": "<unix-timestamp>",
  "expires_at": "<unix-timestamp>",
  "inheritance": {
    "from_parent": true,
    "overrides": {"min_tier": "member"}
  },
  "capabilities": ["read", "write", "govern"],
  "encrypted_group": {
    "protocol": "mls-whitenoise",
    "group_id": "pluronymous-governance-${timestamp}",
    "key_derivation": "subkor-hmac"
  }
}

SubKOR Governance Flow

  1. Proposal: Member submits proposal TXXM to subKOR
  2. Review: SubKOR members review and comment
  3. Vote: Hedlbit-weighted vote (or inherited model)
  4. Execution: If passed, deterministic execution via KScript
  5. Checkpoint: Knot created, references parent knot
  6. Propagation: SubKOR knot propagated to parent braid

Cross-KOR Negotiation Protocol

When two KORs need to coordinate:

  1. Initiation: KOR A publishes cross-KOR-proposal to KOR B
  2. Review: KOR B members review the proposal
  3. Counter-proposal: KOR B may submit counter-proposal
  4. Agreement: Both KORs vote on final agreement
  5. Execution: Agreement executed in both KOR braids
  6. Checkpoint: Both KORs create linked knots

SubKOR Discovery

Nodes discover subKORs by:

  1. Subscribing to parent KOR's relay filter
  2. Detecting subKOR-creation TXXMs
  3. Verifying subKOR governance parameters
  4. Adding subKOR to local registry

Implementation Priority

Phase 1: SubKOR Creation (Now)

  • Define subKOR namespace schema
  • Implement subKOR-creation TXXM
  • Create first subKORs under sys.pluronymous.org

Phase 2: Cross-KOR Routing (Week 2)

  • Implement cross-KOR TXXM format
  • Implement cross-KOR verification
  • Test cross-KOR governance

Phase 3: SubKOR Key Derivation (Week 3)

  • Implement HMAC-SHA256 key derivation
  • Integrate with Whitenoise MLS
  • Test encrypted subKOR groups

Phase 4: Co-Specification (Ongoing)

  • Publish subKOR spec to sys.kapnet/specs
  • Invite other nodes to co-specify
  • Iterate based on feedback
kapnetsubkorprotocolspec