TTL & Burn Rules

Everything inside Nyxen obeys a single law: nothing lasts forever. This section defines exactly how Time-to-Live (TTL) and burn mechanics work — the heartbeat of Nyxen’s privacy guarantees.

---

1. The Core Principle

Every object in Nyxen — whether a message, board, voice call, or capsule — is born with an expiration. When that time arrives, it’s not hidden, archived, or soft-deleted. It’s erased.

[!NOTE] TTL and burn events are not symbolic. They trigger literal data destruction — client-side key wipes and server-side purges.

---

2. TTL Definitions

Level	Applies To	Typical Range	Behavior
Primitive TTL	Single object (message, file, board)	5 min – 4 hr	Controls the life of one encrypted entity.
Context TTL	Dead Drop Room / Board / Voice	15 min – 6 hr	Ends the whole session and everything within it.
Capsule TTL	Composite container of multiple primitives	30 min – 12 hr	Overrides all subordinate TTLs; nothing may outlive the capsule.

---

3. TTL Enforcement

Nyxen enforces expiry in three layers:

1. Client Layer – timers purge local keys and cached ciphertext.

2. Relay Layer – scheduled task deletes ciphertext and metadata at expires_at.

3. UI Layer – instantly reflects state change (“expired” or “burned”).

Example (simplified):

if (Date.now() >= expiresAt) {
  delete(ciphertext);
  clearKey();
  renderNotice("Expired — this object no longer exists.");
}

---

4. Burn Events

A burn is a deliberate, user-initiated destruction event.

It is:

• irreversible,

• immediate,

• cascaded to all linked objects.

Manual Burn Flow

[ User Clicks "Burn" ]
      ↓
Client wipes keys + local data
      ↓
Relay receives burn flag → purges ciphertext
      ↓
Other peers notified → auto-wipe

Burn events propagate through the capsule hierarchy.

[!WARNING] A burn cannot be undone, reversed, or queried after execution.

---

5. Automatic Burn Conditions

In addition to manual triggers, Nyxen may auto-burn when:

Condition	Result
TTL reached	Object expires and is purged.
Parent context burned	All child entities instantly deleted.
Network violation (e.g. signature mismatch)	Auto-burn object to prevent replay.
User revokes key locally	Peers lose ability to decrypt; Nyxen purges remaining ciphertext.

---

6. Cascading Logic

Each primitive inherits the life of its parent.

Capsule
 ├── Dead Drop (inherits Capsule TTL)
 ├── Ephemeral Board (inherits Capsule TTL)
 ├── File Drop (inherits Capsule TTL)
 └── Spectre Voice (inherits Capsule TTL)

If Capsule burns → all children burn. If one child burns → siblings remain unless cascade is explicit.

---

7. Burn Signaling Protocol

All Nyxen clients recognize a standardized “burn” signal:

{
  "context_id": "C-IR492",
  "burn": true,
  "timestamp": "2025-11-11T22:00:00Z"
}

Relay behavior: delete ciphertext + expiry records → broadcast burn event → clear caches.

Client behavior:

onBurn(contextId) {
  clearLocalData(contextId);
  revokeKeys(contextId);
  showNotice("This Nyxen context has been burned.");
}

---

8. Visible Burn States

State	Meaning	UI Cue
Active	Within TTL	Normal interface
Expiring Soon	< 5 min remaining	Countdown + subtle glow
Expired	TTL passed	Locked / greyed out
Burned	Manual or cascade burn	Blackout screen + burn notice

[!TIP] The “Burned” visual deliberately interrupts workflow — you should feel the cutoff.

---

9. Recommended TTL Settings

Use Case	Recommended TTL	Rationale
Quick coordination	15–30 min	Forces brevity; no clutter
Incident response	60–120 min	Enough to conclude without persistence
Deal review	30–90 min	Adequate for context, still ephemeral
Voice sessions	≤ 45 min	Matches human attention + reduces leak window
File drops	10–30 min	Keep delivery narrow and disposable

---

10. Security Rationale

TTL + Burn = anti-forensics by architecture.

Benefits:

• Eliminates long-term server compromise value

• Removes retroactive discovery exposure

• Discourages over-retention habits

• Simplifies compliance with “right-to-forget” expectations

Limitations:

• No recovery if TTL or burn misconfigured

• Endpoint logs and screenshots remain user risks

• Requires operational discipline

[!NOTE] Nyxen enforces irreversibility to align with its philosophy: privacy through disappearance, not permission.

---

11. Visual Flow Diagram

[Create Object]
     ↓ (TTL timer starts)
[Active State]
     ↓ after TTL or Burn
[Client Key Wipe] → [Relay Purge] → [Object Non-existent]

---

Nyxen’s destruction model is not a feature — it is the core of its ethics. Data dies on schedule or on command, every time.