tane/docs/design/network-trust.md

Tane — 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. Confianza egocéntrica (huecos 3 y 4)

Revisión 2026-07-11. La primera versión de esta sección proponía la regla global de membresía de Duniter (N certificaciones + distancia desde referentes fundadores curados). Se descartó: esa regla resuelve identidad sybil-proof para una renta básica — un problema que Tane no tiene — y exige curar referentes por comunidad/país, inviable en una app internacional (¿quién cura los fundadores de Japón, Brasil, Marruecos?). Un set de referentes malo es peor que ninguno. Ver open-decisions.md.

Modelo egocéntrico: los avales ("doy fe de esta persona") son públicos, firmados y compartidos — todo el mundo ve el mismo grafo — pero no hay veredicto global: cada persona calcula la confianza desde su propia posición. Es el modelo que funcionó en la práctica en PGP (la validez se calcula desde TU clave) y el que usa el ecosistema Nostr ("seguido por gente que sigues").

• Certificar = acto presencial y consciente ("te conocí, respondo por ti"). Encaja con §1: las ferias generan avales. En la UI es un toque: "Conozco a esta persona", en el chat.
• Tu círculo: tú, la gente que avalas, y la gente que ellos avalan (distancia ≤2). El chat lo muestra en humano: "En tu círculo" / "Avalada por N" / "Nadie la avala aún".
• Cold-start resuelto de raíz (hueco 3): valor desde el primer aval, día uno, en cualquier país. Un colectivo arranca su propio racimo sin pedir permiso ni esperar referentes. Al recién llegado no se le bloquea, solo se le marca como desconocido.
• Moderación sin autoridad central (hueco 4): un atacante puede crear mil claves que se avalen entre sí, pero ese racimo queda desconectado de tu vista — siguen siendo desconocidos para ti. Para colarse en tu círculo necesita un aval presencial de alguien de tu entorno (la escasez de "aristas de ataque" protege por observador, como en la investigación anti-sybil por grafo social). Los avales son públicos: avalar a un estafador tiene coste social. Caducan (365 días) y se renuevan, podando confianza rancia.
• Reputación encima: valoraciones tipo Wallapop (§2.1).
• UI para 10–80: "Tu gente" (a quién avalas / quién te avala), lenguaje humano, nunca jerga de grafos ni parámetros.

Qué se pierde honestamente: el badge global "miembro de la red" y la garantía una-persona-una-identidad — herencia del problema de Duniter (RBU), no del nuestro. Puerta no quemada: el primitivo de certificación sigue siendo estructuralmente compatible con Duniter (una certificación viva por par, con caducidad); una capa futura de "confianza por comunidad" (una red de semillas define sus propias raíces y su propia regla) o una importación opcional de la WoT de Ğ1 pueden construirse encima del mismo motor sin migración.

2.1 Reputación: valoraciones tipo Wallapop

Los avales no cubren la estafa desde dentro del círculo; las valoraciones sí. V1 (implementada): estrellas 1–5 + comentario corto sobre una persona, públicas y firmadas; una valoración viva por par (re-valorar edita, no acumula — un mismo autor no puede amontonar reseñas); retirable. Anclaje blando: solo puedes valorar a alguien con quien tienes conversación. Se muestran en el detalle de oferta y en el chat, ponderadas por tu círculo ("N de gente que conoces") — las reseñas de desconocidos no se destacan, así que inflarlas con claves falsas no sirve de nada. Evolución prevista: anclaje fuerte a un trato cerrado con el formulario bilateral firmado (ver sharing-model.md §6).

A decidir: si un banco/colectivo puede certificar como entidad (ver sharing-model §6).

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.