File Drops

Nyxen File Drops are encrypted, time-limited file hand-offs designed to avoid permanent storage, email trails, or shared drive residue. They are built for situations where a file must move from A to B—once, briefly, and without becoming a long-term liability.

Concept

A File Drop is:

  • Client-side encrypted before upload

  • Shared via a short URL (with or without embedded key)

  • Protected by:

    • TTL (time-to-live)

    • Access limits (e.g. single-download)

  • Burned automatically after conditions are met

No accounts. No folder trees. No shared drives. Just a disposable, verifiable, encrypted file bridge.

[!IMPORTANT] Once a File Drop expires or reaches its download limit, its encrypted payload is purged and cannot be recovered.

Core Properties

Property
Description

Encryption

Client-side (e.g. AES-GCM with unique file key)

Access Model

URL + key (inline fragment or split)

TTL

Minutes to hours (configurable)

Download Limit

Single-use or small fixed number

Storage

Ciphertext only, auto-deleted on expiry/limit

Identity

No login, no email, no linked identity required

File Size

Bounded (implementation-defined, e.g. 1–100MB recommended)

[!NOTE] Nyxen is not a long-term storage layer. File Drops are intentionally constrained in size and lifetime.

Lifecycle

  1. Select File – choose the file locally.

  2. Encrypt – handled in the client before upload.

  3. Register Drop – send only ciphertext + metadata to Nyxen.

  4. Share – distribute link (and key if split).

  5. Retrieve – recipient downloads and decrypts locally.

  6. Burn – on TTL expiry or after final allowed download.

1. Client-Side Encryption

The file never leaves the device in plaintext.

Simplified flow:

const fileBuffer = await readFileAsArrayBuffer(file);
const key = await generateFileKey(); // local only
const { ciphertext, nonce } = await encryptWithKey(key, fileBuffer);

await sendToNyxen({
  dropId,
  nonce,
  ciphertext,
  maxDownloads,
  expiresAt
});

Nyxen:

  • stores only ciphertext

  • tracks TTL + maxDownloads

  • never sees the file decrypted

  • never sees the encryption key

2. Link & Key Handling

Two recommended patterns:

A. Key-in-Fragment (Simple)

https://nyxen.vip/file/7HX2P#Kf9sQ2...

  • The fragment (#...) is handled client-side only.

  • Good for internal or lower-friction use.

B. Split Key (Safer)

  • URL without key:

https://nyxen.vip/file/7HX2P

  • Key sent via:

    • another channel,

    • voice,

    • in-person,

    • or through a Dead Drop Room.

[!TIP] For meaningful sensitivity, always split link and key. Consider the link compromised; the key is the gate.

3. Retrieval Rules

On access:

  1. Nyxen verifies:

    • dropId exists

    • TTL not expired

    • downloads < maxDownloads

  2. Client pulls ciphertext.

  3. Client uses key (fragment or user input) to decrypt locally.

  4. File is made available for save/open.

After successful retrieval:

  • If maxDownloads = 1:

    • Nyxen purges stored ciphertext immediately.

  • If maxDownloads > 1:

    • Nyxen decrements counter; purges after final allowed download.

If TTL expires first:

  • Drop becomes invalid regardless of remaining downloads.

[!IMPORTANT] Once purged, the file cannot be retrieved—even if someone still has the old link.

Recommended Usage Patterns

Scenario
TTL
Max Downloads
Notes

One-time key/seed transfer

5–15 minutes

1

Small file; split key; confirm burn.

Sensitive report / log excerpt

30–60 minutes

1–2

Use for review; keep master copy offline.

Access instructions / configs

15–45 minutes

1–3

Rotate configs; avoid email attachments.

Legal/ops working draft snapshot

30–120 minutes

1–3

Not a repo; ephemeral checkpoint only.

[!TIP] Treat File Drops as envelopes, not storage. Anything permanent should live in your own offline or controlled system, not on Nyxen.

Example: User Flow

A minimal step-by-step you can expose to users:

  1. Open Nyxen File Drops.

  2. Select the file to send.

  3. Set:

    • TTL: 20 minutes

    • Max downloads: 1

  4. Generate File Drop.

  5. Send:

    • Link via your usual channel.

    • Decryption key via a different channel.

  6. Recipient downloads and opens the file.

  7. Drop auto-burns after first download or TTL.

Result: no persistent attachment in email, chat, or shared drives.

Implementation Notes (For Builders)

  • Use streaming encryption for large files where supported.

  • Enforce practical size limits to:

    • keep UX clean,

    • avoid File Drops being misused as generic hosting.

  • Consider:

    • optional password protection on top of key,

    • forcing split-key mode for certain policies.

Example future API sketch:

POST /api/file-drop
Content-Type: application/json

{
  "ttl_seconds": 1200,
  "max_downloads": 1,
  "size_bytes": 5242880
}

Server response contains:

{
  "drop_id": "7HX2P",
  "share_url": "https://nyxen.gg/file/7HX2P"
}

Key generation & encryption remain client-side responsibilities.

How File Drops Relate to Other Nyxen Primitives

  • Use Dead Drops for multi-message coordination.

  • Use Secure Links for text-only secrets.

  • Use File Drops when a binary artifact must cross once, briefly.

  • Use Capsules to bundle one or more File Drops with:

    • a Dead Drop Room,

    • a Secure Link,

    • Signals, under a single TTL and key.

They all share the same Nyxen guarantees:

Key-based. Encrypted at the edge. Time-limited. Burnable. No archives.

PreviousSecure LinksNextEphemeral Boards (Coming soon)

Last updated