comunes/tane
1
0
Fork 0
Code Issues Pull requests Projects Releases 7 Packages Wiki Activity Actions

Fix naming (Seedks->Tanemaki) in PLAN; reconcile data-model with core/domain boundary (Plantare->Pledge, Movement->LedgerEntry notes); fix quantity_label type nit; note social layer as one indivisible block in VISION; add seedks.ttf asset

Browse source
This commit is contained in:
vjrj 2026-07-07 11:06:38 +02:00
parent 8286d1fec8
commit e4ccffe168
5 changed files with 14 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/design/g1-integration.md
View file

@ -78,11 +78,11 @@ Empezar por los niveles **1 y 2** (precio en Ğ1 + enlace a la cartera): casi gr
- **WoT propia pero compatible con Duniter** (no dependiente, no independiente-desde-cero): mismo primitivo de identidad + mismo modelo de certificación + import unidireccional de la WoT de Ğ1.
- **Una sola clave para todo**, tipo Duniter-v2/Substrate (perfil, ofertas, mensajes, certificaciones, Ğ1). Sin claves por función. Clave seudónima distinta = solo opción avanzada para publicar algo sensible.
**Consecuencia honesta (a mirar):** una sola clave Duniter/Substrate **debilita el encaje de Nostr** como transporte — la identidad de Nostr *es* su clave secp256k1, y no es la nuestra. O bien Nostr queda como transporte "tonto" con nuestro propio sobre firmado (perdiendo el ecosistema NIP), o bien conviene **apoyar ofertas/mensajería en el ecosistema Duniter** (datapods/indexadores firmados con la misma clave) o en un transporte **agnóstico a la clave**. Se replantea en la ronda social (no bloquea la Fase 1). → [open-decisions.md](open-decisions.md) D7.
**Resuelto — "una sola clave" *y* Nostr, vía derivación:** los datapods de Duniter **no están en servicio**, así que para el transporte (Nostr) sí necesitamos una clave **secp256k1**. La solución que mantiene "una sola identidad": la secp256k1 se **deriva determinísticamente** de la semilla raíz Ğ1 (como las carteras multi-cadena derivan claves de varias curvas de una misma mnemónica; precedente: Cesium deriva sus claves de cifrado de la de firma). El usuario respalda **una sola cosa** (el QR de la semilla Ğ1); la secp256k1 se regenera cuando hace falta. Así **Nostr vuelve a ser transporte viable** (NIP-99/17/85) sin gestionar dos claves ni depender de infraestructura muerta. La derivación es **unidireccional**: desde la secp256k1 pública no se puede llegar a la identidad Ğ1 (aunque el uso simultáneo podría correlacionarse — para eso queda la clave seudónima aparte del peor caso).
## A decidir (pendiente)
- **Transporte de la capa social** dado "una sola clave Duniter": ¿datapod/indexador estilo Duniter, transporte agnóstico, o Nostr como mero relay? (Revisar; sustituye la inclinación previa "Nostr primero".)
- **Transporte de la capa social:** Nostr vuelve a ser viable (secp256k1 **derivada** de la semilla Ğ1). Confirmar Nostr para ofertas/mensajería/WoT y su madurez. (Datapods de Duniter descartados: no están en servicio.)
- Ruta/dominio de derivación de la secp256k1 desde la semilla raíz (que sea estándar y unidireccional).
- ¿Nivel 3 (import de la WoT de Ğ1) entra en la primera ronda de la capa social o en una posterior?
- ¿`sr25519` o `ed25519` (lo que use Duniter v2) para la clave única?
- Formato de certificación propio, mapeable al modelo Duniter.