feat(node): indexing v2 — partial-read hashing for files above 40 MB

Files above 40 MB are no longer read in full. Instead, blake3 hashes
45 MB of samples (first 20 MB + last 20 MB + 5 MB at 50% offset).
Files at or below 40 MB are unchanged (full read, hash_version 1).

A new `hash_version` field on IndexEntry (default 1) travels on the
wire and through the cache so both versions coexist without breaking
existing nodes or clients.

The IndexCache auto-migrates its schema on open (ALTER TABLE), so no
manual step is required on upgrade. A standalone migration script is
available in QE/migration/ for operators who want to preview or force
a full re-hash.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

1 files changed, 312 insertions, 0 deletions

diff --git a/docs/indexing-v2.md b/docs/indexing-v2.md
new file mode 100644
index 0000000..6fc7990
--- /dev/null
+++ b/docs/indexing-v2.md
@@ -0,0 +1,312 @@
+# Indexing v2 — Partial-read hashing for large files
+
+> Status: **plan, not built.** Decision record and implementation checklist.
+
+---
+
+## 0. Problem
+
+The current indexer reads every file in full to compute its blake3 content hash (`id`).
+For a large media library (multi-terabyte, thousands of files), this means:
+
+- **Time**: initial indexing takes tens of minutes to hours.
+- **Disk I/O**: every byte of every file is read, which wears SSDs and saturates spinning
+  drives for the entire duration. A USB hard drive serving a 4 TB library is pegged for
+  over an hour.
+- **Blocking**: no connected peer receives a usable index until the full scan finishes.
+
+The hash exists for **content identity** (deduplication, cross-group search, file
+requests). A 4 GB film does not need 4 GB of I/O to be identified with overwhelming
+probability — 45 MB of well-chosen samples suffice.
+
+---
+
+## 1. Design
+
+### 1.1 Hashing rules
+
+| File size          | Method                                              | `hash_version` |
+|--------------------|-----------------------------------------------------|-----------------|
+| <= 40 MB           | Full read, blake3 of entire content (unchanged)     | `1`             |
+| > 40 MB            | Partial read, blake3 of 45 MB sampled (see below)   | `2`             |
+
+**Partial-read algorithm (hash_version 2):**
+
+Given a file of `S` bytes where `S > 40 MB`:
+
+1. Read the first **20 MB** (bytes `[0, 20 MB)`).
+2. Append the last **20 MB** (bytes `[S - 20 MB, S)`).
+3. Append **5 MB** starting at **50% of the file** (bytes `[S // 2, S // 2 + 5 MB)`).
+4. Compute `blake3(concatenation of the three regions)`.
+
+The three regions may overlap for files just above 40 MB. This is fine — the concatenation
+is deterministic for a given file, which is the only property that matters.
+
+**Why these offsets.** Head and tail catch container headers, trailers, and the common case
+of files that differ only at one end (re-encoded, re-muxed, appended). The mid-sample
+catches files that share a header and trailer but differ in content (same container,
+different media stream).
+
+**Why 40 MB threshold.** Below 40 MB the partial read would sample the entire file anyway
+(head + tail >= file size), so the full-read path is both simpler and produces the same
+result. The boundary is inclusive: a 40 MB file is read in full.
+
+### 1.2 `hash_version` field
+
+A new field on `IndexEntry`:
+
+```
+hash_version: int = 1
+```
+
+- `1` — the `id` is blake3 of the full file content. This is the only value any existing
+  node has ever produced.
+- `2` — the `id` is blake3 of the 45 MB partial sample described above.
+
+**For files <= 40 MB on a v2 node, `hash_version` stays `1`.** The hash is identical to
+what a v1 node produces, because both read the file in full. This preserves cross-group
+search compatibility for small files across v1 and v2 nodes.
+
+**For files > 40 MB on a v2 node, `hash_version` is `2`.** The hash is different from
+what a v1 node would produce for the same file. This is the accepted side effect.
+
+### 1.3 Backward compatibility
+
+| Scenario | Behaviour |
+|---|---|
+| v2 node sends `hash_version` to v1 client | Client ignores unknown field (JS objects are open) |
+| v1 node sends entries without `hash_version` | Client/consumer treats it as `1` (dataclass default) |
+| v2 `IndexEntry(**e)` where `e` lacks `hash_version` | Uses default `1` — existing serialized indexes deserialize correctly |
+| Cross-group search: same file, one node v1, one node v2 | Different `id` for files > 40 MB — not merged. Accepted |
+| Cross-group search: same small file, mixed nodes | Same `id` (both `hash_version=1`) — merged correctly |
+| Hub tables (`swarm_sources`, `content_blocklist`, `content_reports`) | Store `content_hash` as an opaque string. No change needed |
+| `GroupIndex.serialize()` / `deserialize()` | `asdict(e)` includes `hash_version`; `IndexEntry(**e)` with default handles missing field |
+
+**Nothing breaks.** A v1 node's data remains valid. A v2 node produces correct new hashes.
+Mixed v1/v2 environments work, with the documented search side effect.
+
+---
+
+## 2. Affected components
+
+### 2.1 `meshbay_common` — `protocol.py`
+
+| Change | Detail |
+|---|---|
+| `IndexEntry` dataclass | Add `hash_version: int = 1` field |
+| `index_entry_wire()` | Add `"hash_version": e.hash_version` to the wire dict |
+
+### 2.2 `meshbay_node` — `indexer/indexer.py`
+
+| Change | Detail |
+|---|---|
+| Constants | `_PARTIAL_THRESHOLD = 40 * 1024 * 1024`, `_PARTIAL_HEAD = 20 * 1024 * 1024`, `_PARTIAL_TAIL = 20 * 1024 * 1024`, `_PARTIAL_MID = 5 * 1024 * 1024` |
+| `_scan_file()` | After stat, if `size > _PARTIAL_THRESHOLD`: use partial-read blake3. Set `hash_version=2` on the returned `IndexEntry`. Otherwise: unchanged (full read, `hash_version=1`) |
+| `_hash_or_cached()` | Compute expected `hash_version` from file size. Pass it to cache `lookup()`. Store it in cache `put()`. Set it on the returned `IndexEntry` |
+
+**`_scan_file` partial-read implementation:**
+
+```python
+def _partial_hash(file_path: Path, size: int) -> str:
+    hasher = blake3.blake3()
+    with open(long_path(file_path), "rb") as f:
+        _feed(hasher, f, _PARTIAL_HEAD)
+        f.seek(size - _PARTIAL_TAIL)
+        _feed(hasher, f, _PARTIAL_TAIL)
+        f.seek(size // 2)
+        _feed(hasher, f, _PARTIAL_MID)
+    return hasher.hexdigest()
+
+def _feed(hasher, f, nbytes: int) -> None:
+    remaining = nbytes
+    while remaining > 0:
+        chunk = f.read(min(_HASH_CHUNK, remaining))
+        if not chunk:
+            break
+        hasher.update(chunk)
+        remaining -= len(chunk)
+```
+
+### 2.3 `meshbay_node` — `indexer/cache.py`
+
+| Change | Detail |
+|---|---|
+| Schema | Add `hash_version INTEGER NOT NULL DEFAULT 1` column to `files` table |
+| `_SCHEMA` | New databases get the column via `CREATE TABLE` |
+| `_MIGRATE_V2` | `ALTER TABLE files ADD COLUMN hash_version INTEGER NOT NULL DEFAULT 1` — applied on `open()` if the column does not exist |
+| `lookup()` | Add `hash_version` parameter. WHERE clause becomes `path = ? AND size = ? AND mtime = ? AND hash_version = ?` |
+| `put()` | Add `hash_version` parameter. INSERT includes `hash_version` |
+| `CachedEntry` | Add `hash_version: int` field |
+
+**Auto-migration on open:** `IndexCache.open()` runs the ALTER TABLE inside a try/except
+(column already exists → no-op). This way a node upgrade just works — no manual step
+needed for the cache.
+
+### 2.4 `meshbay_node` — `indexer/group_index.py`
+
+No code change needed. `serialize()` calls `asdict(e)` which includes `hash_version`.
+`deserialize()` calls `IndexEntry(**e)` which uses the default `1` for entries written
+before v2.
+
+### 2.5 `meshbay_node` — `transport/wire.py`
+
+No code change needed. `index_sync_message()` and `index_delta_message()` call
+`index_entry_wire()` which is updated in §2.1.
+
+### 2.6 Client side (browser / desktop)
+
+**No code changes required.** Entries are JavaScript objects; the extra `hash_version`
+field is carried through without needing explicit handling:
+
+- `transport.js` — `_applyIndexMessage()` passes the opened payload through. `hash_version`
+  rides along on each entry object.
+- `group-page.js` — `applyIndex()` / `applyIndexDelta()` store entries as-is in state
+  and in IndexedDB.
+- `hub-client.js` — IndexedDB cache stores entry objects verbatim.
+- `source-merge.js` — merges by `id`. Different hashes naturally don't merge.
+- `search-page.js` — aggregates entries from cached indexes. No change.
+- `files-app.js` — renders entries. `hash_version` is ignored.
+
+### 2.7 Hub side
+
+**No code changes required.** `swarm_sources.content_hash`, `content_reports.content_hash`,
+`content_blocklist.content_hash` are opaque `String(64)` columns. They store whatever
+blake3 hex the node provides. No hub migration needed.
+
+### 2.8 Tests
+
+| Test | What it verifies |
+|---|---|
+| `test_indexer.py` — new cases | Partial hash for file > 40 MB produces `hash_version=2`. File <= 40 MB produces `hash_version=1`. Partial hash is deterministic. Partial hash differs from full hash for the same large file |
+| `test_indexer.py` — existing cases | All existing tests still pass (small files, type detection, enrichment, etc.) |
+| `test_index_cache.py` — new cases | Cache lookup with `hash_version` match. Cache miss when `hash_version` differs. Schema migration from v1 cache |
+| `test_index_cache.py` — existing cases | Unchanged behaviour for v1 entries |
+| `test_indexer.py` — round-trip | `GroupIndex.serialize()` → `deserialize()` preserves `hash_version` on entries |
+| `test_index_seal_client.py` | Wire format includes `hash_version`, old entries without it deserialize as v1 |
+
+---
+
+## 3. Migration
+
+### 3.1 What actually needs migrating
+
+The node has two relevant stores:
+
+| Store | Location | Content | Migration |
+|---|---|---|---|
+| `index_cache.db` | `data_dir/index_cache.db` | `(path, size, mtime) → hash` accelerator | Add `hash_version` column |
+| In-memory `GroupIndex` | rebuilt from disk on every startup | Current file listing | No migration — rebuilt on next scan |
+
+**The IndexCache is the only persistent store that needs a schema change.** The GroupIndex
+is rebuilt by scanning the filesystem on every daemon start. Once the code uses v2 hashing,
+the next startup produces v2 hashes for large files automatically.
+
+**The cache auto-migrates.** `IndexCache.open()` adds the `hash_version` column if missing.
+Existing rows get `DEFAULT 1`. When the v2 indexer looks up a large file with
+`hash_version=2`, the cached v1 entry won't match (different hash_version in WHERE), so
+the file is re-hashed with the partial algorithm and the new entry is written with
+`hash_version=2`.
+
+This means: **large files are re-hashed lazily on first scan after upgrade.** The first
+scan after upgrading to v2 re-reads 45 MB per large file instead of the full content —
+already much faster than v1's full read.
+
+### 3.2 Migration script — `QE/migration/migrate_index_v2.sh`
+
+A standalone bash script (not in git — QE/ is gitignored) that:
+
+1. Detects the node's `data_dir` from `node.toml` (default `~/.local/share/meshbay-node/`)
+2. Checks that `index_cache.db` exists
+3. Runs `ALTER TABLE files ADD COLUMN hash_version INTEGER NOT NULL DEFAULT 1`
+4. Optionally (`--purge-large`) deletes cache entries for files > 40 MB, forcing immediate
+   re-hash on next scan instead of lazy migration
+5. Reports what it did
+
+**Works on Ubuntu and Fedora** — uses only `sqlite3` (present by default on both) and
+standard bash.
+
+**Not strictly required** if the code's auto-migration in `IndexCache.open()` is
+implemented. The script exists for operators who want to:
+- Verify the schema change before restarting
+- Force a clean re-hash of all large files in one pass
+- Run the migration on a machine where the node isn't installed yet (preparing a data dir)
+
+### 3.3 What the operator does
+
+1. Update the node package (or `pip install -e` in dev)
+2. (Optional) Run `QE/migration/migrate_index_v2.sh` to preview or force the migration
+3. Restart the node daemon
+4. The first scan re-hashes files > 40 MB with partial reads — much faster than before
+
+No client-side action needed. No hub-side action needed.
+
+---
+
+## 4. What does NOT change
+
+- **Files <= 40 MB** — identical hashing, identical `id`, `hash_version=1`.
+- **Enrichment** (thumbnails, duration, metadata) — unchanged, still runs after hashing.
+- **File downloads** — `file_req` uses the current `id` from the index. After re-indexing,
+  clients get the new index with new hashes and request accordingly.
+- **Watchdog / reconciliation** — filesystem events trigger the same code paths. New or
+  modified files are hashed with the appropriate method based on size.
+- **Index encryption / signing** — `GroupIndex.serialize()` and the GEK-sealed wire
+  messages are unchanged. `hash_version` rides inside each entry via `asdict()`.
+- **Index delta computation** — `GroupIndex.diff()` compares entries by all fields
+  (dataclass `__eq__`). A re-indexed file whose hash changed (v1 → v2) appears as a
+  deletion of the old id + addition of the new id, which is correct.
+- **Hub tables** — opaque content_hash storage, untouched.
+- **MNP version** — this is an additive field on index entries. No protocol version bump
+  needed. An older node that doesn't send `hash_version` is handled by the default.
+
+---
+
+## 5. Side effects — documented and accepted
+
+1. **Cross-group search**: a file > 40 MB indexed on a v1 node and a v2 node produces
+   different `id`s. The search page will not merge them as the same file. The user sees
+   two entries instead of one, each from its own group. This resolves itself when both
+   nodes upgrade.
+
+2. **First scan after upgrade**: files > 40 MB are re-hashed. With v2 this reads 45 MB
+   per file (not the full content), so the re-index is fast — but it is not instant. A
+   4 TB library with 1000 large files reads ~44 GB instead of 4 TB.
+
+3. **`content_hash` drift on hub tables**: if a public group's node upgrades, the hashes
+   it registers in `swarm_sources` change for large files. Old entries with v1 hashes
+   become stale. The swarm registration mechanism's `last_seen` update handles this — stale
+   entries age out. No explicit cleanup needed.
+
+4. **Index version bump**: re-indexing sets `GroupIndex.version = int(time.time())`,
+   which triggers a full `index_sync` to all connected peers. This is the normal path for
+   any index change — it is not new load.
+
+---
+
+## 6. Indexing trigger points — verified safe
+
+| Trigger | Location | Impact of v2 |
+|---|---|---|
+| Daemon startup — initial scan | `daemon.py:648-674` | Uses `_hash_or_cached()` which applies v2 rules. Safe |
+| Create Group wizard — Step 3 | `create-group-page.js:244-248` polls `index-status` | No change — polls progress, doesn't control hashing |
+| Settings — add root | `group-settings.js:909-927` | Triggers `retarget()` → scan → `_hash_or_cached()`. Safe |
+| Watchdog — file created/modified | `indexer.py:797-816` | Calls `_update_entry()` → `_hash_or_cached()`. Safe |
+| Reconciliation loop | `indexer.py:513-650` | Calls `_sweep_available_roots()` → `_hash_or_cached()`. Safe |
+| Hot reload — `_reload_config()` | `daemon.py:790-829` | Creates new `DirectoryIndexer` with v2 code. Safe |
+
+---
+
+## 7. Implementation order
+
+1. **`protocol.py`** — add `hash_version` field to `IndexEntry` and `index_entry_wire()`
+2. **`cache.py`** — add `hash_version` to schema, auto-migrate on open, update lookup/put
+3. **`indexer.py`** — implement `_partial_hash()`, update `_scan_file()` and
+   `_hash_or_cached()`
+4. **Tests** — new test cases for partial hashing, cache versioning, wire round-trip
+5. **`QE/migration/migrate_index_v2.sh`** — standalone migration script
+6. **Manual test** — run a node with a mixed library (small + large files), verify:
+   - Small files: same hash as before, `hash_version=1`
+   - Large files: different hash, `hash_version=2`, 45 MB read
+   - Cross-group search: small files merge, large files don't (across v1/v2 nodes)
+   - Cache hit on second scan: no re-read
+   - Index sync to connected peers: entries carry `hash_version`