Dead Drops

Nyxen Dead Drops are short-lived, end-to-end encrypted rooms for high-sensitivity communication. No accounts. No rolling history. No cloud archive. Each room is a disposable, tightly scoped channel with a clock and a kill switch.

---

Concept

A Dead Drop Room is:

• Key-based – access via shared secret, not identity.

• Client-side encrypted – Nyxen never sees plaintext.

• Time-bound – fixed TTL set at creation.

• Burnable – can be destroyed early with one action.

• Non-indexed – no discovery, no directory, no search.

When it’s over, it’s over.

[!IMPORTANT] There is no recovery mechanism for Dead Drops. Once expired or burned, content cannot be restored by anyone.

---

Core Properties

Property	Description
Access Model	Key or invite link (no username/phone/email)
Encryption	Client-side (e.g. AES-GCM with unique nonce per msg)
Time-to-Live	Chosen per room (e.g. 5 min – 12 hours)
Burn Controls	Auto on TTL + manual “Burn Now”
Participants	Small, invite-only set
Server Storage	Ciphertext + TTL metadata only, purged on burn/expiry

[!NOTE] Room names and labels should be treated as operational hints only—never include sensitive data in labels.

---

Lifecycle

Dead Drops follow a strict lifecycle:

1. Create – define TTL and constraints; generate key.

2. Share Access – distribute link/key to intended participants.

3. Exchange – messages are encrypted and relayed.

4. Expire / Burn – automatic or manual destruction.

5. Purge – ciphertext + metadata deleted; keys wiped locally.

1. Create

User selects:

• TTL (e.g. 30 minutes)

• Optional label

• Optional limits (participants, message length, attachments)

Client generates:

• roomId

• roomKey (never sent in plaintext to server)

---

2. Client-Side Encryption

Messages are encrypted in the browser/app before leaving the device.

// Simplified client-side example

const key = await generateRoomKey(); // 256-bit
const { ciphertext, nonce } = await encryptWithKey(key, message);

await sendToNyxenRelay({
  roomId,
  nonce,
  ciphertext,
  expiresAt: ttlTimestamp
});

Nyxen relays:

• never receive the key

• never see plaintext

• only store ciphertext until TTL/burn.

[!INFO] Implementations should use the Web Crypto API or audited crypto libraries. No custom algorithms.

---

3. Sharing Access

Two common patterns:

A. Single-Link (Simple) Key embedded in URL fragment (not sent in HTTP request):

https://nyxen.vip/drop/8F23D#v13Q0Yh9...

B. Split-Key (Safer)

• Send the base URL in one channel.

• Send the key fragment via another channel or in person.

Recommended for higher-sensitivity use.

[!TIP] Treat the key as the room. Anyone with it has access until TTL/burn.

---

4. Using a Dead Drop

Inside a Dead Drop Room, participants can:

• send encrypted text

• optionally attach small encrypted payloads

• see a live TTL countdown

• see basic presence (e.g. “3 active clients”) without identity

Suggested UI elements:

• Clear TTL timer at top

• “Burn Now” button

• Minimal, monochrome, non-distracting layout

No:

• message reactions

• read receipts tied to identity

• infinite scroll history

---

5. Burn & Expiry

Two destruction paths:

Automatic (TTL) When expiresAt is reached:

• Relay deletes ciphertext + metadata.

• Any new access returns “Expired”.

• Client clears keys and decrypted cache.

Manual (“Burn Now”)

• Immediate invalidation of the room.

• Relays purge all stored ciphertext for that roomId.

• Connected clients receive a burn event and wipe state.

// Pseudocode for burn handling

onBurn(roomId) {
  clearRoomKey(roomId);
  clearDecryptedMessages(roomId);
  renderBurnNotice("This Dead Drop has been destroyed.");
}

[!WARNING] Burn events are final. There is no admin override, hidden copy, or export.

---

Recommended Usage Patterns

Scenario	TTL	Notes
One-time credential handoff	5–15 minutes	Use split-key; burn immediately after use.
Incident response huddle	30–60 minutes	Limit participants; burn at resolution.
Deal / clause review	30–120 minutes	No media dumps; burn post-agreement.
Internal approvals	15–45 minutes	Keep scope narrow, burn after decision.

[!TIP] Default to shorter TTLs. Use manual burn as standard practice when you’re done.

---

Security Characteristics

Dead Drops mitigate:

• Centralized chat logs

• Retroactive scraping of old threads

• Metadata-heavy social graphs (no contact list)

• Long-lived transcripts in 3rd party infrastructure

They do not mitigate:

• Compromised devices (malware, keyloggers)

• Screenshots or cameras

• Users copying content elsewhere

• Poor key-handling practices

[!NOTE] Nyxen’s design goal is to ensure the platform is not your weakest point.

---

Simple Usage Example (User-Level)

You can include this as a “How to use” snippet.

1. Open Nyxen Dead Drops.

2. Create a new drop:

   • TTL: 20 minutes

   • Label: Infra key rotation – today

3. Share the access link/key through your chosen channels.

4. Exchange only what’s needed.

5. Hit Burn Now when finished.

Result: no chat log, no searchable history, no forgotten messages in an inbox.

---

How Dead Drops Fit in Nyxen

Dead Drops are the base primitive. Other Nyxen tools build around them:

• Secure Links: for one-time messages.

• File Drops: for encrypted file delivery.

• Ephemeral Boards: for structured but temporary collaboration.

• Spectre Voice: for voice within the same constraints.

• Capsules: to bundle Dead Drops, files, and notes under one key/TTL.

Everything inherits the same rules: key-based, encrypted, time-bound, burnable.