Add VISION and design docs (backup/recovery, G1 integration, network trust, security/privacy, open decisions); update domain boundary and data notes
This commit is contained in:
parent
59beadc03c
commit
8286d1fec8
8 changed files with 496 additions and 5 deletions
56
docs/design/open-decisions.md
Normal file
56
docs/design/open-decisions.md
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
# Tanemaki — Decisiones abiertas y "qué chirría"
|
||||
|
||||
*Revisión de conjunto antes de seguir construyendo. Reúne los cabos sueltos repartidos por los docs de diseño, ordenados por cuándo hay que decidirlos, y nombra las tensiones del plan que conviene mirar de frente.*
|
||||
|
||||
## A) Decidir antes de escribir código de la Fase 1 (inventario)
|
||||
|
||||
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)
|
||||
- **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
|
||||
- **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
|
||||
- **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
|
||||
- **Reputación** atada a un trato/oferta cerrada (evitar reseñas falsas). → sharing-model §6
|
||||
- **Precio:** ¿monedas comunitarias / de tiempo además de dinero? → sharing-model §6
|
||||
- **Integración Ğ1 (moneda libre):** niveles 1–2 (precio en Ğ1 + enlace a cartera Ğecko/Cesium²/Ğ1nkgo) en la capa social; nivel 3 (reusar la WoT de Ğ1 como fuente de confianza) como estudio aparte. → [g1-integration.md](g1-integration.md)
|
||||
- **Ofertas de banco colectivo** (publica la entidad, no la persona). → sharing-model §6
|
||||
- **Caducidad/revocación** de ofertas ya replicadas en relays. → sharing-model §6
|
||||
|
||||
## C) Puede esperar (no bloquea nada ahora)
|
||||
|
||||
- Negación plausible / bóveda señuelo; modo discreto. → security-privacy
|
||||
- Reconocimiento por foto en la varilla.
|
||||
- Respaldo social distribuido entre contactos.
|
||||
- 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
|
||||
|
||||
## D) Qué chirría (tensiones a mirar de frente)
|
||||
|
||||
1. **La capa social es indivisible y grande.** "MVP = inventario + compartición local" subestima que "compartir" de verdad = **ofertas + mensajería + relays + red de confianza**, todo junto e interdependiente. Propuesta: replantear las fases como **(1) inventario** —entregable, sólido, en solitario— y **(2) el salto social** —un bloque grande, no un incremento—. Ser honestos con esto en el plan y en la financiación.
|
||||
|
||||
2. **Casi toda la dificultad vive en `commons_core`.** Identidad, sync CRDT, ofertas, pledge, red de confianza, **mensajería**, relays… `app_seeds` es, en comparación, ligero. En el fondo Tanemaki es **infraestructura de procomún** con las semillas como primera aplicación. Es buena noticia para NLnet/NGI Zero (financian infraestructura), pero hay que asumir que lo "sencillo" (semillas) es la punta del iceberg y comunicar el proyecto en consecuencia.
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
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)
|
||||
|
||||
## Recomendación de orden
|
||||
|
||||
Cerrar el bloque **(A)** — son pocas decisiones y desbloquean construir el inventario, que es valioso por sí solo y de bajo riesgo. Dejar **(B)** para una ronda de diseño específica de la capa social (con su propia financiación si llega). Y asumir explícitamente el punto **(D.1)**: replantear las fases para que "lo social" sea un hito grande y no una coletilla del MVP.
|
||||
Loading…
Add table
Add a link
Reference in a new issue