realtimeclipboard 0.3.0

package/src/core/crypto.js

@@ -0,0 +1,215 @@
+/**
+ * End-to-end encryption. All of it. No libraries.
+ *
+ * OPEN SESSION — the key the user types serves two purposes without the server
+ * learning it:
+ *
+ *   roomHash = SHA-256("realtimeclipboard:" + KEY)[0..16]   -> sent, routes the room
+ *   aesKey   = PBKDF2(KEY, salt, 250k)             -> never leaves this browser
+ *
+ * LOCKED SESSION — a PIN that is never in the link, never on disk and never
+ * sent anywhere. It is folded into ONE PBKDF2 run whose output is expanded by
+ * HKDF into three independent values:
+ *
+ *   prk       = PBKDF2(PIN, salt = "realtimeclipboard-lock-v1:" + KEY, 600k)
+ *   aesKey    = HKDF(prk, "…/aes")    -> AES-GCM-256
+ *   roomHash  = HKDF(prk, "…/room")   -> sent, routes the room
+ *   authToken = HKDF(prk, "…/auth")   -> sent, proves PIN knowledge to the relay
+ *
+ * The room hash requiring the PIN is the load-bearing part: it is what turns
+ * "you cannot read it" into "you cannot find it". Someone holding the link but
+ * not the PIN computes a different room hash, lands in a different room, and
+ * never appears in the real one at all — no peer slot, no roster entry, no
+ * traffic metadata. Locked and unlocked rooms with the same key are likewise
+ * disjoint, so the two kinds of client can never meet and fail to decrypt each
+ * other.
+ *
+ * The relay cannot derive the key from the hash, so it cannot decrypt. It sees
+ * a room name and ciphertext, and nothing else. See PRD §7.3.
+ */
+
+import { CRYPTO } from "./config.js";
+
+const enc = new TextEncoder();
+const dec = new TextDecoder();
+
+/** Derivation is expensive (OI-8), so cache per key for the session. */
+let cached = { id: null, aesKey: null };
+
+export async function roomHash(key) {
+  const digest = await crypto.subtle.digest("SHA-256", enc.encode("realtimeclipboard:" + key));
+  return hex(new Uint8Array(digest).slice(0, CRYPTO.ROOM_HASH_BYTES));
+}
+
+/**
+ * Derive the AES key. Several hundred ms on a low-end Android, so call once
+ * per session and show an "unlocking" state — never per message.
+ */
+export async function deriveKey(key) {
+  if (cached.id === `open:${key}` && cached.aesKey) return cached.aesKey;
+
+  const material = await crypto.subtle.importKey(
+    "raw", enc.encode(key), "PBKDF2", false, ["deriveKey"]
+  );
+  const aesKey = await crypto.subtle.deriveKey(
+    { name: "PBKDF2", salt: enc.encode(CRYPTO.SALT),
+      iterations: CRYPTO.ITERATIONS, hash: "SHA-256" },
+    material,
+    { name: "AES-GCM", length: 256 },
+    false,
+    ["encrypt", "decrypt"]
+  );
+  cached = { id: `open:${key}`, aesKey };
+  return aesKey;
+}
+
+/* ------------------------------------------------------------------
+   Locked sessions
+------------------------------------------------------------------- */
+
+/**
+ * Normalise a PIN — the exact OPPOSITE of what normalise() does to a key, and
+ * the reasoning is worth keeping because getting it backwards is silent.
+ *
+ * A key is uppercased and stripped to [A-Z0-9] so that two people typing "the
+ * same key" land in the same room. A PIN is user-chosen prose, so:
+ *
+ *   - NFC, mandatory. "é" can be typed as one code point or as "e" plus a
+ *     combining accent. They are different byte strings, they derive different
+ *     rooms, and NOTHING would report it — the second device would simply be
+ *     alone in a room of its own, looking like a wrong PIN.
+ *   - Trim the ends. A trailing space from a paste is invisible on screen and
+ *     the user has no way to see why their correct PIN is rejected.
+ *   - Keep case and everything in the middle. Uppercasing would throw away
+ *     about a bit per letter to buy nothing: unlike a key, a PIN is never read
+ *     aloud off a screen and retyped from memory.
+ */
+export function normalisePin(raw) {
+  return String(raw ?? "").normalize("NFC").trim();
+}
+
+/**
+ * The whole locked-session derivation: one PBKDF2, three outputs.
+ *
+ * PBKDF2 reruns its full iteration count for every 32-byte block of output, so
+ * asking it for the 64 bytes we need would cost twice what it should — and OI-8
+ * already flags this as hundreds of milliseconds on a low-end Android. Instead
+ * we stretch once and expand with HKDF, which is a couple of HMACs.
+ *
+ * The share key is the salt, and it is worth being precise about what that does
+ * and does not buy. It stops ONE table from covering every session — the
+ * open-session path, with its single global CRYPTO.SALT, has exactly that
+ * weakness today. It buys nothing at all against the attacker this feature is
+ * actually for: someone holding the link holds the key, so they can compute the
+ * salt themselves. Against them the only defence is the length of the PIN and
+ * the iteration count, which is why the dialog reports entropy in bits instead
+ * of calling a short PIN "secure".
+ *
+ * Returns `prk` as hex alongside the derived values so a page refresh can skip
+ * the 600k iterations. See storage.saveLock for why the PIN itself is never
+ * what gets stored.
+ */
+export async function deriveLocked(key, pin) {
+  const prk = await stretch(key, normalisePin(pin));
+  return { ...(await expand(prk)), prk: hex(new Uint8Array(prk)) };
+}
+
+/** Same outputs, from a remembered prk. No PBKDF2, so this is instant. */
+export async function deriveLockedFromPrk(prkHex) {
+  return { ...(await expand(unhex(prkHex))), prk: prkHex };
+}
+
+async function stretch(key, pin) {
+  const material = await crypto.subtle.importKey(
+    "raw", enc.encode(pin), "PBKDF2", false, ["deriveBits"]
+  );
+  return crypto.subtle.deriveBits(
+    { name: "PBKDF2", salt: enc.encode(CRYPTO.LOCK_SALT + key),
+      iterations: CRYPTO.LOCK_ITERATIONS, hash: "SHA-256" },
+    material,
+    256
+  );
+}
+
+async function expand(prk) {
+  const ikm = await crypto.subtle.importKey("raw", prk, "HKDF", false, ["deriveBits", "deriveKey"]);
+  const info = i => ({ name: "HKDF", hash: "SHA-256", salt: new Uint8Array(0), info: enc.encode(i) });
+
+  const [aesKey, room, auth] = await Promise.all([
+    crypto.subtle.deriveKey(
+      info(CRYPTO.LOCK_INFO.AES), ikm,
+      { name: "AES-GCM", length: 256 }, false, ["encrypt", "decrypt"]
+    ),
+    crypto.subtle.deriveBits(info(CRYPTO.LOCK_INFO.ROOM), ikm, CRYPTO.ROOM_HASH_BYTES * 8),
+    crypto.subtle.deriveBits(info(CRYPTO.LOCK_INFO.AUTH), ikm, CRYPTO.ROOM_HASH_BYTES * 8),
+  ]);
+
+  return {
+    aesKey,
+    roomHash:  hex(new Uint8Array(room)),
+    authToken: hex(new Uint8Array(auth)),
+  };
+}
+
+/**
+ * No cache entry for locked sessions, deliberately.
+ *
+ * The open-session cache exists because deriveKey() is called with the same key
+ * repeatedly. The locked path is not: it runs once per session, a reconnect
+ * reuses the room hash without re-deriving, and the only things that DO call it
+ * again — a corrected PIN, a rotated key — are the cases where the previous
+ * answer is exactly the one you must not reuse. The refresh path is covered by
+ * the stored prk instead, which is cheaper than a cache and survives the tab
+ * being reloaded.
+ */
+
+/** -> {payload, iv} both base64. A fresh IV per message is mandatory for GCM. */
+export async function encrypt(aesKey, plaintext) {
+  const iv = crypto.getRandomValues(new Uint8Array(12));
+  const buf = await crypto.subtle.encrypt(
+    { name: "AES-GCM", iv }, aesKey, enc.encode(plaintext)
+  );
+  return { payload: toB64(buf), iv: toB64(iv) };
+}
+
+export async function decrypt(aesKey, payloadB64, ivB64) {
+  const buf = await crypto.subtle.decrypt(
+    { name: "AES-GCM", iv: fromB64(ivB64) }, aesKey, fromB64(payloadB64)
+  );
+  return dec.decode(buf);
+}
+
+/**
+ * Forget the derived key.
+ *
+ * Called on leaving a session and on rotating the key. For years this had no
+ * callers at all, which meant the AES key of a room you had deliberately walked
+ * out of stayed live in this module until you happened to open another one.
+ */
+export function clearCache() { cached = { id: null, aesKey: null }; }
+
+/* ---- hex helpers ---- */
+function hex(bytes) {
+  return [...bytes].map(b => b.toString(16).padStart(2, "0")).join("");
+}
+function unhex(s) {
+  const out = new Uint8Array(s.length / 2);
+  for (let i = 0; i < out.length; i++) out[i] = parseInt(s.substr(i * 2, 2), 16);
+  return out;
+}
+
+/* ---- base64 helpers (binary-safe) ---- */
+function toB64(buf) {
+  const bytes = new Uint8Array(buf);
+  let s = "";
+  for (let i = 0; i < bytes.length; i += 0x8000) {
+    s += String.fromCharCode(...bytes.subarray(i, i + 0x8000));   // chunked: avoids arg limit
+  }
+  return btoa(s);
+}
+function fromB64(b64) {
+  const bin = atob(b64);
+  const out = new Uint8Array(bin.length);
+  for (let i = 0; i < bin.length; i++) out[i] = bin.charCodeAt(i);
+  return out;
+}

package/src/core/device.js

@@ -0,0 +1,55 @@
+/**
+ * A human-readable name for this device, shown in the peer list.
+ *
+ * Derived from the user agent, which is unreliable by design — this is a label
+ * to help someone recognise their own laptop in a list of three, not an
+ * identity.
+ *
+ * IT IS SENT IN THE CLEAR. This comment used to claim the opposite — "inside
+ * the encrypted envelope, never to the relay in the clear" — and the wire has
+ * never agreed with it: `protocol.hello()` puts `name` in a plaintext field,
+ * and the relay stores it and rebroadcasts it in every roster
+ * (backend/main.py `_adopt_identity`, `_roster`).
+ *
+ * So keep it a label. "Chrome · Windows" is fine; a name is not the place for
+ * anything you would mind the relay operator reading. This is one of the things
+ * a locked session does NOT hide — see PRD §7.5 and OI-20.
+ */
+
+import { read, write } from "./storage.js";
+
+function detect() {
+  const ua = navigator.userAgent;
+
+  const os =
+    /Windows/i.test(ua)                    ? "Windows" :
+    /Android/i.test(ua)                    ? "Android" :
+    /iPhone|iPad|iPod/i.test(ua)           ? "iOS"     :
+    /Mac OS X|Macintosh/i.test(ua)         ? "macOS"   :
+    /Linux/i.test(ua)                      ? "Linux"   : "Unknown";
+
+  // Order matters: Edge and Opera both contain "Chrome", Chrome contains "Safari".
+  const browser =
+    /Edg\//i.test(ua)                      ? "Edge"    :
+    /OPR\/|Opera/i.test(ua)                ? "Opera"   :
+    /Firefox\//i.test(ua)                  ? "Firefox" :
+    /Chrome\//i.test(ua)                   ? "Chrome"  :
+    /Safari\//i.test(ua)                   ? "Safari"  : "Browser";
+
+  return `${browser} · ${os}`;
+}
+
+/** Persisted so a device keeps its name across reloads, and stays renameable. */
+export function name() {
+  const saved = read("deviceName");
+  if (saved) return saved;
+  const detected = detect();
+  write("deviceName", detected);
+  return detected;
+}
+
+export function rename(newName) {
+  const clean = String(newName || "").trim().slice(0, 40);
+  if (clean) write("deviceName", clean);
+  return clean || name();
+}

package/src/core/history.js

@@ -0,0 +1,208 @@
+/**
+ * In-session clip history — PRD FR-2.9 (last 20 clips, one-click copy).
+ *
+ * ── PRIVACY INVARIANT ──────────────────────────────────────────────────────
+ * This module persists to **sessionStorage only. Never localStorage.**
+ *
+ * Clipboard content is not ordinary application data: in practice it is
+ * passwords, API tokens, 2FA codes and private URLs. Those must not survive the
+ * browser session, must not be readable by the next person to open the laptop,
+ * and must not leak between rooms. sessionStorage is scoped to the tab and dies
+ * with it, which is exactly the lifetime we want.
+ *
+ * core/storage.js is the localStorage wrapper and is explicitly documented as
+ * "clipboard *content* never comes near this — only preferences". So the
+ * sessionStorage twin lives here rather than being bolted onto that module: the
+ * two stores have different lifetimes for a reason, and keeping them in separate
+ * files is what stops a future edit from quietly moving clips onto disk.
+ *
+ * The same reasoning drives the key-change behaviour: a different share key is a
+ * different room and a different set of people. History never crosses that line.
+ *
+ * Node-testable on purpose — this file imports only core/bus.js, and every
+ * sessionStorage call is wrapped, so it degrades to memory-only where the API is
+ * missing (node, private mode, storage disabled).
+ */
+
+import { on, emit, EV } from "./bus.js";
+
+/**
+ * PRD FR-2.9 caps history at 20. This belongs in core/config.js with the other
+ * limits; it lives here only because config.js is owned elsewhere. Move it when
+ * the two land together.
+ */
+export const MAX_CLIPS = 20;
+
+/** Event names this module owns. Use the constants — a typo'd literal is a silent no-op. */
+export const EVENTS = {
+  /** {clips, reason} — the list changed (add / clear / hydrate). */
+  CHANGED: "history:changed",
+  /** {text} — a clip was picked from history and should be loaded into the editor. */
+  RESTORE: "history:restore",
+};
+
+const STORE_KEY = "realtimeclipboard.history";
+
+let clips = [];
+let roomKey = null;      // share key the current list belongs to; null until first KEY_CHANGED
+let started = false;
+let seq = 0;
+
+/* ------------------------------------------------------------------ storage */
+/*
+ * Mirrors the shape of core/storage.js (read / write / remove, wrapped so a
+ * disabled-storage browser degrades instead of throwing) but targets
+ * sessionStorage. try/catch also swallows the ReferenceError under node, which
+ * is what makes this module testable outside a browser.
+ */
+
+function readStore() {
+  try {
+    const raw = sessionStorage.getItem(STORE_KEY);
+    return raw === null ? null : JSON.parse(raw);
+  } catch { return null; }
+}
+
+function writeStore(value) {
+  try { sessionStorage.setItem(STORE_KEY, JSON.stringify(value)); return true; }
+  catch { return false; }   // quota, private mode, or no sessionStorage at all
+}
+
+function removeStore() {
+  try { sessionStorage.removeItem(STORE_KEY); } catch { /* nothing to do */ }
+}
+
+/**
+ * A clip can be 50k characters and we keep 20 of them, so a full list can push
+ * a megabyte. If the write is refused we keep going in memory rather than
+ * dropping the clip — losing persistence across a reload is a smaller failure
+ * than losing the user's clipboard.
+ */
+function persist() {
+  if (!clips.length && roomKey === null) return removeStore();
+  writeStore({ key: roomKey, clips });
+}
+
+/* ------------------------------------------------------------------- model */
+
+const nextId = () => `h${Date.now().toString(36)}${(++seq).toString(36)}`;
+
+/** Local normalisation — deliberately not importing core/keys.js, which pulls in
+ *  config.js and its top-level `location` read (breaks node testability). */
+const normKey = k => String(k ?? "").trim().toUpperCase();
+
+function announce(reason) {
+  emit(EVENTS.CHANGED, { clips: all(), reason });
+}
+
+/** Newest first. Returns a shallow copy — callers must not mutate the list. */
+export function all() {
+  return clips.slice();
+}
+
+export function get(id) {
+  return clips.find(c => c.id === id) ?? null;
+}
+
+export const size = () => clips.length;
+
+/**
+ * Record a clip. Returns the new entry, or null if it was ignored.
+ *
+ * Ignored when: the text is empty/whitespace, or it is identical to the most
+ * recent entry. That last one matters more than it looks — capture tiers can
+ * fire twice for one copy (paste event + poll), and a peer echoing our own clip
+ * back arrives with the same text under a different direction. Consecutive
+ * duplicates are noise in every one of those cases.
+ */
+export function add({ text, direction }) {
+  const value = String(text ?? "");
+  if (!value.trim()) return null;
+
+  const dir = direction === "sent" ? "sent" : "received";
+  if (clips.length && clips[0].text === value) return null;   // consecutive dedupe
+
+  const entry = { id: nextId(), text: value, direction: dir, at: new Date(), chars: value.length };
+  clips.unshift(entry);
+  if (clips.length > MAX_CLIPS) clips.length = MAX_CLIPS;     // FR-2.9: last 20
+
+  persist();
+  announce("add");
+  return entry;
+}
+
+/** Drop everything, in memory and in sessionStorage. */
+export function clear(reason = "clear") {
+  const had = clips.length;
+  clips = [];
+  removeStore();
+  if (roomKey !== null) persist();
+  if (had) announce(reason);
+  return had;
+}
+
+/* -------------------------------------------------------------------- boot */
+
+/**
+ * Rehydrate whatever this tab had before a reload. The stored key is not known
+ * to be the current room yet — the first KEY_CHANGED decides whether to keep or
+ * discard this (see onKeyChanged).
+ */
+function hydrate() {
+  const saved = readStore();
+  if (!saved || !Array.isArray(saved.clips)) return;
+
+  roomKey = saved.key ?? null;
+  clips = saved.clips
+    .filter(c => c && typeof c.text === "string")
+    .slice(0, MAX_CLIPS)
+    .map(c => ({
+      id: typeof c.id === "string" ? c.id : nextId(),
+      text: c.text,
+      direction: c.direction === "sent" ? "sent" : "received",
+      at: new Date(c.at ?? Date.now()),          // JSON round-trips Date to a string
+      chars: typeof c.chars === "number" ? c.chars : c.text.length,
+    }));
+}
+
+/**
+ * A new share key is a new room, new peers, and a new privacy context. Clips
+ * from the old room must not be sitting in the panel when someone else joins.
+ *
+ * The first KEY_CHANGED after boot is not a rotation, though — main.js emits one
+ * during startup for the key we already had. Comparing against the key stored
+ * alongside the clips is what tells the two apart, and is why the key is
+ * persisted with the list rather than held only in memory.
+ */
+function onKeyChanged({ key }) {
+  const next = normKey(key);
+  if (!next) return;
+
+  if (roomKey !== null && normKey(roomKey) !== next) {
+    roomKey = next;
+    clear("key-changed");
+    persist();
+    return;
+  }
+
+  roomKey = next;
+  persist();
+}
+
+/**
+ * Subscribe to the bus. Idempotent — ui/historyPanel.js calls this so the
+ * feature is one init() line in main.js, but calling it from main.js directly is
+ * equally fine.
+ */
+export function init() {
+  if (started) return;
+  started = true;
+
+  hydrate();
+
+  on(EV.TEXT_CAPTURED, ({ text }) => add({ text, direction: "sent" }));
+  on(EV.TEXT_RECEIVED, ({ text }) => add({ text, direction: "received" }));
+  on(EV.KEY_CHANGED, onKeyChanged);
+
+  if (clips.length) announce("hydrate");
+}

package/src/core/keys.js

@@ -0,0 +1,150 @@
+/** Share-key generation and normalisation. */
+
+import { KEY, LOCK } from "./config.js";
+
+/**
+ * Cryptographically random key from the unambiguous alphabet.
+ *
+ * Note the modulo bias: 256 does not divide 30, so the first 16 letters of the
+ * alphabet are very slightly likelier than the last 14. The effect is about
+ * 0.03 bits over a 6-character key — irrelevant next to the 30-bit total, and
+ * called out here so nobody has to rediscover it.
+ */
+export function generate(length = KEY.LENGTH) {
+  const bytes = crypto.getRandomValues(new Uint8Array(length));
+  return Array.from(bytes, b => KEY.ALPHABET[b % KEY.ALPHABET.length]).join("");
+}
+
+/**
+ * Bits of entropy in a key of this length, given the 30-letter alphabet.
+ *
+ *   6 chars  ≈ 29.4 bits   — the default. Convenient, and brute-forceable
+ *                            offline by anyone who captured ciphertext.
+ *  10 chars  ≈ 49.1 bits   — ~1.6 million times harder, still typeable.
+ *
+ * PBKDF2 at 250k iterations multiplies the cost of each guess, but it does not
+ * change the shape of the problem: short keys are a convenience decision, and
+ * this function exists so the UI can say so in numbers rather than adjectives.
+ */
+export function entropyBits(length) {
+  return Math.log2(KEY.ALPHABET.length) * length;
+}
+
+export const LENGTHS = { NORMAL: KEY.LENGTH, LONG: KEY.LONG_LENGTH };
+
+/**
+ * Normalise before ANY use — hashing, comparison, display.
+ *
+ * This matters more than it looks: the room name is a hash of the key, and
+ * "D75LV" and "d75lv" hash differently. Skipping this silently drops two users
+ * into different rooms while both believe they typed the same key.
+ * Verified in docs/M0-RESULTS.md §6.
+ */
+export function normalise(raw) {
+  return String(raw || "").trim().toUpperCase().replace(/[^A-Z0-9]/g, "");
+}
+
+/**
+ * Deliberately more permissive than the generation alphabet.
+ *
+ * KEY.ALPHABET exists so generated keys are unambiguous when read aloud or
+ * retyped — it is a constraint on what we PRODUCE. Validation must accept
+ * anything a peer might legitimately hand us, because:
+ *
+ *   - a key shared from another build (or a future alphabet) is still valid;
+ *     the room name is a hash, and a hash accepts any input
+ *   - rejecting an in-use key strands the user with no way to join
+ *
+ * "D75LV" is the worked example throughout the docs and contains an L, which
+ * the generator will never emit. It still has to work.
+ */
+export function isValid(raw) {
+  const k = normalise(raw);
+  return k.length >= 4 && k.length <= 32;
+}
+
+/**
+ * Bits of entropy in a PIN, estimated from the character classes it actually
+ * uses rather than from its length alone.
+ *
+ * Deliberately pessimistic — it assumes an attacker who knows the alphabet you
+ * drew from, which is the only assumption worth making about someone running an
+ * offline attack. "123456" is counted as six digits, not six printable ASCII
+ * characters, so the dialog reports ~20 bits and not a flattering ~39.
+ *
+ * The number matters more here than it does for a key. A key is guessed from
+ * nothing; a PIN is guessed by someone who may already hold the link, and at
+ * that point it is the entire remaining secret.
+ */
+export function pinEntropyBits(pin) {
+  const p = String(pin ?? "");
+  if (!p) return 0;
+  let alphabet = 0;
+  if (/[a-z]/.test(p)) alphabet += 26;
+  if (/[A-Z]/.test(p)) alphabet += 26;
+  if (/[0-9]/.test(p)) alphabet += 10;
+  if (/[^a-zA-Z0-9]/.test(p)) alphabet += 33;      // printable ASCII punctuation
+  return Math.log2(alphabet) * p.length;
+}
+
+/* ------------------------------------------------------------------
+   The fragment
+
+   A locked session's link carries a marker but never the PIN: `#!ABCDEF`.
+   That a session is locked is not a secret — the PIN is — and the app has to
+   know before it derives anything, because the marker is what decides which of
+   two completely different derivations to run.
+
+   Parsing happens BEFORE normalise(), and that ordering is load-bearing:
+   normalise() strips everything outside [A-Z0-9], so running it first turns
+   "#!ABCDEF" into the perfectly valid, completely different key "ABCDEF".
+
+   An older build has no idea about any of this. It normalises the fragment,
+   drops the "!", and joins the UNLOCKED room named ABCDEF — a different room
+   from the locked one, which it cannot address. It finds an empty room and
+   learns nothing, which is the correct way for this to fail.
+------------------------------------------------------------------- */
+
+export const LOCK_SIGIL = LOCK.SIGIL;
+
+/** Split a raw fragment into its key and its lock flag. */
+export function parseFragment(raw) {
+  const s = String(raw ?? "").trim();
+  const locked = s.startsWith(LOCK.SIGIL);
+  return { key: normalise(locked ? s.slice(LOCK.SIGIL.length) : s), locked };
+}
+
+/** Build one. The inverse of parseFragment, and tested as such. */
+export function fragment(key, locked = false) {
+  return (locked ? LOCK.SIGIL : "") + normalise(key);
+}
+
+/** Read the key from the URL fragment. The fragment is never sent to a server. */
+export function fromUrl() {
+  return parseFragment(location.hash.slice(1));
+}
+
+export function toUrl(key, locked = false) {
+  location.hash = fragment(key, locked);
+}
+
+/**
+ * Drop the key out of the address bar without navigating.
+ *
+ * For the one case where the session in the URL is not merely over but closed
+ * to this device: it was locked by somebody else and we were removed from it
+ * (main.js onEvicted). The fragment is what boot() reads first, so leaving it
+ * in place means every reload rejoins a room we have been ejected from and
+ * gets ejected again.
+ *
+ * replaceState rather than `location.hash = ""`, which leaves a bare "#" on the
+ * URL and pushes a history entry — so Back would put the dead key straight
+ * back.
+ */
+export function clearUrl() {
+  history.replaceState(null, "", location.pathname + location.search);
+}
+
+export function shareLink(key, locked = false) {
+  return `${location.origin}${location.pathname}#${fragment(key, locked)}`;
+}