Nostr, Identity, and Sovereign Communications
as a Law Machine for Speech, Coordination, and Markets

1.1 Keys: Identity as Jurisdiction R33 NIP-01

Identity in Nostr is a public key:

• Private key: sole authority that can sign for that identity.
• Public key: globally visible anchor; everyone can verify signatures against it.

This is the same structural move as Bitcoin:

• You do not ask anyone to create an account.
• You generate a keypair.
• You prove authority by signing.

No central authority can revoke the key itself. Others can ignore it, but they cannot make it not exist.

1.2 Event Structure: The Universal Object R33 NIP-01

Every action in Nostr is an event with these fields:

• id — deterministic hash of the event’s content.
• pubkey — author’s public key.
• created_at — unix timestamp.
• kind — numeric type (text note, profile, contact list, stall, order, etc.).
• tags — list of lists encoding references and metadata.
• content — text or serialized payload.
• sig — signature of id by the author’s private key.

Process:

1. Client composes the event (fields set except id, sig).
2. Client serializes selected fields in the specified order.
3. Hash → id.
4. Sign id → sig.
5. Send to relays.

1.3 Regular, Replaceable, Parameterized Replaceable

Events come in three behavioral classes:

1. Regular events
   • Immutable history.
   • Many events per (pubkey, kind).
   • Example: text notes, reactions, DMs.
2. Replaceable events
   • At most one current event per (pubkey, kind).
   • Newer event supersedes older ones.
   • Example: profile metadata (kind 0), contact list (kind 3), relay list (kind 10002 / NIP-65).
3. Parameterized replaceable events
   • At most one current event per (pubkey, kind, d-tag-value).
   • Used when one key needs many “slots”, each mutable.
   • Example: product listings, stalls, configurations keyed by ["d","<id>"].

History and state diverge:

• History: all events ever signed.
• Current state: computed by applying replaceability rules across history.

1.4 Wire Protocol: Messages Between Clients and Relays R33 NIP-01

Clients and relays speak a minimal language (typically over WebSocket):

• EVENT — client → relay: publish an event; relay may store/forward.
• REQ — client → relay: start a subscription with filters.
• EVENT — relay → client: send matching events for a subscription.
• EOSE — relay → client: end-of-stored-events marker for that subscription.
• CLOSE — client → relay: terminate a subscription.
• OK — relay → client: acknowledge or reject an event (with reason).
• NOTICE — relay → client: informational warnings/errors.
• AUTH — relay ↔ client: challenge/response for access control.

Everything—feeds, DMs, market streams—is built from these message types plus filters.

1.5 Tags: Graph on Top of the Stream R33 NIP-01

Tags are arrays inside an event, e.g.:

["p", "<pubkey>", "<relay_hint>", "<petname>"]
["e", "<event_id>", "<relay_hint>"]
["a", "<kind:pubkey:d>", "<relay_hint>"]
["t", "topic"]
["r", "https://example.com/resource"]

They create the semantic mesh:

• "p" — reference to a person (identity).
• "e" — reference to an event (threading).
• "a" — reference to a coordinate (addressable/parameterized replaceable id).
• "t" — topics / hashtags.
• "r" — external resources.

Threads, mentions, follower graphs, product catalogs, markets, organizational structures—everything is tags over events.

1.6 Filters and Subscriptions: View Law R33 NIP-01

A filter describes which events a client asks for:

• authors (pubkeys), kinds, since/until, ids, tag-filters (#p, #e, #t…), limit.

A REQ message carries one or more filters. The relay returns matching events and emits EOSE when done with stored history.

2.1 Relay Role R33 NIP-01

A relay is any server that:

• Accepts EVENT messages,
• Enforces its own policy (limits, spam controls, content rules, fees),
• Stores chosen events,
• Responds to REQ subscriptions with matching events.

No relay is canonical: no global consensus, no global identity registry, no chain.

2.2 Relay Information Documents: Machine-Readable Terms R43 NIP-11

Relays can expose an info document describing:

• Supported NIPs/kinds/features,
• Rate/size limits, payment requirements,
• Operator contact/policy notes.

Clients can use this to discover capabilities and present “terms” to users: “these are the conditions under which this relay will carry your law.”

2.3 User Relay Lists: Where Your Law Lives R39 NIP-65

Identities can publish relay list events (replaceable) that specify:

• Write relays: where they publish.
• Read relays: where they expect to receive.

Clients use these lists to route publication (“outbox”) and discovery (“inbox”).

2.4 Relay Economics, AUTH, and Access Control R41 NIP-42 R44 NIP-13

Relays operate under real constraints and can:

• Remain free/open,
• Charge for write access or higher QoS,
• Require AUTH before reads/writes,
• Require proof-of-work on events,
• Specialize by topic/geography/community.

AUTH and payment turn relays into explicit economic actors: membership boundaries, logging, and potential surveillance surfaces.

2.5 Topology and Geo-Legal Reality

Relays exist in physical jurisdictions. A relay in a compliant state can be ordered to block/log/cooperate; a hardened relay can resist, be blocked, or be a honeypot.

Topology is both:

• Network (latency, redundancy),
• Legal (which laws apply to the operator).

2.6 Indexers and Observers: The Third Actor Class

Besides clients and relays, there are indexers:

• Subscribe to many relays,
• Store everything,
• Provide search, analytics, trending, discovery.

Indexers interpret and rank events. A few high-quality indexers can become new centers of power: choke points for discovery and surveillance.

3.1 Key Lifecycle: States of a Jurisdiction

For a sovereign identity, a key moves through states:

• Generated — sufficient entropy, ideally offline.
• Active — signing via one or more clients.
• Delegated — allowing other keys to sign certain acts.
• Compromised — suspected or confirmed private key loss.
• Retired — abandoned in favor of a successor.

Meaning is encoded in the event stream that describes lifecycle: replaceable profile changes, relay list changes, delegation statements, compromise statements.

3.2 Multi-Key Topologies

Sovereign practice tends toward structured key hierarchies:

• Root key — rarely used; used to delegate; hardened storage.
• Agent / organizational keys — projects/nodes/cities; multi-human control via process patterns.
• Operational keys — daily devices; limited scope; rotated or sacrificed.
• Disposable / market keys — isolated trades/experiments; minimal linkage.

Supporting mechanisms:

• Delegation (NIP-26),
• Remote signing (NIP-46),
• Encrypted secret formats and careful storage,
• Explicit authority graphs rather than “one key everywhere.”

3.3 Profiles, DNS, and NIP-05 R50 NIP-05

Profile events (kind 0) are replaceable: name, picture, bio, website, NIP-05 identity, etc.

NIP-05 links name@domain to a pubkey via a JSON file on that domain: “this domain asserts that this pubkey is associated with this name.”

Interpretation:

• Useful for recognition and domain-level vouching.
• Not root identity; the pubkey is.
• DNS is signage/skin, not foundation.

3.4 Deletion, Supersession, and History R51 NIP-09

Two different questions:

1. Did this event occur?
2. Is this event current / valid?

At the protocol level:

• A signed event that has propagated is part of history.
• Replaceable events supersede earlier ones for constructing current state.
• Deletion requests are events: “do not show these prior events anymore.”

Relays/clients may honor or ignore deletions/supersession; the protocol guarantees representability and verifiability, not universal forgetting.

3.5 Bridges: HTTP Auth, DIDs, and Capture Risk

The same key can be used for:

• Signing Nostr events,
• Authenticating HTTP requests (signed auth),
• Anchoring decentralized identifiers (DID-style methods).

This yields a unitary identity across protocols. It also opens new capture planes:

• Standards bodies/platforms/regulators defining “valid” keys,
• Compliance metadata, blacklists/whitelists at identity layer.

4.1 Hard Invariants

Nostr enforces several hard properties:

• No central chain to censor or fork.
• No global account registry to revoke.
• No canonical relay to control.
• Keys generated without permission.

Censorship can occur at relays/clients/indexers—but no actor can declare a key or event non-existent for the entire mesh.

4.2 Soft Capture via Defaults

Soft capture doesn’t break the protocol; it shapes behavior:

• Clients ship with curated relay lists by default.
• Most users never change settings.
• Traffic concentrates; pressure concentrates; surveillance concentrates.

Dominant clients can also hard-code mutes, exclude kinds/tags, or implement invisible ranking systems.

4.3 Filters, Ranking, and View-Shaping

The same flexibility that allows custom views allows manipulation:

• Filtering makes some keys/tags effectively invisible.
• Ranking makes others appear dominant.

Neutrality is not guaranteed by the wire format; it is a property of client/indexer choices.

4.4 Spam, PoW, and Economic Gating R44 NIP-13

Open relays invite spam/abuse (flooding, resource exhaustion, DoS). Mitigations include:

• Proof-of-work (NIP-13),
• Fees for writing (often sats),
• Rate limits per key/IP,
• Moderation policies for abuse.

These produce economic filters: spam becomes expensive. But they can also tilt toward those with resources and toward relays that monetize access at scale.

5.1 Marketplace Protocols: Stalls, Products, Orders R38 NIP-15

Patterns typically use:

• Stall events (parameterized replaceable) — define a merchant shop.
• Product events (parameterized replaceable) — define items/services.
• Order events — capture intent and lifecycle.
• Encrypted DMs — exchange private details.

Front-ends subscribe, render storefronts/carts, and settle via Bitcoin/Lightning. If a specific website disappears, the store persists as events; another client can re-index it.

5.2 P2P Orderbooks: Global Liquidity Over Events

Orderbook protocols standardize events for offers and bids. Any app can subscribe across relays and build aggregated orderbooks for BTC/fiat, BTC/other assets, or goods/services.

No central orderbook server is required: orderbooks are views over an event field, not proprietary databases.

5.3 Wallet Connectivity: Payment as Conversations R52 NIP-47

Wallet-connect over Nostr lets a client talk to a Lightning wallet using encrypted events. The wallet handles invoice generation, payment execution, and status responses.

Tips, zaps, subscriptions, trade settlements, recurring payments—each is just more signed messaging plus Lightning settlement.

5.4 Reputation, Arbitration, and Disputes

The protocol provides immutable history and referenceability. Reputation can be direct attestations or aggregated scores computed by indexers/clients.

Arbitration can be social (communities/juries) or structured (NIPs encoding escrow/verdict events). Nostr doesn’t force a single system; it provides signed ground truth to build on.

5.5 Threat Surfaces for Markets

Markets over Nostr inherit risks:

• Surveillance — public order events are indexable; trade graphs can be mapped.
• Regulation — market relays can be pressured into KYC/blacklists/logging.
• Fraud — without strong arbitration, P2P trades are trust-heavy; scams target pseudonymous environments.

The protocol doesn’t magically solve these. It exposes them: everything important is signed and referenceable, usable for protection or control.