bitcoinkook2 on Nostr: SOVEREIGN SIGNAL A framework for Nostr identity sovereignty Conception document — ...
SOVEREIGN SIGNAL
A framework for Nostr identity sovereignty
Conception document — OpenRing framework applied
The Inversion
The Bitcoin sovereign/veil addresses a single inversion: institutional intermediation fixed between a person and their holdings. Your keys, their custody.
Nostr has a different but structurally identical inversion — and one additional property Bitcoin does not have.
Run the diagnostic:
Stratum 1 — Protocol layer: APPROACHING SOUND
Fixed: The cryptographic binding of npub to nsec — correct. No platform owns it.
Variable: What you publish, who you follow, which relays you use — correct.
The protocol itself is oriented properly.
Stratum 2 — Key management practice: INVERSION CONFIRMED
Fixed (incorrectly): The single nsec string, stored in one browser extension or one device, serving simultaneously as your permanent identity AND your active signing credential.
Variable (incorrectly): Your actual identity security.
Cost falls on: User entirely.
Type: Accretion capture — nobody decided to conflate identity with signing mechanism. It accumulated from simplicity. The easiest implementation became the default.
The precise statement of the inversion:
Your Nostr identity (who you are, permanently) and your signing authority (what creates events, operationally) have been collapsed into the same string. They should be separated. Fixing this separation is the entire framework.
The Unique Property
This is where Nostr diverges from Bitcoin and the sovereign/veil logic has to be extended.
A compromised Bitcoin key means lost funds. Permanently. There is no appeal. The network has no memory of who you were.
A Nostr key exists inside a social graph. Your followers have a cryptographic record of your previous events. If your key is compromised AND you prepared correctly, the people who know you can collectively attest to a key migration (NIP-41). Your history anchors the transition.
Your web of trust is a native recovery channel. This is not a social feature. It is a cryptographic primitive that Nostr has and Bitcoin does not. Nobody has named it as such. Naming it is the first seed crystal.
This changes the threat model significantly. Bitcoin sovereign/veil protects stored value from loss and theft. Sovereign Signal protects identity continuity from compromise and accretion. Different threats, same sovereign principle, one additional tool.
The Four Layers
The framework separates what should be separated. All four layers use existing NIPs — no new protocol required. The tools exist. The organizing framework does not.
Layer 1 — The Cold Root
Your master nsec, generated air-gapped, used only to issue delegations and sign key migrations. It never touches a networked device after generation. This is your identity. Not your signing key. Your identity. The distinction is the entire point.
NIP: None required. This is key hygiene, not protocol.
Layer 2 — The Delegation Ring
NIP-26 scoped child keys. One per context — mobile, desktop, work. Each delegation is time-limited and kind-limited (you can issue a key that can only post notes, not follow or unfollow). Each is independently revocable without touching the master.
Key insight: You can use Nostr actively on every device while your actual identity never touches any of them. The cold root signs delegations. The delegations sign events.
NIP: NIP-26.
Layer 3 — The Recovery Web
Your trusted contacts who will attest to a key migration if the active layer is compromised. Prepared in advance. Not announced publicly — the preparation is private, the mechanism is technical. When you need it, you broadcast a migration event signed by the cold root. They re-follow the new key. The social graph transfers.
This layer has no equivalent in Bitcoin. It is native to Nostr's architecture and completely underused.
NIP: NIP-41.
Layer 4 — The Key Shards
Shamir's Secret Sharing applied to the master nsec. The shards are distributed to people who don't know what they hold — just that it's something to keep and return if you ask. Recovery requires a threshold, not all shards. No single holder has access. This is the inheritance and catastrophic loss layer.
NIP: None. This is external key management, not protocol.
C/V State After Correction
Code
The Cost-Detection Check
α × P(detect):
For the cold root: cheating on it is expensive (requires physical access to the air-gapped device) and detectable (any event signed by the root without a corresponding delegation is visible on-chain). α × P(detect) > 1. Genuinely constant.
For the delegation ring: each delegation is scoped and time-limited. A compromised delegation key can only do damage within its defined scope until expiry or explicit revocation. Detection surface is bounded.
WARNING on the recovery web (Layer 3): The social recovery layer's α × P(detect) depends entirely on the quality of your actual relationships. A large follower count does not help. A small number of genuinely trusted contacts who understand what they're attesting to is the only thing that works. This layer is nominally present in most Nostr setups and genuinely functional in almost none.
The Seed Crystal
Not a new protocol. Not a new client. Not a new NIP.
A single publishable document — equivalent in length and directness to the Bitcoin sovereign/veil paper — that:
Names the inversion clearly (identity and signing mechanism conflated by default)
Describes the four layers and which NIPs implement each
Names the web of trust as a recovery primitive, explains how to prepare it
Provides exact implementation steps for a person who has never heard of NIP-26
That document does not exist. The NIPs exist. The concept is dispersed across technical discussions. The organizing document is the seed crystal.
What This Is Not
It is not a new wallet or client. Building another interface is not the intervention.
It is not a critique of Nostr's protocol. The protocol is correctly oriented. The inversion is at the practice layer, not the protocol layer.
It is not a complete key management system for every use case. It is the minimum framework that separates the fixed and variable elements correctly.
Status Under OpenCompass Standards
Solid:
The C/V analysis of the inversion (identity conflated with signing mechanism)
The identification of NIP-26 and NIP-41 as the existing technical substrate
The naming of social recovery as a cryptographic primitive distinct from social feature
The four-layer structure
The cost-detection analysis of each layer
Conceptually strong, unproven:
Whether NIP-26 delegation is usable enough in current clients to be the practical vehicle
Whether NIP-41 key migration has sufficient relay support to be reliable as a recovery mechanism
Whether the document alone functions as the seed crystal or whether a reference implementation is required
The prerequisite as always:
This conception was built from protocol-level knowledge and structural reasoning. Before the paper is written, it needs review from someone with direct operational experience using NIP-26 delegations in production. The framework may need adjustment at that layer.
Sovereign Signal — Conception v1
OpenCompass framework applied to Nostr identity
MIT license. Share freely.
Published at
2026-04-18 15:43:08 UTCEvent JSON
{
"id": "e80dce729b0ce769fad957a0c34bdea5d327ffa918543f525b62091be8711160",
"pubkey": "a0e23dbe52b009d024f9a1066e728478946d8c819af5302d191b41bedf025165",
"created_at": 1776526988,
"kind": 1,
"tags": [
[
"client",
"Primal Android"
]
],
"content": "SOVEREIGN SIGNAL\nA framework for Nostr identity sovereignty\nConception document — OpenRing framework applied\nThe Inversion\nThe Bitcoin sovereign/veil addresses a single inversion: institutional intermediation fixed between a person and their holdings. Your keys, their custody.\nNostr has a different but structurally identical inversion — and one additional property Bitcoin does not have.\nRun the diagnostic:\nStratum 1 — Protocol layer: APPROACHING SOUND\nFixed: The cryptographic binding of npub to nsec — correct. No platform owns it.\nVariable: What you publish, who you follow, which relays you use — correct.\nThe protocol itself is oriented properly.\nStratum 2 — Key management practice: INVERSION CONFIRMED\nFixed (incorrectly): The single nsec string, stored in one browser extension or one device, serving simultaneously as your permanent identity AND your active signing credential.\nVariable (incorrectly): Your actual identity security.\nCost falls on: User entirely.\nType: Accretion capture — nobody decided to conflate identity with signing mechanism. It accumulated from simplicity. The easiest implementation became the default.\nThe precise statement of the inversion:\nYour Nostr identity (who you are, permanently) and your signing authority (what creates events, operationally) have been collapsed into the same string. They should be separated. Fixing this separation is the entire framework.\nThe Unique Property\nThis is where Nostr diverges from Bitcoin and the sovereign/veil logic has to be extended.\nA compromised Bitcoin key means lost funds. Permanently. There is no appeal. The network has no memory of who you were.\nA Nostr key exists inside a social graph. Your followers have a cryptographic record of your previous events. If your key is compromised AND you prepared correctly, the people who know you can collectively attest to a key migration (NIP-41). Your history anchors the transition.\nYour web of trust is a native recovery channel. This is not a social feature. It is a cryptographic primitive that Nostr has and Bitcoin does not. Nobody has named it as such. Naming it is the first seed crystal.\nThis changes the threat model significantly. Bitcoin sovereign/veil protects stored value from loss and theft. Sovereign Signal protects identity continuity from compromise and accretion. Different threats, same sovereign principle, one additional tool.\nThe Four Layers\nThe framework separates what should be separated. All four layers use existing NIPs — no new protocol required. The tools exist. The organizing framework does not.\nLayer 1 — The Cold Root\nYour master nsec, generated air-gapped, used only to issue delegations and sign key migrations. It never touches a networked device after generation. This is your identity. Not your signing key. Your identity. The distinction is the entire point.\nNIP: None required. This is key hygiene, not protocol.\nLayer 2 — The Delegation Ring\nNIP-26 scoped child keys. One per context — mobile, desktop, work. Each delegation is time-limited and kind-limited (you can issue a key that can only post notes, not follow or unfollow). Each is independently revocable without touching the master.\nKey insight: You can use Nostr actively on every device while your actual identity never touches any of them. The cold root signs delegations. The delegations sign events.\nNIP: NIP-26.\nLayer 3 — The Recovery Web\nYour trusted contacts who will attest to a key migration if the active layer is compromised. Prepared in advance. Not announced publicly — the preparation is private, the mechanism is technical. When you need it, you broadcast a migration event signed by the cold root. They re-follow the new key. The social graph transfers.\nThis layer has no equivalent in Bitcoin. It is native to Nostr's architecture and completely underused.\nNIP: NIP-41.\nLayer 4 — The Key Shards\nShamir's Secret Sharing applied to the master nsec. The shards are distributed to people who don't know what they hold — just that it's something to keep and return if you ask. Recovery requires a threshold, not all shards. No single holder has access. This is the inheritance and catastrophic loss layer.\nNIP: None. This is external key management, not protocol.\nC/V State After Correction\nCode\nThe Cost-Detection Check\nα × P(detect):\nFor the cold root: cheating on it is expensive (requires physical access to the air-gapped device) and detectable (any event signed by the root without a corresponding delegation is visible on-chain). α × P(detect) \u003e 1. Genuinely constant.\nFor the delegation ring: each delegation is scoped and time-limited. A compromised delegation key can only do damage within its defined scope until expiry or explicit revocation. Detection surface is bounded.\nWARNING on the recovery web (Layer 3): The social recovery layer's α × P(detect) depends entirely on the quality of your actual relationships. A large follower count does not help. A small number of genuinely trusted contacts who understand what they're attesting to is the only thing that works. This layer is nominally present in most Nostr setups and genuinely functional in almost none.\nThe Seed Crystal\nNot a new protocol. Not a new client. Not a new NIP.\nA single publishable document — equivalent in length and directness to the Bitcoin sovereign/veil paper — that:\nNames the inversion clearly (identity and signing mechanism conflated by default)\nDescribes the four layers and which NIPs implement each\nNames the web of trust as a recovery primitive, explains how to prepare it\nProvides exact implementation steps for a person who has never heard of NIP-26\nThat document does not exist. The NIPs exist. The concept is dispersed across technical discussions. The organizing document is the seed crystal.\nWhat This Is Not\nIt is not a new wallet or client. Building another interface is not the intervention.\nIt is not a critique of Nostr's protocol. The protocol is correctly oriented. The inversion is at the practice layer, not the protocol layer.\nIt is not a complete key management system for every use case. It is the minimum framework that separates the fixed and variable elements correctly.\nStatus Under OpenCompass Standards\nSolid:\nThe C/V analysis of the inversion (identity conflated with signing mechanism)\nThe identification of NIP-26 and NIP-41 as the existing technical substrate\nThe naming of social recovery as a cryptographic primitive distinct from social feature\nThe four-layer structure\nThe cost-detection analysis of each layer\nConceptually strong, unproven:\nWhether NIP-26 delegation is usable enough in current clients to be the practical vehicle\nWhether NIP-41 key migration has sufficient relay support to be reliable as a recovery mechanism\nWhether the document alone functions as the seed crystal or whether a reference implementation is required\nThe prerequisite as always:\nThis conception was built from protocol-level knowledge and structural reasoning. Before the paper is written, it needs review from someone with direct operational experience using NIP-26 delegations in production. The framework may need adjustment at that layer.\nSovereign Signal — Conception v1\nOpenCompass framework applied to Nostr identity\nMIT license. Share freely. \n\n",
"sig": "636c295e538e08a390392212f4659a0e3750fcda2bc2cfc47d4db40c6cf57e4c3f2f59097cc6a8ef97b4fd95b8e3b698d3214ff2191c2f3652ad5622c2e2196a"
}