tane/docs/design/backup-and-recovery.md

# Tane — Copias de seguridad y recuperación

*Nota de diseño (discusión). Responde al hueco crítico nº 1 de [VISION.md](../../VISION.md): si cada persona es su propio banco, perder el móvil no puede significar perder el banco.*

## El planteamiento

"El banco eres tú." Tu inventario, tu identidad (tu clave) y tu historial viven en tu teléfono. Si el móvil se rompe, se pierde o se cambia, hace falta poder **recuperarlo todo** en otro. Y como Tane **no tiene servidor central** (por sostenibilidad y por privacidad), la copia no puede vivir "en la nube de Tane": tiene que ir a un sitio que **tú** elijas y controles.

Qué debe entrar en una copia completa: los datos del inventario (variedades, lotes, movimientos, notas), las **fotos**, la **identidad (par de claves)** y la red de confianza/Plantares que tienes. Sin la clave, recuperarías los datos pero perderías tu identidad y tu reputación; por eso viajan juntos, cifrados.

## Principios (coherentes con el proyecto)

- **Sin infraestructura de Tane.** El destino de la copia lo pone la persona: un archivo, su propia nube, otro dispositivo. Nada obligatorio en servidores nuestros.
- **Privada por defecto.** La copia va cifrada (lleva tu clave privada y tus datos). Nadie más debería poder leerla.
- **Para humanos de 10 a 80.** "Guarda una copia de tu banco", no "exporta la base de datos cifrada". Metáfora amable: guardar las semillas a buen recaudo. Recordatorios suaves ("hace 2 meses que no haces copia").
- **Degrada con elegancia.** La copia más simple (un archivo) funciona sin red y sin cuentas. Las opciones más cómodas se añaden encima, nunca como requisito.

## Mecanismos, en capas (de lo simple a lo potente)

### 1. Exportar / importar un archivo *(base, Fase 1)*
Un botón: **"Guardar una copia de mi banco"** → un único archivo `.tane` (un zip con los datos + fotos + la clave, cifrado con una frase de paso). La persona lo guarda donde quiera: se lo manda a su propio correo, a un USB, a su nube, lo copia a otro móvil. **"Restaurar desde una copia"** en el móvil nuevo lo devuelve todo, identidad incluida. Sin infraestructura, sin cuentas, totalmente privado. Es la red de seguridad mínima y debe existir desde el inventario (Fase 1).
*Contra:* es manual (la gente se olvida) y el archivo es sensible (por eso, cifrado).

### 2. Copia a una carpeta que tú sincronizas *(muy alineado con tu ethos)*
La app deja la copia (cifrada) en una **carpeta local que tu propia herramienta ya sincroniza**: Seafile, Nextcloud, Syncthing... (justo como trabajas tú). Set-and-forget, sin depender de Big Tech ni de nosotros. Para quien ya se autogestiona, es la opción ideal.

### 3. Copia automática programada a un destino elegido *(Fase 1–2)*
La app escribe la copia cada cierto tiempo en el sitio que elegiste una vez (una carpeta, tu nube). Resuelve el "se me olvidó". Con recordatorios amables si lleva mucho sin hacerse.

### 4. Respaldo del sistema operativo *(red de seguridad automática)*
Aprovechar el backup normal del móvil (Android Auto Backup / iCloud): los datos de la app entran en la copia que la persona ya hace de su teléfono. Cero esfuerzo, pero opaco, con límites de tamaño (las fotos), y atado a cuentas de Big Tech → **como red de seguridad adicional, no como único mecanismo**.

### 5. Segundo dispositivo = copia viva *(Fase 3, cuando exista la sincronización)*
Como el modelo es CRDT, **sincronizar con un segundo dispositivo** (una tablet, el ordenador de casa, el móvil de la pareja) hace que los datos vivan en dos sitios: el segundo dispositivo *es* una copia que se actualiza sola. La misma maquinaria de sincronización que construimos para el P2P sirve de backup. Elegante, pero necesita la sincronización hecha y un segundo aparato.

### 6. Papel: recuperación de la identidad *(bonito y fiel al Plantare)*
La **clave de identidad** cabe en una hoja imprimible / un QR (como una "frase de recuperación", pero explicada con cariño). Un QR guardado en un cajón permite recuperar tu identidad aunque lo pierdas todo. El inventario entero no cabe en papel, pero **imprimir un catálogo legible de tu banco** es además un artefacto humano precioso y muy en la línea del Plantare de papel.

### 7. Respaldo social/distribuido *(investigación, más adelante)*
Trozos cifrados de tu copia guardados entre **contactos de confianza** o en relays. "Tu banco, respaldado en tu red." Muy en el espíritu (descentralizado, resiliente), pero complejo → no para la v1.

### 8. El banco colectivo como respaldo *(gratis, cuando exista)*
Lo que compartes con un banco comunitario ya está replicado en el banco y en otras personas. Pertenecer a un banco es, en sí, una copia de lo compartido.

## ¿Cifrar la copia? Pros, contras y recomendación

Es la decisión delicada, y conviene separarla por partes, porque la copia contiene dos cosas muy distintas: **los datos** (semillas, notas, fotos) y **la clave de identidad**.

**A favor de cifrar:**
- Protege tu **clave privada** si el archivo cae en malas manos (con ella te podrían **suplantar**: publicar ofertas o firmar Plantares como si fueras tú, dañar tu reputación). Este es el argumento fuerte y real.
- Protege el **grafo social** ("quién comparte qué con quién") en **contextos donde compartir está penado** (Francia/Kokopelli) — justo parte del público que al proyecto le importa.
- Tranquilidad si la copia va a una nube de terceros.

**En contra de cifrar (con contraseña):**
- **Introduce un modo de fallo que va justo en contra del propósito de una copia:** contraseña olvidada = pérdida **total e irreversible**. En un backup —cuyo único fin es *no* perder— esto es especialmente perverso. Para el público de 10 a 80, olvidar la contraseña es *más probable* que sufrir un robo del archivo.
- **Fricción** real: contraseñas, "no la apuntes pero no la olvides", gestión.
- Los **datos en sí son de baja sensibilidad** para la mayoría (una lista de semillas y fotos de tomates). Cifrarlo todo es matar moscas a cañonazos.
- **Redundante** si la copia ya vive en un sitio que tú proteges (tu cuenta de nube, tu cajón): el resto de tus ficheros ahí tampoco van cifrados uno a uno.

**Recomendación (revisada por el peor caso legal — ver [security-privacy.md](security-privacy.md)):** el "peor caso" (país donde la variedad está prohibida) obliga a subir el listón: **se cifra siempre, también el inventario en reposo, y también la copia.** La clave está en cifrar **sin una contraseña que olvidar**:

- **La llave es una clave aleatoria fuerte, no un secreto memorizado.** Uso diario: en el **almacén de claves del sistema** (se libera con la huella/PIN que ya usas). Recuperación/portabilidad: un **QR imprimible** que guardas físicamente ("como tu mejor semilla"), en dos copias.
- Así se consiguen **las dos cosas a la vez**: confidencialidad total (nada en claro, ni datos ni copia) *y* durabilidad (no hay contraseña que olvidar; solo pierdes datos si pierdes el móvil **y** todas las copias del QR — un objeto físico, no un olvido).
- **Contraseña adicional = opción avanzada** para quien quiera defensa en profundidad, con aviso honesto de pérdida irreversible.

Esto **corrige** la idea provisional anterior de "datos de baja sensibilidad → sin cifrar": valía para tomates en España, no para el peor caso, que es nuestra brújula. El detalle completo (inventario en reposo, bloqueo de app, red) vive en [security-privacy.md](security-privacy.md); aquí basta con: **la copia va cifrada con la llave del QR.**

## Recomendación por fases

- **Fase 1 (inventario):** exportar/importar a un archivo cifrado (mecanismo 1) + "copia a una carpeta que tú sincronizas" (2). Es la caja fuerte mínima, sin infraestructura. **Esto obliga a que el formato de exportación sea abierto, estable y versionado** (encaja con las migraciones, §5 del data-model): una copia de hace un año debe poder restaurarse en una versión nueva de la app.
- **Fase 1–2:** copia automática programada (3), recordatorios, QR de recuperación de identidad + catálogo imprimible (6).
- **Fase 3+:** segundo dispositivo como copia viva (5) y respaldo por banco colectivo (8).
- **Investigación:** respaldo social distribuido (7).

## Consecuencias para el diseño (ya, desde la Fase 1)

- El **formato de exportación** es de primera clase: abierto, documentado, estable, versionado, y que incluya datos + fotos + clave. No es un "extra al final".
- La **identidad debe ser exportable/recuperable** por separado (QR) además de dentro de la copia completa.
- Pensar el modelo para que **restaurar** sea idempotente y tolere versiones (una copia vieja restaurada en app nueva → se migra al abrir).

## Decidido sobre cifrado (ver [security-privacy.md](security-privacy.md))

- **Todo cifrado, siempre**: inventario en reposo *y* copia. Nada en claro en disco.
- **Llave = clave aleatoria** en el almacén del sistema (uso diario con huella/PIN) + **QR imprimible** físico (recuperación/portabilidad, dos copias). **Sin contraseña memorizada como único secreto.**
- Con eso: confidencialidad total *y* durabilidad (no hay contraseña que olvidar).
- **Contraseña adicional = opción avanzada opt-in** (defensa en profundidad), con aviso de pérdida irreversible.

## A decidir (pendiente)

- **Formato del archivo de copia:** ¿zip con SQLite/estado CRDT + carpeta de fotos + clave (protegida aparte); o un único blob? Debe ser abierto, documentado y versionado.
- ¿La copia "de datos" incluye la clave o la clave va **siempre** por el canal separado (QR)? (Tiende a: clave separada, para que una copia de datos filtrada no entregue la identidad.)
- ¿Ofrecemos "copia a carpeta" (Seafile/Nextcloud/Syncthing) ya en la v1 como opción destacada, dado que es la más afín al proyecto? (Tiende a: sí.)