Exchange DB changes over Iroh

README.md

@@ -101,7 +101,8 @@ The bootstrap implementation provides:
 - local DB resource registration: `geth db add <name> <path>` and
   `geth db status <name>` with schema and `crsql_changes` metadata; the DB
   crate and daemon can extract typed local `crsql_changes` batches through
-  `geth db changes <name>` for future sync
+  `geth db changes <name>` and exchange authorized remote batches with
+  `geth db sync <node-id> <name>`
 - local SQLite-backed KV commands: `geth kv create/set/get`; `kv set` accepts
   `--subject <principal>` to exercise local capability checks for non-local
   callers; `geth kv sync <node-id> <name>` pulls authorized remote updates
@@ -161,6 +162,13 @@ Document sync is a bootstrap JSON last-writer-wins path before Automerge:
 manual `geth document sync <node-id> <name>` and background live-sync require
 `document.read` on `resource:document:<name>` and import only state that is not
 older than the local document timestamp.
+DB sync is a staged cr-sqlite path: manual `geth db sync <node-id> <name>` and
+background live-sync require `db.sync` on `resource:db:<name>`, exchange typed
+`crsql_changes` batches over the protected Iroh control path, and check remote
+schema metadata against the local DB before advancing the per-peer cursor.
+Applying remote changes through cr-sqlite is still future work, so the current
+prototype is useful for validating auth, schema gating, and live change
+exchange without mutating the local application database.
 Importing or pinging a peer card never grants capabilities by itself.
 When `[iroh].local_discovery = true`, the daemon also advertises and discovers
 signed peer cards on LAN using a geth-specific mDNS TXT payload. That payload is