BurnLink — notes that provably die

Share a secret that provably stops existing. Encrypted in your browser, stored as an Arkiv entity on the Tiramisu testnet, and deleted by the protocol — by burn-after-read or by Entity Expiration — never by someone's promise.

Built for Arkiv: Global Tour Stop 🌍 (9–18 Oct 2026). Tracks entered: Privacy and Security.

How it works

1. You type a note — or attach an image, or record a voice note (15 s Opus clip). The browser encrypts it with AES-GCM-256 (WebCrypto).
2. Only the ciphertext becomes an Arkiv entity — { iv, ct, bh } — with the Entity Expiration you picked (15 seconds → 30 days).
3. The decryption key is placed inside the link fragment (#k=…&b=…). Fragments are never sent over the network.
4. The recipient opens the link: ciphertext is fetched with a credential-free public client, decrypted locally, and — for burn-after-read notes — the entity is deleted on-chain. Reloading the link shows "gone".

Features

• Burn-after-read — reading fires a real deleteEntity; the explorer shows the deletion transaction.
• Timed expiry — 15s → 30d via Arkiv Entity Expiration. The holder can extend the fuse (extendEntity +5m/+1h) or burn it now — both gated by the burn-capability token.
• Passphrase layer — optional second secret; PBKDF2-derived key, wrong guesses can't burn the note.
• Image notes — downscaled client-side to fit the entity cap, encrypted inside the same envelope; indistinguishable from text on-chain.
• Replies — sender-opt-in. The recipient's reply is a burnlink-reply entity pointed at the note via a replyto attribute, readable only by link-holders.
• QR hand-off — the link QR is generated locally; the key never leaves the browser.
• Live counter — counts type = "burnlink" entities on-chain (attribute query, so session-signed notes count too).
• Sender retract — kill the link right after sealing.
• Invisible session wallet — on page load the browser generates a disposable keypair and /api/fund drips it ~0.005 GLM. When funded, the note is created by createEntity signed in the browser — the sender provably owns the entity (unique $creator) without ever seeing a wallet. Falls back to the shared relay if the drip hasn't landed.

Why Arkiv is load-bearing

• Postgres/S3: deletion is a promise by an operator who can be breached, subpoenaed, or simply careless. On Arkiv, Entity Expiration and deleteEntity are enforced by the protocol and visible on the explorer.
• IPFS: no expiry, no delete — content-addressed data is forever.
• Own API + encrypted blobs: still one operator holding ciphertext it could keep forever or hand over. With Arkiv the ciphertext sits on a public chain; there is no operator to compel, and deletion is verifiable.

Schema & evidence

• /arkiv/schema.md — entity types, attributes, expirations, queries
• /arkiv/friction.md — build friction report
• Entity-creating wallet: 0x4d3Af8811dB4D23D1cb0Ad8355c419d05fd467AB (relay)

Run locally

cp .env.example .env.local   # add a funded Tiramisu wallet key
npm install
npm run dev                  # http://localhost:3000

Requires Node ≥ 20 and @arkiv-network/[email protected].

Design notes

• Session wallet → relay fallback — the preferred path signs note writes with a disposable browser-generated keypair (gas dripped via /api/fund, rate-limited per address/IP/hour). If unfunded, the relay wallet signs instead — consumer UX plus a privacy property: relay notes share one $creator, unlinkable to their authors.
• Burn token (bh): entity keys are enumerable via $creator, so deletion requires the token whose SHA-256 is in the payload — carried only in the link fragment. See arkiv/schema.md.
• Demo data is synthetic — per the rules, never put real secrets in a note.

MIT © BurnLink contributors 2026

Asset note: public/fire-bg.mp4 is a third-party "fiery background" animation sourced via Pinterest (pin.it/Tqb7jF9At) — used for hackathon demo purposes; verify its licence before production reuse.