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: 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 y en 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.

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, "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.