From 465bef8691729030af34492eece5206fd836a9c2 Mon Sep 17 00:00:00 2001 From: vjrj Date: Tue, 7 Jul 2026 11:38:51 +0200 Subject: [PATCH] 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 --- PLAN.md | 11 +++++++++-- README.md | 4 ++-- VISION.md | 2 +- docs/design/data-model.md | 2 +- docs/design/data-notes.md | 17 ++++++++++++++++- docs/design/open-decisions.md | 15 ++++++++------- 6 files changed, 37 insertions(+), 14 deletions(-) diff --git a/PLAN.md b/PLAN.md index 8a44180..26a2319 100644 --- a/PLAN.md +++ b/PLAN.md @@ -3,7 +3,14 @@ *App descentralizada para la gestión personal y la compartición de semillas y plantel* Documento de trabajo · Julio 2026 · Autor del proyecto: vjrj (Comunes) -Licencia sugerida del documento y del proyecto: copyleft (ver §7) +Licencia del proyecto: **AGPL-3.0** (software) · docs y assets CC-BY-SA. + +> **Nota de vigencia.** Este PLAN es el documento *origen*. Varias decisiones han evolucionado en `docs/design/`; la **lista viva de decisiones** es [docs/design/open-decisions.md](docs/design/open-decisions.md). En particular, actualizan/matizan este texto: +> - **Nombre:** Tanemaki (種まき), apodo Tane; dominio `tanemaki.app`. +> - **Identidad:** *una sola clave* raíz estilo Duniter/Ğ1, de la que se **deriva** la clave secp256k1 para el transporte (Nostr). No "solo Nostr". → [g1-integration.md](docs/design/g1-integration.md) +> - **"¿Blockchain?" (§4):** sigue siendo *no* para los datos de semillas (locales/CRDT), pero **sí interoperamos con la cadena de Duniter v2** para identidad, red de confianza y moneda **opcionales** (Ğ1). No es contradicción: la blockchain no es el libro mayor de las semillas, es una capa opcional de identidad/confianza/pago. +> - **Transporte social:** Nostr sigue siendo la vía (viable con la clave derivada); datapods de Duniter descartados (no en servicio). +> - **Añadidos no cubiertos abajo:** usabilidad 10–80, la "varilla", backup y cifrado en reposo, mensajería 1:1, integración Ğ1 y arranque en frío vía grupos de semillas de Ğ1, y la frontera `commons_core`/`app_seeds`. Todo en `docs/design/`. --- @@ -262,7 +269,7 @@ El mayor riesgo de este proyecto no es técnico, es de *continuidad*. Los proyec **Técnica (que no dependa de ti para seguir vivo):** - Local-first significa que **la app sigue funcionando aunque no haya nadie manteniéndola ni servidores encendidos.** Es la forma más fuerte de sostenibilidad: la utilidad no caduca. - Sin infraestructura central que pagar = sin factura mensual que mate el proyecto. Relays de Nostr o instancias son opcionales y compartidos por la comunidad. -- Código libre (copyleft: AGPL o GPL v3) para que otra gente pueda continuar. Datos en formato abierto y exportable (que nadie quede atrapado). +- Código libre (**AGPL-3.0**, decidido) para que otra gente pueda continuar. Datos en formato abierto y exportable (que nadie quede atrapado). **Comunitaria (aunque hayas elegido empezar en solitario):** - Aunque el desarrollo inicial sea personal + IA, **abre el repositorio desde el principio** y ve dejando puertas: README claro, issues etiquetados "good first issue", documento de visión (este documento puede ser su semilla). diff --git a/README.md b/README.md index 0596188..86f8af3 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ Early design. See [`PLAN.md`](PLAN.md) for the full analysis and roadmap (in Spa ## Principles - **Local-first.** Works fully offline, no account, no central server. Stays useful even if no one maintains it. -- **Decentralized.** Identity is a keypair you own; sharing rides on open protocols (Nostr / ActivityPub), never a central marketplace. +- **Decentralized.** Identity is a single key you own (Duniter/Ğ1-style, with a derived subkey for transport); sharing rides on open protocols (Nostr), with optional interoperability with the Ğ1/Duniter web of trust and currency. Never a central marketplace. - **Free/libre.** Copyleft software, open data formats, multilingual from day one. - **Layered.** Inventory -> Offer -> Local sharing -> Web of trust. Each layer is useful on its own. @@ -30,4 +30,4 @@ Early design. See [`PLAN.md`](PLAN.md) for the full analysis and roadmap (in Spa ## License -Software: copyleft (AGPL/GPLv3, TBD). Docs & assets under CC-BY-SA where noted. +Software: **AGPL-3.0** (GPLv3 strengthened with the network clause; compatible with GPLv3 and with Duniter/Ğ1nkgo, which we reuse). Docs & assets under CC-BY-SA where noted. diff --git a/VISION.md b/VISION.md index 6bd8ec1..458c9e1 100644 --- a/VISION.md +++ b/VISION.md @@ -99,7 +99,7 @@ La capa social (huecos 2–6) tiene ya enfoque en [docs/design/network-trust.md] 5. **Relays.** Sí, **la propia app puede hacer de relay** (oportunista), combinado con intercambio por **proximidad física** (feria: Bluetooth/QR, cero infraestructura) y algún **relay comunitario** barato (colectivos/Comunes, no una empresa). -6. **Mensajería (hueco grande destapado).** Hace falta **mensajería 1:1 cifrada dentro de la app** (estilo Wallapop) para cerrar tratos sin dar el teléfono. Va sobre la misma identidad Nostr (NIP-17), es de `commons_core`, y el mockup `10_chat` ya la preveía. (La "autenticidad de variedad" se cubre con confianza + procedencia.) +6. **Mensajería (hueco grande destapado).** Hace falta **mensajería 1:1 cifrada dentro de la app** (estilo Wallapop) para cerrar tratos sin dar el teléfono. Va sobre la misma identidad (una clave; NIP-17 con la subclave derivada), es de `commons_core`, y el mockup `10_chat` ya la preveía. (La "autenticidad de variedad" se cubre con confianza + procedencia.) 7. **Avisos legales.** Empezar por **unas pocas jurisdicciones de marco común (Europa)** y ampliar luego. diff --git a/docs/design/data-model.md b/docs/design/data-model.md index c729932..b349970 100644 --- a/docs/design/data-model.md +++ b/docs/design/data-model.md @@ -113,7 +113,7 @@ Immutable events on a `Lot`. Entries/exits are just types. This *is* the history |---|---|---| | `id` | UUID | | | `display_name` | TEXT | | -| `public_key` | TEXT | Nullable. Nostr/keypair identity (Layer 3+). | +| `public_key` | TEXT | Nullable. The person's single identity key (Duniter/Ğ1-style; a derived subkey serves Nostr transport). Layer 3+. | | `kind` | enum | `person` / `collective`. | | `note` | TEXT | | diff --git a/docs/design/data-notes.md b/docs/design/data-notes.md index 908ba9f..9684065 100644 --- a/docs/design/data-notes.md +++ b/docs/design/data-notes.md @@ -75,6 +75,8 @@ Con eso, el **catálogo empaquetado se licencia CC-BY** (Wikidata CC0 + GBIF CC- El **banco de nombres de especie** (capa 4 de §2) viene de Wikidata/GBIF. Pero la **variedad/cultivar** (capa 3, la que más importa a quien guarda semillas) **la teclea la gente**, no una autoridad. Con el tiempo, los nombres de variedad compartidos entre usuarios de Tanemaki (de forma agregada/opcional) van formando **el propio banco folclórico de nombres de Tanemaki** — descentralizado, vivo, y que ninguna base oficial puede darte. Es coherente con todo el proyecto: la ciencia formal se toma prestada (CC0/CC-BY), pero el conocimiento de las variedades tradicionales es de la red, no de un registro. +Nota (posible puente futuro, no ahora): como anclamos a GBIF/Wikidata, ese banco folclórico —taxonomía de variedades y nombres vernáculos— es justo lo que los portales abiertos de biodiversidad (GBIF, atlas ALA) tienen más flojo. Deja la puerta a un export *opt-in* estilo Darwin Core, con guardas estrictas de privacidad. No es fase ni modelo; detalle e intención en [open-decisions.md](open-decisions.md) §C. + ### Regla transversal: online siempre opcional Nada del núcleo depende de la red. Offline tienes inventario completo, nombres del catálogo empaquetado, notas y registro de banco. Online solo *enriquece* (Wikipedia, fotos, GBIF, cultivo Permapeople, y más adelante los mapas de la Capa 3) y todo **degrada con elegancia**: si no hay red, simplemente no aparece esa capa extra, sin errores ni bloqueos. @@ -95,7 +97,20 @@ Principios (coherentes con todo lo demás): Encaje con la arquitectura: la varilla es **de dominio** (`app_seeds`), porque "cuidados" y "conservación" son específicos de semillas; el motor genérico no sabe de eso. Es una de las piezas que más diferencian a Tanemaki de una libreta: reduce a un toque lo que en papel era investigar y copiar a mano. -**A pensar más:** el conjunto mínimo de campos que la varilla intenta rellenar en la v1 (probablemente solo nombres + viabilidad + siembra), y si el reconocimiento por foto entra pronto o es fase posterior. +### ¿Es viable la "varilla mágica" con datos abiertos? Sí + +Verdad de a pie: **es viable**, y hay un gradiente de dificultad según el dato: + +- **Nombres, identificación y enciclopedia** (nombre común/científico, sinónimos, foto, resumen): **fácil**. Wikidata (CC0) + GBIF (CC-BY) + Wikipedia/Commons vía el QID. Aquí la varilla brilla. +- **Datos de conservación** (viabilidad en años, comportamiento en almacén, secado, peso de semilla, germinación): **viable, y con una joya** — la **Seed Information Database (SID) de Kew**, de **dominio público**, cubre ~52.000 taxones (comportamiento en almacén ~25.000 registros, germinación ~54.000, pesos, constantes de viabilidad) e incluye un **modelo que estima la viabilidad** según años y condiciones. Es a nivel de *especie* (no de tu variedad concreta), pero perfecto como **valor por defecto** que la persona confirma. Justo el saber que se está perdiendo, servido por la varilla. +- **Cuidados/cultivo** (siembra, riego, asociaciones): **viable pero más irregular** — Permapeople (CC-BY-SA) y Practical Plants tienen datos, a nivel de especie y con cobertura desigual; por su licencia *share-alike*, mejor **enlazar/consultar online** que empaquetar (§3-bis). + +Conclusión: la varilla no es magia ni humo — es **agregación de datos abiertos existentes**, anclada al QID de la especie. Lo fácil (nombres, Kew SID de conservación) da ya muchísimo valor; lo irregular (cuidados) se enlaza. Trabajo real: montar el **subconjunto curado empaquetado** para las especies objetivo (Wikidata + GBIF + Kew SID) y enriquecer online el resto. + +**A pensar más:** el conjunto mínimo de campos de la v1 (probablemente nombres + viabilidad/conservación de Kew SID + siembra), confirmar la vía de acceso/descarga de Kew SID, y si el reconocimiento por foto entra pronto o es fase posterior. + +### Fuentes +- [Seed Information Database (SID), RBG Kew — dominio público](http://data.kew.org/sid/) · [visión general MSB](https://www.rbgkew.org.uk/msbp/scitech/sidoverview.html) --- diff --git a/docs/design/open-decisions.md b/docs/design/open-decisions.md index 13a776c..dba7da2 100644 --- a/docs/design/open-decisions.md +++ b/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