tane/docs/design/network-trust.md

# Tanemaki — Red, confianza y mensajería (capa social descentralizada)

*Nota de diseño (discusión). Resuelve los huecos 2–6 del anexo de [VISION.md](../../VISION.md): cómo arranca la red, cómo se teje la confianza, quién sostiene el descubrimiento y cómo se comunican las personas. Se apoya en la Capa 3–4 del [PLAN.md](../../PLAN.md) y en [sharing-model.md](sharing-model.md).*

## 1. Arranque en frío: sembrar en lo físico (hueco 2)

Una app de compartición local no sirve si eres la única persona en 50 km. Dos motores lo resuelven:

- **Utilidad en solitario.** El inventario vale **sin red**: la gente adopta la app para su uso personal (su banco en el bolsillo), y la red social crece *por debajo*. No hace falta masa crítica para empezar a usarla. Esto amortigua el arranque en frío mejor que ninguna campaña.
- **Siembra física.** Ferias de intercambio, **mercados**, colectivos agroecológicos, Red de Semillas: ahí se junta gente que **ya** comparte semillas. Llevar la app a esos espacios crea comunidades locales de golpe. El plan de adopción es presencial, no digital.

**Sinergia clave:** los encuentros físicos arrancan a la vez la **red** y la **confianza** (§2) — te certificas cara a cara, en la feria.

**Primer campo de prueba: los grupos de semillas de Ğ1.** En la comunidad Ğ1 ya hay grupos de semillas, pero les falla la app y la red para intercambiar. Son el **piloto ideal**: comunidad motivada, afín, **ya en red y con confianza (WoT) y moneda (Ğ1) montadas** — solo les falta la herramienta. Para ese subconjunto, el arranque en frío está casi resuelto. Detalle en [g1-integration.md](g1-integration.md).

## 2. Red de confianza estilo Duniter (huecos 3 y 4)

Modelo inspirado en **Duniter / Ğ1**: cualquiera participa desde el minuto uno, pero empieza como **"desconocido"**. Cuando **N personas** que ya son miembros te **certifican** (una firma: "doy fe de esta persona"), entras en el área de **"gente conocida"** (miembro de la red de confianza). Duniter usa ~5 certificaciones + una regla de distancia; el umbral es un **parámetro ajustable**.

- **Certificar = acto presencial y consciente** ("te conocí, respondo por ti"). Encaja con §1: las ferias generan certificaciones.
- **Resuelve el arranque de confianza (hueco 3):** al recién llegado no se le bloquea, solo se le marca como desconocido hasta acumular avales.
- **Resuelve la moderación (hueco 4):** spammers y estafadores se quedan en "desconocido" y se filtran o despriorizan solos; la red de confianza pone en cuarentena **sin autoridad central**. Encima se suma la **reputación** (valoraciones tras un trato cerrado).
- **UI para 10–80:** mostrar "conocido / desconocido" con lenguaje humano ("aún nadie de tu confianza responde por esta persona"), nunca jerga de grafos.

*A decidir:* umbral de certificaciones (¿5?), regla de distancia, caducidad de certificaciones, y si un banco/colectivo puede certificar como entidad.

## 3. Relays y descubrimiento: ¿la app como relay? (hueco 5)

El problema: encontrar ofertas sin índice central depende de nodos (relays), que cuestan. Respuesta en tres piezas, de menos a más infraestructura:

1. **Proximidad física primero.** En una feria o mercado, dos móviles intercambian **directamente** (red local, Bluetooth, QR) sin ningún relay. Para el cara a cara, **cero infraestructura**.
2. **La app como peer que propaga.** Cada instancia, cuando está online, puede reenviar y almacenar temporalmente eventos de su entorno: un **relay ligero oportunista**. Reduce la dependencia de servidores. (Los móviles solos no bastan —offline a ratos, tras NAT, batería—, pero ayudan.)
3. **Relays comunitarios de respaldo.** Unos pocos nodos siempre encendidos, **baratos**, hospedados por colectivos, redes de semillas o Comunes —nunca una empresa—. Dan fiabilidad. Coste **distribuido** y afín al ethos.

Respuesta a tu pregunta: **sí, la app puede ser relay** (parcial/oportunista), combinado con proximidad física y algún relay comunitario. No es cero-infraestructura, pero sí distribuida, barata y opcional.

## 4. Mensajería en la app (hueco 6, reformulado — y es grande)

Para cerrar tratos hace falta **mensajería dentro de la app** (como Wallapop u otros). Sin ella, la gente tendría que intercambiar teléfonos —fuga de datos personales— y se rompe el seudonimato. Es un **hueco importante** que hay que asumir.

- **Ya estaba entrevisto:** el mockup `10_chat.png` tiene pantalla de chat.
- **Diseño:** mensajería **1:1 cifrada**, sobre la **misma identidad y transporte** (mensajes directos cifrados de Nostr, NIP-17). **No es un sistema aparte**: reusa claves y relays. Mantiene el seudonimato (no das el teléfono).
- **Es de core** (`commons_core`): una biblioteca de cosas también necesita mensajería. Va al motor común.
- **Alcance v1:** 1:1 atado a una oferta/contacto. Grupos (banco colectivo) más tarde.
- **Es una funcionalidad grande** (entrega, offline, cifrado, spam). Apoyarse en NIP-17 reduce el trabajo, pero hay que dimensionarla. La red de confianza (§2) filtra también el spam de mensajes.

*Nota sobre "autenticidad de la variedad"* (el hueco 6 original): se resuelve por **confianza + procedencia** (ya cubierto), no por prueba técnica. El hueco real que destapaste es la **mensajería**.

## 5. Consecuencia importante para el plan

Esta capa social —ofertas + **mensajería** + relays + red de confianza— es **indivisible y grande**: no se puede "compartir un poco". Todo va junto y es interdependiente. Esto tiene peso para las fases (ver [open-decisions.md](open-decisions.md), "qué chirría"): la Fase 1 (inventario) es entregable sola y sólida; la parte social es un **salto grande**, no un incremento pequeño. Conviene reflejarlo en el plan y en la solicitud de financiación.