Signals & Ghost Codes

Nyxen Signals & Ghost Codes are ultra-minimal, time-critical notifications designed to leave almost nothing behind.

They are not chats. They are not feeds. They are small, encrypted events with seconds-level TTL, used to coordinate without generating story or transcript.

Concept

Nyxen provides two complementary primitives:

  1. Signals Short, encrypted alerts like:

    • “online now”

    • “call ready”

    • “drop consumed”

    • “rotate keys”

  2. Ghost Codes Pre-agreed coded messages where:

    • the meaning is known only to your team,

    • Nyxen only sees an opaque code identifier,

    • TTL is extremely short (e.g. 5–60 seconds).

These are designed for:

  • teams that already have protocols

  • incident response workflows

  • “go/no-go” scenarios

  • coordination around Dead Drops, Boards, Capsules, Spectre Voice

[!IMPORTANT] Signals and Ghost Codes are built to not create a timeline. They are ephemeral hints, not logs.

Core Properties

Primitive
Description

Signals

Direct, human-readable alerts with short TTL

Ghost Codes

Obfuscated code IDs mapped to private meanings

TTL

Seconds to a few minutes (enforced, no extension)

Delivery

Client-side encrypted events

History

No persistent list beyond the live window

Identity

No long-term identities; optionally pseudonymous tags

Nyxen Signals

Concept

Signals are tiny, encrypted events like:

  • “Ready”

  • “Delay 5”

  • “On route”

  • “Burn now”

  • “Check Dead Drop”

  • “Spectre in 2”

They answer “what now?” without opening a conversation.

Behavior

  • Created from within:

    • a Dead Drop,

    • an Ephemeral Board,

    • a Capsule,

    • or a dedicated Signals panel.

  • Encrypted client-side.

  • Broadcast to authorized participants.

  • Visible for a few seconds → then removed for everyone.

Property
Value/Behavior

Payload

tiny: type + optional small param

TTL

typically 5–60 seconds

Storage

in-memory + relay buffer until expiry

After TTL

removed; not queryable, not listed, no audit log

[!NOTE] Signals are intentionally blunt. If you need prose, use a Dead Drop. If you need logs, Nyxen is the wrong tool.

Example UI

  • Inside a room/board:

    • Small “Signals” row: [READY] [DELAY] [ON] [BURN]

    • Click sends encrypted event.

    • Brief toast-style indicator for recipients: Signal: READY then fades.

Ghost Codes

Ghost Codes are Signals with an extra layer of deniability and discipline.

Concept

  • Each team defines its own internal codebook locally:

    • 101 → “All clear”

    • 304 → “Delay 5”

    • 909 → “Escalate / abort”

    • 777 → “Switch to Spectre Voice”

  • Nyxen only ever sees:

    • encrypted payload containing code_id

    • routing and TTL metadata

Nyxen does not know what 101 means.

[!INFO] The mapping from code_id → meaning lives in the client or your team’s operational playbook, not on Nyxen’s servers.

Core Properties

Property
Description

Code IDs

Small integers/strings (e.g. 101, 909, SIG-A)

Meaning Storage

Local-only; never uploaded in plaintext

TTL

very short (e.g. 5–30 seconds)

Display

Compact, inline; no scrollable backlog

Flow

  1. Team configures Ghost Codes locally in their Nyxen client:

    • Add code_id

    • Add local label/meaning

  2. During operations:

    • User selects a Ghost Code to send

  3. Nyxen relays:

    • encrypted code_id event to connected peers

  4. Each client:

    • decrypts

    • maps code_id → local meaning

    • displays ephemeral notice (e.g. “Code 304: Delay 5”)

  5. After TTL:

    • event disappears for all users

// Pseudocode (client-side mapping)

const codebook = {
  "101": "All clear",
  "304": "Delay 5",
  "909": "Escalate / Abort"
};

function handleGhostCodeEvent(event) {
  const { code_id } = decrypt(event);
  const meaning = codebook[code_id] || "Unknown code";
  showEphemeralNotice(`Code ${code_id}: ${meaning}`, { ttlMs: 8000 });
}

Nyxen servers never see meaning, only the encrypted code_id.

Usage Patterns

Signals

Use Nyxen Signals when:

  • you operate within a Dead Drop / Board / Capsule,

  • you need to quickly indicate status without writing full messages.

Examples:

  • READY when all parties are in.

  • BURN when decision is final.

  • CHECK to prompt reading of a Secure Link or File Drop.

Ghost Codes

Use Ghost Codes when:

  • you want to minimize semantic exposure,

  • only your team should understand the intent,

  • you expect someone to see traffic patterns but not decode them.

Examples:

Code
Internal Meaning (local only)

101

All clear / proceed

202

Pause / hold

304

Delay 5 minutes

707

Rotate to new keys

808

Regroup in new Dead Drop

909

Abort / escalate as per playbook

[!TIP] Rotate your Ghost Codes and never write the full mapping into systems you do not control.

Ephemerality & Non-Logging

Both Signals and Ghost Codes are built to not create timelines.

  • No long-term feed.

  • No infinite scroll.

  • No “last 7 days of signals” view.

  • Once gone, they are gone.

Any attempt to screenshot/log them:

  • happens on the endpoint,

  • is outside Nyxen’s control,

  • should be handled by your operational policy.

[!WARNING] If your compliance or regulatory environment requires persistent logs, Nyxen Signals/Ghost Codes may not be appropriate for that channel. They are intentionally anti-log.

Integration with Other Nyxen Primitives

Signals & Ghost Codes are not standalone; they sit on top of the rest of Nyxen:

  • Inside Dead Drops:

    • “READY / BURN / DELAY” without cluttering the transcript.

  • Alongside Ephemeral Boards:

    • Code-based sync signals during an incident.

  • As part of Capsules:

    • A Capsule may include:

      • 1 Dead Drop

      • 1 Board

      • 1 File Drop

      • Ghost Codes for navigation

Conceptual Capsule:

Capsule: IR-Session-492
- Dead Drop Room
- Ephemeral Board
- 2 File Drops
- Ghost Codes: {101, 304, 909}
TTL: 60 minutes
Burn: manual or on expiry

Implementation Notes (For Builders)

  • Use the same relay and encryption pattern as other Nyxen primitives:

    • small encrypted events,

    • TTL enforced server-side,

    • keys never sent.

  • UI should:

    • show Signals/Ghost Codes briefly,

    • avoid scrolling history,

    • visually distinguish them from actual text messages.

  • Consider:

    • per-context codebooks (per Capsule, per team)

    • policy options like:

      • “Ghost Codes only in this context”

      • “Disable Signals for this drop”

Summary

Signals & Ghost Codes give Nyxen users:

  • a way to coordinate without conversation, and

  • a way to carry meaning without metadata-rich logs.

They fit the Nyxen doctrine:

minimal, encrypted, time-bound, and structurally resistant to narrative.

Next: Capsules — how Nyxen lets you bind multiple primitives (room, files, links, codes, voice) into a single, controlled operation with one key and one burn.

PreviousEphemeral Boards (Coming soon)NextCapsules

Last updated