From 1c73f1b1ef5a195f8859f88246145984d038f2af Mon Sep 17 00:00:00 2001 From: Fredrik Johansson Date: Sun, 28 Jun 2026 22:53:35 +0200 Subject: [PATCH] ci: bump Node to 24 to match local lockfile; add history gossip proposal package-lock.json was generated with npm 11 (Node 24). CI was running Node 20 which resolves @emnapi deps differently, causing npm ci to fail. Co-Authored-By: Claude Sonnet 4.6 --- .gitea/workflows/build.yml | 2 +- PROPOSAL-history-gossip.md | 154 +++++++++++++++++++++++++++++++++++++ 2 files changed, 155 insertions(+), 1 deletion(-) create mode 100644 PROPOSAL-history-gossip.md diff --git a/.gitea/workflows/build.yml b/.gitea/workflows/build.yml index 24509b6..a2b665a 100644 --- a/.gitea/workflows/build.yml +++ b/.gitea/workflows/build.yml @@ -20,7 +20,7 @@ jobs: - uses: actions/setup-node@v4 with: - node-version: '20' + node-version: '24' - name: Install Wails CLI run: go install github.com/wailsapp/wails/v2/cmd/wails@latest diff --git a/PROPOSAL-history-gossip.md b/PROPOSAL-history-gossip.md new file mode 100644 index 0000000..927194e --- /dev/null +++ b/PROPOSAL-history-gossip.md @@ -0,0 +1,154 @@ +# Proposal: P2P Message History Gossip + +## Goals + +- New peers joining a network can retrieve recent message history from existing peers +- No central storage — history lives only in peer daemons (SQLite) +- No new trust requirements — history is shared only over already-established encrypted DataChannels +- No duplicates in the local store or UI +- No conflicts — history gossip is append-only and idempotent + +--- + +## Privacy Model + +History is shared **peer-to-peer over the encrypted mesh**, never via the anchor. The anchor remains dumb — it sees only signaling blobs. A peer only receives history from peers they have successfully completed a YAW/2 handshake with, so the same trust boundary as live messages applies. + +A peer can choose not to share history by ignoring `history_request` messages — the protocol is advisory, not mandatory. + +--- + +## Wire Protocol + +Two new YAW/2 extension messages (added to EXTENSIONS.md): + +### `history_request` + +Sent by a newly-connected peer to one or more existing peers shortly after the handshake completes. + +```json +{ + "type": "history_request", + "room": "general", + "since": "2026-01-01T00:00:00Z", + "limit": 200 +} +``` + +| Field | Type | Description | +|---------|-----------------|----------------------------------------------------------| +| `room` | string | Room name to request history for. One request per room. | +| `since` | ISO 8601 or "" | Only return messages newer than this timestamp. Empty = return up to `limit` most recent. | +| `limit` | int (max 500) | Maximum number of messages to return. Responder may return fewer. | + +### `history_chunk` + +Response from an existing peer. May be sent in multiple chunks if `limit` is large. + +```json +{ + "type": "history_chunk", + "room": "general", + "messages": [ + { + "id": "sha256:", + "from": "", + "from_id": "", + "body": "hello", + "ts": "2026-06-01T12:00:00Z", + "room": "general" + } + ], + "done": true +} +``` + +| Field | Type | Description | +|------------|---------|----------------------------------------------------------| +| `messages` | array | Ordered oldest-first. | +| `done` | bool | `true` on the final chunk. Receiver may display after this. | + +--- + +## Message Identity and Deduplication + +Each message has a **content-addressed ID**: + +``` +id = "sha256:" + hex(SHA-256(from_id || room || ts || body)) +``` + +- Computed by the original sender and included in every live message going forward +- The SQLite `messages` table gains an `id TEXT UNIQUE` column +- On insert, use `INSERT OR IGNORE` — receiving the same message twice (live or via gossip) is a no-op +- The UI sorts by `ts`, so late-arriving history slots in correctly without reordering visible messages + +Legacy messages (before this feature) have no `id`. They are assigned a local-only ID on migration and are never gossipped (they have no canonical ID the receiver could deduplicate against). + +--- + +## Daemon-Side Implementation + +### SQLite schema change + +```sql +ALTER TABLE messages ADD COLUMN msg_id TEXT; +CREATE UNIQUE INDEX IF NOT EXISTS idx_messages_msg_id ON messages(msg_id) WHERE msg_id IS NOT NULL; +``` + +### Handling `history_request` + +``` +peer sends history_request{room, since, limit} +→ query SQLite: SELECT * FROM messages WHERE room=? AND ts>? ORDER BY ts ASC LIMIT ? +→ send history_chunk{room, messages, done:true} +``` + +Responder enforces: +- `limit` capped at 500 +- Only messages the responder itself received or sent (no re-gossipping of gossipped history to avoid amplification) +- Rate limit: one `history_request` per peer per room per 60 seconds + +### Handling `history_chunk` + +``` +for each message in chunk: + INSERT OR IGNORE INTO messages (msg_id, room, from_alias, from_id, body, ts) VALUES (...) +emit IPC event: history_loaded{room, count} +``` + +### When to request + +- After handshake completes with the **first** peer in a network (only ask one peer — avoids fan-out) +- Request rooms the local peer knows about (from its own SQLite `rooms` table) +- If no rooms known yet: request `"general"` only; discover others from incoming live messages + +--- + +## IPC / UI Integration + +New IPC event emitted after history is loaded: + +```json +{ "type": "history_loaded", "network_id": "...", "room": "general", "count": 47 } +``` + +The web UI and TUI insert a visual separator above the first gossipped message: + +``` +── 47 earlier messages ───────────────────────────── +[12:03] alice: hey +[12:04] bob: yo +── live ───────────────────────────────────────────── +[14:22] you joined +``` + +--- + +## What This Does Not Do + +- **No conflict resolution** — messages are immutable append-only records; there is nothing to conflict +- **No ordering guarantee beyond timestamp** — if two peers sent messages at the same millisecond, both are stored; the UI sorts by `ts` then `msg_id` for a stable tiebreak +- **No full sync** — gossip is bounded by `limit` and `since`; it is not a replication protocol +- **No anchor involvement** — the anchor never sees history +- **No history from peers who were offline** — if no peer with history is online when you join, you get nothing (acceptable given the trust model)