tane/docs/design/g1-integration.md

# Tane — Integración opcional de Ğ1 (moneda libre)

*Nota de diseño (discusión). Explora integrar opcionalmente la moneda libre Ğ1 (Duniter) para facilitar intercambios, sin excluir el regalo, el Plantare, el trueque ni otras monedas. Conecta con [sharing-model.md](sharing-model.md) §4 y con [network-trust.md](network-trust.md) §2.*

## Por qué Ğ1 encaja como ninguna otra moneda

No es un añadido oportunista: hay **tres coincidencias profundas**.

1. **Misma red de confianza.** Tane ya adopta una WoT **estilo Duniter** (network-trust §2). Ğ1 *es* esa WoT hecha moneda. Integrarla no es pegar un sistema ajeno: es la misma filosofía expresada como dinero.
2. **Misma ética.** Ğ1 es libre, descentralizada, no especulativa (dividendo universal, no acumulativa). Casa con el proyecto donde el euro no llega, y resuena con el espíritu del Plantare ("mantener en circulación, no acaparar").
3. **Mismo stack, y experiencia propia.** Duniter v2 (lanzado el 7 de marzo de 2026, sobre Substrate) trae **Ğecko**, cartera móvil en **Flutter** —igual que Tane—, y **Ğ1nkgo**, del propio autor de este proyecto. Hay código Dart/Flutter y conocimiento directo que reutilizar: la integración **no parte de cero**.

## El gradiente de reciprocidad

Tane no elige "regalo vs. dinero": ofrece un **abanico**, del más procomún al más convencional, y la interfaz lo presenta en ese orden (lo comunitario primero):

**regalo → Plantare (devolver algo similar) → trueque → Ğ1 (moneda libre) → euro (moneda convencional)**

Ğ1 se sitúa como la **opción de dinero afín a los valores** — la que uno *preferiría* mostrar frente al euro, sin prohibir ninguna. Todas conviven; ninguna es obligatoria.

## Ğ1 como primer campo de prueba (y solución al arranque en frío)

En la comunidad Ğ1 **ya hay grupos de semillas**, pero lo que falla es justo **la app y la red para intercambiar**. Es decir: existe una comunidad motivada, afín en valores, **ya en red y con confianza montada (la WoT) y con moneda (Ğ1)** — a la que solo le falta la herramienta que Tane construye. Esto convierte a los grupos de semillas de Ğ1 en el **piloto perfecto**:

- **Resuelve el arranque en frío (hueco 2 de VISION)** para ese subconjunto casi de un plumazo: no hay que crear la comunidad ni la confianza, ya existen; se les da la pieza que falta.
- **Prueba las tres capas a la vez con gente real:** inventario, compartición y —único sitio donde podemos probarlo de verdad— la **integración Ğ1** (niveles 1–3) y la WoT compartida.
- **Feedback de calidad:** son usuarios exigentes y alineados, buenos para pulir antes de abrir a un público más amplio (Red de Semillas, ferias, gente de 80 sin Ğ1).

Estrategia sugerida: **primer piloto dentro de los grupos de semillas de Ğ1**, y desde ahí ampliar a la Red de Semillas y al público general (que no necesita Ğ1). No convertir a Ğ1 en el único público, pero sí en la **primera comunidad**.

## Principios de la integración

- **Opcional y plural.** Ğ1 es *una* opción más. Nunca obligatoria, nunca el defecto. El regalo y el Plantare siguen siendo de primera clase.
- **Sin custodia ni rieles de pago en la app** (coherente con sharing-model §4.3). Tane **no** mueve fondos: anuncia y conecta; el valor se transfiere en la **cartera del usuario** (Ğecko/Cesium²/Ğ1nkgo), fuera de la app. Así seguimos siendo infraestructura neutral, sin KYC/AML.
- **Inclusión intacta.** Usar Tane **no** exige ser miembro de Ğ1. La persona de 80 que solo cambia tomates no toca Ğ1 jamás. Ğ1 es una **capa opcional** para quien ya está en ese mundo.
- **Acoplamiento con cuidado.** Reusar la WoT/identidad de Ğ1 es potente, pero no debe volver a Tane dependiente de Duniter para funcionar. Ğ1 informa/enriquece; no manda.

## Niveles de integración (de menos a más)

1. **Precio en Ğ1 (ya cabe hoy).** `price_currency` admite Ğ1: una oferta puede valer "50 Ğ1". Sin pago en la app; la transferencia va aparte, como el efectivo. **Coste técnico casi nulo** — ya está en el modelo (sharing-model §4.4).

2. **Enlace a la cartera (deep-link).** Botón "Pagar en Ğ1" que abre **Ğecko / Cesium² / Ğ1nkgo** con destinatario e importe ya rellenos (URI de pago). La app no toca fondos; solo entrega el testigo. Riesgo bajo, UX buena — y conoces esos esquemas de URI de primera mano.

3. **Identidad y confianza compartidas (la sinergia profunda).** Como la WoT de Duniter v2 está en cadena e indexada (duniter-squid, GraphQL), Tane podría **opcionalmente** vincular tu identidad Ğ1 e **importar tu pertenencia y certificaciones** como señal de confianza: un miembro Ğ1 llega **pre-avalado** a Tane. Pero manteniendo la WoT propia y ligera para quien no es de Ğ1 (inclusión). Ğ1 como **fuente opcional de confianza que suma**, no como requisito.

4. **Pago dentro de la app (descartado).** Firmar transferencias Ğ1 desde Tane cruzaría la línea de "sin rieles de pago" y añadiría custodia/complejidad. Mejor el nivel 2 (delegar en la cartera).

## La WoT: independiente pero compatible (respuesta a "¿podría ser compatible?")

La disyuntiva no es "depender de Ğ1" (fácil, pero excluye a los no-Ğ1 y acopla) contra "independiente" (inclusivo, pero costoso de construir). Hay un **punto medio**, como el correo electrónico —tu propio servidor, pero compatible con SMTP—: **una WoT propia de Tane, estructuralmente compatible con la de Duniter.** Y ser compatible **abarata** lo difícil, porque reutilizas diseño probado y tu propio código.

Cómo se logra:

1. **Mismo primitivo de identidad.** Usar el mismo tipo de clave que Duniter v2 (cuentas Substrate). Así una identidad Ğ1 es técnicamente comprensible por Tane y **reutilizas la cripto de Ğ1nkgo/Ğecko**, sin depender de la red Ğ1.
2. **Mismo modelo de certificación.** Modelar la WoT de Tane como la de Duniter (certificaciones firmadas "A avala a B", regla de N certificaciones + distancia). Es una WoT estilo Duniter, pero **tu propia instancia/grafo**. Esto abarata el "hazlo independiente": reutilizas un diseño probado desde 2017, no inventas uno.
3. **Importar la WoT de Ğ1 en un solo sentido.** Leer el grafo on-chain de Ğ1 (duniter-squid, GraphQL) para *informar* la confianza en Tane: un miembro Ğ1 llega **pre-avalado**. Tane **no escribe** en la cadena de Ğ1 (eso sí acoplaría). Import unidireccional = compatible **sin** dependencia.
4. **Una sola clave para todo (como en Duniter).** Una única identidad —una clave Duniter-v2/Substrate— hace *todo*: perfil, ofertas, mensajes, certificaciones y, si te opt-in, pagos Ğ1 y pertenencia a la WoT. Nada de claves separadas por función. **Tener la clave ≠ ser miembro de Ğ1:** una persona no-Ğ1 (la abuela) tiene una clave que simplemente **no está certificada** en la WoT (= "desconocida", encaja con network-trust §2) y nunca toca la moneda. Un miembro Ğ1 **reusa su misma clave** y llega pre-avalado. Así, una sola clave *e* inclusión total.

*Privacidad y peor caso legal:* usar la misma clave enlaza tu actividad de semillas con tu identidad Ğ1 pública. Para la mayoría (tomates en España) es indiferente. Para el caso sensible, la protección real es que **tener no es publicar**: las variedades delicadas viven **locales y cifradas**, y publicar una oferta es opt-in por ítem — así la clave nunca las expone en la red. Como escape adicional, quien *publique* algo sensible y no quiera ligarlo a su Ğ1 puede usar una **clave seudónima distinta** (opción avanzada), pero la norma es **una sola clave**.

**Resultado: instancia independiente, estándar compartido, una sola clave.** Funciona sin Ğ1 (incluye a la abuela), interopera con Ğ1 (miembros y certificaciones cuentan) y reutiliza tu código. Lo "difícil" se vuelve asequible por ser compatible.

## Recomendación

Empezar por los niveles **1 y 2** (precio en Ğ1 + enlace a la cartera): casi gratis, sin custodia, y ya dan una experiencia real "vendo/cambio por Ğ1, pago en mi cartera". El nivel **3** (reusar la WoT de Ğ1 como fuente de confianza) es la joya, pero es diseño de la capa social (Fase 3) y decisión mayor — se aborda en la ronda social, no ahora.

## Notas técnicas

- **Duniter v2 = Substrate/Rust.** Identidades = cuentas Substrate; WoT y certificaciones **en cadena**, consultables vía **duniter-squid (GraphQL)**.
- **Cliente Dart/Flutter** ya existente en el ecosistema (Ğecko, Ğ1nkgo) → reutilizable en `commons_core` como módulo opcional de "moneda/confianza Ğ1".
- **Deep-links de pago** hacia las carteras v2 (a confirmar los esquemas URI actuales de Ğecko/Cesium²).
- Encaje arquitectónico: el soporte de Ğ1 vive en `commons_core` (identidad/pago/confianza son genéricos), tras una interfaz, para no acoplar el núcleo a un único sistema.

## Decidido

- **Reutilizar el código de Ğ1nkgo/Ğecko** (Dart/Flutter) para la parte Ğ1 (cripto, identidad, WoT). Sí.
- **Ğ1 por delante del euro** en la interfaz (orden por valores). Sí.
- **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.

**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:** 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?
- Formato de certificación propio, mapeable al modelo Duniter.