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 <noreply@anthropic.com>

.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

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:<hex>",
+      "from":      "<peer-alias>",
+      "from_id":   "<hex-pubkey>",
+      "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)