Note optional Darwin Core / GBIF / ALA biodiversity-portal bridge as a deferred, opt-in intention (open-decisions C + data-notes 3-bis), with privacy guardrails; not a phase or model change

docs/design/open-decisions.md

@@ -6,17 +6,17 @@
 
 Estas fijan `schemaVersion = 1` y el arranque técnico:
 
-- **Formato de exportación/copia:** abierto, documentado, versionado (datos + fotos + clave). Bloqueante para el backup. → [backup-and-recovery.md](backup-and-recovery.md)
+- **Formato de exportación/copia → ✅** un **archivo único cifrado**, abierto, documentado y versionado (volcado SQLite/CRDT + fotos + semilla envuelta). → [backup-and-recovery.md](backup-and-recovery.md)
 - **Cifrado en reposo (el "cómo" técnico):** SQLCipher + llave aleatoria en el almacén del sistema + QR de recuperación. Conceptualmente decidido; falta bajar el mecanismo. → [security-privacy.md](security-privacy.md)
-- **Claves separadas** para identidad (firmar) y para cifrado. (Tiende a: sí.)
-- **Detalles de modelo que fijan el esquema:** ¿`Quantity` como tipo compartido reutilizado en Lot y Movement? ¿`offer_status` solo en Lot? ¿`category` libre o ligada a `Species.family`? → [data-model.md](data-model.md) §6
-- **Licencia** del código (AGPL vs GPLv3): conviene fijarla al abrir el repo público.
-- **Alcance de la "varilla" v1** y **fuente de los datos de conservación** (viabilidad, secado): ¿quién los cura/empaqueta? → [data-notes.md](data-notes.md) §3-ter
+- **Identidad → ✅ una sola clave** raíz (Duniter/Ğ1), de la que se deriva la secp256k1 para Nostr. La clave simétrica que cifra la BD en reposo es un **detalle interno aparte** (no es una identidad), así que no contradice el "una sola identidad". → [g1-integration.md](g1-integration.md), [security-privacy.md](security-privacy.md)
+- **Detalles de modelo que fijan el esquema → ✅** `Quantity` como **tipo compartido** (Lot y Movement); `offer_status` **solo en Lot**; `category` **texto libre** prerrellenado desde `Species.family`. → [data-model.md](data-model.md) §6
+- **Licencia** del código → ✅ **AGPL-3.0** (GPLv3 + cláusula de red; compatible con GPLv3 y con Duniter/Ğ1nkgo). Falta añadir el fichero `LICENSE` al abrir el repo.
+- **Varilla v1 → ✅ viable** con datos abiertos: nombres/identificación (Wikidata+GBIF, fácil), **conservación desde Kew SID** (dominio público, ~52k taxones), cuidados enlazados de Permapeople. Falta: confirmar acceso/descarga de Kew SID y el subconjunto curado a empaquetar. → [data-notes.md](data-notes.md) §3-ter
 - **Estructura del workspace** (`commons_core` + `app_seeds`, pub workspaces) — decidido; falta materializarlo.
 
 ## B) Decidir antes de la capa de compartir (Fase 3) — muy interdependientes
 
-- **Transporte de la capa social — REPLANTEAR** (ya no "Nostr primero"): la decisión de "una sola clave Duniter/Substrate" (D7) descarta la identidad Nostr. Opciones: datapod/indexador del ecosistema Duniter (misma clave), transporte agnóstico a la clave, o Nostr como mero relay con sobre propio. → [g1-integration.md](g1-integration.md) D7
+- **Transporte de la capa social → Nostr (confirmado).** No se renuncia a Nostr: **Duniter no tiene mensajería**, así que Nostr es la vía para mensajes y ofertas. Se mantiene "una sola identidad" derivando la clave **secp256k1** (Nostr) de la semilla raíz Ğ1. Falta: confirmar madurez de los NIPs y la ruta de derivación. (Datapods de Duniter descartados: no están en servicio.) → [g1-integration.md](g1-integration.md)
 - **Estrategia de relays:** app-as-relay oportunista + proximidad física + relays comunitarios. → network-trust §3
 - **Parámetros de la red de confianza:** umbral de certificaciones (¿5, estilo Duniter?), distancia, caducidad, certificación por colectivo. → network-trust §2
 - **Mensajería:** alcance v1 (1:1 atada a oferta), apoyo en NIP-17. → network-trust §4
@@ -34,6 +34,7 @@ Estas fijan `schemaVersion = 1` y el arranque técnico:
 - Ampliar avisos legales más allá de Europa (empezar por jurisdicción común europea). → PLAN §6
 - Segundo producto (biblioteca de cosas) y extracción de `Item/Holding` al core. → core-domain-boundary
 - Bloqueo de app: ¿activado por defecto o sugerido? → security-privacy
+- **Puente opcional con portales abiertos de biodiversidad (Darwin Core / GBIF / ALA).** Export *opt-in* de agrobiodiversidad (variedades cultivadas, taxonomía folk, nombres vernáculos) como Darwin Core Archive hacia un atlas ALA/GBIF — justo los datos que esos portales tienen más flojos. **No es fase ni código ahora:** solo se apunta como intención. Lo único que exige del diseño actual ya lo hacemos por otros motivos: anclar especies a GBIF key + Wikidata QID (data-model §2.2) y mantener el formato de exportación abierto/versionado (requisito de backup, Fase 1). **Guardas innegociables** para que no choque con el modelo de privacidad: opt-in por ítem, a nivel de banco colectivo (no persona), ubicación difuminada, solo material no sensible, y en un solo sentido (app → portal; nunca escribir de vuelta en un inventario privado). Argumento de interoperabilidad útil para NLnet/NGI. → data-notes §3-bis
 
 ## D) Qué chirría (tensiones a mirar de frente)
 
@@ -49,7 +50,7 @@ Estas fijan `schemaVersion = 1` y el arranque técnico:
 
 6. **Alcance vs. sostenibilidad de un mantenedor.** El conjunto (inventario + cripto + P2P + confianza + mensajería + relays, en varias plataformas) es **mucho** para "proyecto personal + IA". Refuerza la necesidad de: fases honestas, comunidad temprana, y financiación (NLnet) para la parte social. La Fase 1 sí es abordable en solitario.
 
-7. **Primitivo de identidad — RESUELTO: una sola clave.** Decidido: **una única clave Duniter-v2/Substrate para todo** (perfil, ofertas, mensajes, certificaciones, Ğ1), como en Duniter. Nada de claves por función. **Consecuencia abierta:** esto **debilita Nostr** como transporte (su identidad es su clave secp256k1) → hay que **replantear el transporte de la capa social** hacia el ecosistema Duniter (datapods) o algo agnóstico a la clave, en vez de "Nostr primero". No bloquea la Fase 1. → [g1-integration.md](g1-integration.md)
+7. **Identidad — RESUELTO: una sola identidad, dos claves derivadas.** Una **semilla raíz** estilo Duniter/Ğ1 (perfil, certificaciones, Ğ1) de la que se **deriva** determinísticamente la clave **secp256k1** para Nostr (mensajes, ofertas). Para la persona es *una sola identidad y una sola copia* (el QR de la semilla). **Nostr no se descarta** — es imprescindible porque **Duniter carece de mensajería**. No hay contradicción con "una sola clave": son subclaves de una raíz. → [g1-integration.md](g1-integration.md)
 
 ## Recomendación de orden