feat(sync): encrypted device-to-device sync transport (core foundation)
The most foundational Block-2+ gap: the data model was built CRDT-ready (HLC, tombstones, LWW, append-only Movement) and the import reconciler proves the merge — but nothing replicated a device's inventory to your OTHER devices. Only manual file backup/restore moved data between devices. This lands the transport foundation in commons_core (seed-agnostic, on the shared connection — the 'one connection, N interfaces' shape): - SyncTransport: moves an opaque, encrypted snapshot blob between ONE identity's own devices. The core carries bytes + does the crypto; the app decides what the bytes are and how to merge them. - NostrSyncTransport: NIP-78 app-data (kind 30078, addressable/replaceable per device via the d-tag), content NIP-44-encrypted TO SELF, discovery filtered to your own author key. Each device keeps one replaceable record. Tests (MiniRelay, pure Dart): a snapshot replicates to the identity's other device; the relay only ever sees ciphertext; another identity neither receives nor could decrypt; re-push replaces; two devices keep their own. Confirms the open-decisions §D.4 guarantee (sync leaks neither the key nor plaintext). NEXT slice (app): a SyncService that serializes the inventory (reusing ExportImportService), pushes on mutation, and runs the existing idempotent importInventory on receive; a stable per-install device id; wire sync into SocialSession.
This commit is contained in:
parent
b9492cb65a
commit
bf15992a97
5 changed files with 262 additions and 1 deletions
|
|
@ -48,7 +48,7 @@ Estas fijan `schemaVersion = 1` y el arranque técnico:
|
|||
|
||||
3. **Apuesta fuerte por Nostr.** Ofertas, mensajes y confianza dependerían de NIPs en evolución (99 / 17 / 85). La abstracción `OfferTransport` amortigua las ofertas, pero mensajería y confianza también se apoyan en Nostr → más acoplamiento del que sugería el plan. Revisar si un solo protocolo lo cubre bien o si conviene aislar también mensajería y confianza tras interfaces.
|
||||
|
||||
4. **Cifrado en reposo + sync CRDT + multidispositivo.** Hay que asegurar que la sincronización **no filtra la llave ni datos en claro**, y que la llave (QR) llega bien al segundo dispositivo. Encaja, pero es un punto técnico fino que conviene prototipar pronto.
|
||||
4. **Cifrado en reposo + sync CRDT + multidispositivo — EN CURSO (base landed 2026-07-10).** El modelo ya está listo para CRDT (HLC, tombstones, LWW, Movement append-only) y el reconciliador de import prueba el merge; faltaba el **transporte de sync**. Primera rebanada en `commons_core`: `SyncTransport` (mueve snapshots opacos y cifrados entre los dispositivos de UNA identidad) + `NostrSyncTransport` (NIP-78 kind 30078 addressable/reemplazable por dispositivo, contenido **NIP-44 cifrado a sí mismo** → el relay solo ve cifrado; filtrado a tu propia clave de autor). Tests con MiniRelay: replica al otro dispositivo, el cable solo ve cifrado, otra identidad no recibe ni podría descifrar, re-push reemplaza. **Confirma la garantía de §4**: no filtra llave ni datos en claro. PENDIENTE (siguiente rebanada, app): `SyncService` que serialice el inventario (reusa `ExportImportService`), empuje en mutaciones, y en recepción corra `importInventory` (LWW idempotente ya existente); id de dispositivo estable por instalación (keystore, NO el nodeId derivado de la semilla, que es común a los dispositivos); integrar `sync` en `SocialSession` (5ª interfaz sobre la conexión compartida); UI de conflictos (raro).
|
||||
|
||||
5. **La "varilla" y los datos de conservación** necesitan una fuente y una curación que **aún no tenemos**. Puede ser más trabajo del que parece (y es, a la vez, de lo que más valor humano aporta).
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue