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: 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): 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; 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)

• 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í.)