NIPs by PolleramaCommunity NIPs, surfaced by trustConnect
npub19jghhl87fum...

ThroatStr NIP — Stegotext Channels

Published Jul 9, 2026

ThroatStr NIP — Stegotext Channels

Kind 38689 — Stego Receiver Profile (Addressable)

Published by the recipient (journalist/redaction) to advertise acceptance of anonymous submissions.

Event Structure

{
  "kind": 38689,
  "content": "<human-readable instructions for sources>",
  "tags": [
    ["d", "<profile-id>"],
    ["stego-suite", "mec-v1/llmspec-<hash>"],
    ["wrap", "nip59"],
    ["enc", "nip44-v2"],
    ["recv-key", "<dedicated submission pubkey hex>"],
    ["relay", "wss://relay1.example.com"],
    ["relay", "wss://relay2.example.com"],
    ["carrier", "text"],
    ["alt", "Stego receiver profile for anonymous source submissions"]
  ],
  "pubkey": "<recipient's main identity pubkey>"
}

Tag Definitions

TagRequiredDescription
dyesUnique profile identifier (allows multiple receiver profiles per pubkey)
stego-suitenoCodec + model contract identifier (Phase 2)
wrapyesWrapping protocol: nip59 (gift wrap mandatory)
encyesEncryption protocol: nip44-v2
recv-keyyesDedicated submission pubkey (MUST differ from identity key)
relaynoSuggested ingest relay URLs (repeatable)
carriernoAllowed carrier types: text, file
altyesNIP-31 human-readable description

Protocol Invariants

  1. recv-key MUST be a different keypair from the recipient's identity key
  2. Gift wrap (NIP-59) is always mandatory for submissions
  3. Carriers (kind:1 notes) MUST NOT carry app-specific tags or markers
  4. Encryption (NIP-44) is always applied before any steganographic encoding

Submission Protocol (Phase 1 — Gift Wrap Channel)

Sources submit via NIP-59 Gift Wrap (kind:1059) addressed to the recv-key:

  1. Source composes message
  2. Message is encrypted with NIP-44 using an ephemeral key → recv-key
  3. Encrypted message is wrapped in a NIP-59 gift wrap (kind:13 seal + kind:1059 wrap)
  4. Gift wrap is published to large public relays
  5. Ephemeral key is destroyed — source retains no evidence

Receiver Decryption

  1. Receiver monitors for kind:1059 events addressed to their recv-key
  2. Decrypts outer wrap with recv-key private key
  3. Decrypts inner seal to retrieve the rumor (unsigned event)
  4. Displays message content securely

Security Properties

  • Metadata protection: Gift wrap hides sender, receiver, kind, and timestamp
  • Forward deniability: Unsigned rumor cannot be authenticated if leaked
  • No sender persistence: Ephemeral keys are destroyed after sending
  • Key separation: Compromise of recv-key does not compromise identity

Phase 2 — Steganographic Channel (Ebene A/B)

Steganographic Encoding

The stego codec implements Perfectly-Secure Steganography via arithmetic coding over autoregressive LLM token probability distributions (based on Schroeder de Witt et al., "Perfectly Secure Steganography Using Minimum Entropy Coupling", ICLR 2023).

Security guarantee: When the payload is uniformly distributed (encrypted), the carrier text is distributionally identical to normal model output. No statistical test can distinguish stego output from real model output.

Stego Pipeline (Encoder)

plaintext → NIP-44 encrypt → high-entropy bytes → arithmetic coding over
model distributions → carrier text → publish as kind:1 from ephemeral key

Stego Pipeline (Decoder / Trial-Decode)

candidate kind:1 notes → tokenize → arithmetic decode using same model →
candidate bytes → NIP-44 decrypt attempt → if MAC valid: message found

stego-suite Tag Format

["stego-suite", "mec-v1/<config-hash>"]

Where <config-hash> is the SHA-256 of the canonical model configuration:

{
  "modelId": "gpt-4o-mini",
  "endpoint": "https://api.openai.com/v1/chat/completions",
  "temperature": 1.0,
  "topP": 1.0,
  "topK": 20,
  "maxTokens": 512
}

Both sender and receiver MUST share the exact same config hash. A mismatch causes silent decode failure (security property: no information leaks about whether something IS a stegogram).

Carrier Events

Steganographic carriers are published as normal kind:1 text notes with:

  • NO app-specific tags
  • NO markers or distinguishing content patterns
  • Ephemeral throwaway pubkey as author
  • Jittered timestamp (±2 hours)

Future Phases

  • Phase 3: Transport adapters (relay strategy, bitchat)
  • Phase 4: OpSec layer (amnesic mode, key rotation, panic functions)