Red social descentralizada gobernada por teoría de juegos, mediada por agentes de IA con principios éticos, optimizada para cooperación en lugar de conflicto.
Este documento describe por qué existe Hispania, qué quiere construir, y las decisiones abiertas de arquitectura que se irán resolviendo con iteraciones reales.
01
Las redes sociales son la infraestructura de circulación de información de la civilización. Quien controla el algoritmo controla qué ideas se propagan y cuáles mueren. Hoy ese algoritmo lo controlan cuatro empresas, y en las cuatro la función objetivo es la misma: maximizar tiempo en pantalla para vender publicidad.
El efecto está documentado y es devastador. Las plataformas amplifican contenido que genera reacción emocional intensa — indignación, miedo, desprecio — porque ese contenido retiene atención. El conflicto visible entre dos personas genera más engagement que la cooperación. El resultado es que las redes actuales sistemáticamente ocultan lo que los humanos comparten y amplifican las diferencias.
La polarización, la desinformación, la ansiedad y la erosión de la confianza social son consecuencias directas de una función de optimización que trata la atención humana como recurso extractivo.
Para 500 millones de hispanohablantes, añádele:
02
Visión: una red cuya función de optimización trabaja a favor de los individuos.
La información valiosa llega a quien la necesita con mínima fricción, donde los conflictos destructivos se amortiguan, donde la cooperación es más visible que el conflicto, y donde nadie controla el algoritmo porque el algoritmo es un protocolo abierto.
Misión:
«La tecnología no puede dejar atrás a quienes no la dominan. Nos apoyamos porque la colaboración nos beneficia a todos.»
03
Ideas similares se han intentado antes y han fracasado. Dos cosas han cambiado que hacen esto viable hoy:
Los agentes de IA (Claude Code, OpenClaw, Cursor, etc.) pueden escribir, depurar y desplegar software complejo. Un individuo con criterio y agentes produce al nivel de un equipo de 20 ingenieros. Esto elimina la necesidad de levantar capital para construir. Sin necesidad de capital no hay inversores ni presión de retorno. Sin presión de retorno, el sistema puede optimizar para lo que importa.
El ciclo cripto 2017-2023 fracasó precisamente por esto: necesitaba millones para construir, emitía tokens para financiarse, y el token convertía toda coordinación en especulación. Esa barrera ya no existe.
Los componentes necesarios existen, están probados y son de código abierto. No hay que inventar nada fundamental. Hay que componerlos con la función de optimización correcta.
| Función | Qué resuelve | Estado |
|---|---|---|
| Nostr | Identidad criptográfica + transporte de mensajes sin servidor central | Productivo. Millones de usuarios. |
| Nombres descentralizados (ej. ENS, Unstoppable Domains) | Nombres legibles para identidades criptográficas | Productivo. Estándares maduros. |
| Cadenas con contratos inteligentes (ej. Ethereum L2, NEAR, Solana) | Smart contracts baratos para acuerdos verificables | Productivo. Fracciones de céntimo por tx. |
| OpenClaw | Agente personal de código abierto, local-first | Productivo. 190k+ estrellas GitHub. |
| IPFS | Almacenamiento descentralizado de datos sin servidor central | Productivo. Estándar consolidado. |
| SingularityNET | Marketplace descentralizado de servicios de IA | Activo. Menos maduro. |
| Bitcoin + Lightning | Settlement final. Micropagos. | Productivo. |
La innovación de Hispania es componer estas herramientas con una función de optimización que prioriza cooperación sobre conflicto, mediada por agentes que tienen principios éticos incorporados.
04
La arquitectura tiene cinco capas. Es una propuesta inicial — cada capa tiene decisiones abiertas que se resolverán con iteraciones reales, no con teoría.
| Capa | Qué hace | Propuesta | Alternativas |
|---|---|---|---|
| Identidad | Cada persona es dueña de su identidad y su grafo social | Nostr (claves) + nombres descentralizados (ej. ENS) | AT Protocol (Bluesky), DID estándar W3C |
| Agentes | Interfaz persona ↔ red. Filtra, prioriza, negocia, ejecuta | OpenClaw + Claude/modelos locales | Agentes custom, otros frameworks |
| Coordinación | Acuerdos verificables entre agentes sin intermediario | Cadena con contratos inteligentes (ej. Ethereum L2, NEAR) | Otras cadenas, sin blockchain al inicio |
| Optimización | La función objetivo que gobierna el grafo (ver sección 5) | Agentes especializados | Por definir — pieza crítica |
| Verificación | Validación de información, settlement final | Mercados de predicción + Bitcoin | Sistemas de reputación, ZK proofs |
| Persistencia | Almacenamiento descentralizado de datos no personales | IPFS | Soluciones híbridas, Arweave |
DECISIÓN ABIERTA: Empezar con o sin blockchain.
Opción A: empezar solo con Nostr (cero coste, cero complejidad) y añadir blockchain si facilitara gobernanza/tokens. Opción B: desplegar tokens soulbound desde el inicio para tener reputación on-chain desde el día uno. Opción C: empezar con sistema centralizado simple (base de datos + API) y descentralizar progresivamente. Criterio: lo que permita tener 50 usuarios reales más rápido.
05
Esta es la pieza central que distingue a Hispania de cualquier otra red social.
Las redes actuales optimizan: maximizar tiempo en pantalla. Hispania optimiza dos cosas complementarias:
Dado un grafo donde los nodos son personas (vía sus agentes) y las aristas son flujos de información: minimizar la energía desperdiciada en interacciones que destruyen valor sin generar información nueva.
En la práctica, esto significa tres cosas:
DECISIÓN ABIERTA: Cómo medir la función de optimización.
El mayor riesgo del proyecto es que «mínima fricción, máximo beneficio» suene bien pero no se pueda medir. Necesitamos métricas proxy que sean robustas a la manipulación. Candidatas: ratio de intercambios validados por receptor, índice de diversidad de interacciones, velocidad de resolución de necesidades, ratio de retención sin mecanismos adictivos. Esto se definirá experimentalmente con los primeros 50 usuarios.
06
Cada persona en Hispania interactúa con la red a través de un agente de IA que absorbe la complejidad técnica para que el usuario solo vea una conversación natural.
Un agente que optimiza para su usuario a costa de todos los demás destruye la red. Si mi agente miente para beneficiarme, y el tuyo hace lo mismo, el resultado agregado es peor para todos. Es un dilema del prisionero clásico.
La solución: el agente tiene principios éticos incorporados en su diseño. Anthropic lo llama «soul document» en Claude. En la práctica son cuatro restricciones:
Es por diseño de mecanismos: si todos los agentes siguen estos principios, el equilibrio resultante es cooperativo. Si no, la red degenera en guerra de bots.
El sistema asume que los agentes actúan correctamente (optimistic) y verifica a posteriori. Los mecanismos de detección incluyen honeypots — interacciones diseñadas para exponer comportamiento deshonesto — y auditoría estadística. Cuando se detecta engaño, la consecuencia es pérdida de reputación tanto del agente como de su usuario. Dado que la reputación no se compra, el coste de reconstruirla es tiempo real de contribución legítima. Esto elimina el incentivo de hacer trampa: el beneficio de un engaño puntual nunca compensa meses de reputación destruida.
El agente de Hispania parte de un fork de OpenClaw (o de una de sus versiones simplificadas y auditadas). Es un agente personal de código abierto que corre localmente y se conecta a Telegram, Signal, Discord y más. 190.000+ estrellas en GitHub, crecimiento explosivo, comunidad activa. Es model-agnostic: funciona con Claude, GPT, modelos locales. El fork incorpora el documento de alma desde el primer momento — los principios éticos no son una capa añadida después, sino están literalmente escritos en la implementación.
07
El principio básico: tu identidad es tuya. Si cualquier plataforma te banea, tu identidad persiste. Si Hispania desaparece, tu identidad persiste.
La propuesta usa dos capas:
El usuario no necesita entender nada de esto. Llega, hace login con Google/Apple/email, y el sistema crea su identidad criptográfica en segundo plano. Sin seed phrase, sin extensiones. Se aprovechan las soluciones de abstracción de cuentas que se están desarrollando en Nostr, donde múltiples métodos de acceso se enlazan a una única identidad criptográfica. El usuario ve una interfaz de chat, no un par de claves.
La reputación es la moneda real del sistema. No un token especulativo. Es un registro no transferible de cuánto has contribuido.
| Propiedad | Valor |
|---|---|
| Transferible | No. No se compra, no se vende, no se hereda. |
| Cómo se gana | Ayuda directa (validada por receptor), contenido, curación, código, auditoría, traer comunidades. |
| Cómo se pierde | Fraude detectado en auditoría aleatoria o por honeypot. |
| Para qué sirve | Peso en decisiones de gobernanza. Credibilidad dentro de la red. Acceso a funciones avanzadas. |
| Implementación | Token soulbound en cadena L2 (propuesta). O base de datos centralizada inicial. |
| Recuperable | Sí. Mediante recuperación social: si un usuario pierde acceso a su clave, su reputación puede migrarse a una nueva identidad con el aval de validadores de confianza. |
DECISIÓN ABIERTA: Reputación on-chain vs. off-chain al inicio.
On-chain (token soulbound) da inmutabilidad y portabilidad desde el día uno, pero añade complejidad técnica. Off-chain (base de datos) es más simple y permite iterar rápido, pero depende de un servidor central. Posible híbrido: off-chain para iterar, con snapshots periódicos anclados on-chain.
08
El ataque Sybil — crear identidades falsas para manipular el sistema — es el riesgo existencial de toda comunidad descentralizada con onboarding abierto. El diseño de Hispania asume que crear cuentas falsas es trivial y se centra en hacerlo inútil.
| Nivel | Qué puede hacer | Cómo se alcanza | Coste Sybil |
|---|---|---|---|
| Visitante | Participar, pedir ayuda, leer | Login con Google/Apple/email | Trivial. Pero no gana nada. |
| Miembro | Acumular reputación, tener nombre descentralizado | Aval de miembro existente O umbral de ayuda validada | Requiere convencer a un humano real. |
| Ciudadano | Votar en decisiones fundamentales | Reputación alta + diversidad de validadores | Prohibitivo. Meses de actividad legítima. |
09
Las DAOs mueren de apatía participativa. Pedir a la gente que vote propuestas abstractas es pedirles un segundo trabajo no remunerado. Hispania reserva el voto para decisiones irreversibles: quizá tres veces al año. El resto de la gobernanza ocurre orgánicamente a través de la actividad diaria: cada ayuda es un voto implícito sobre qué importa. Gobernanza por aclamación.
Importante: no es necesario ser miembro de la asociación para participar en Hispania. Se puede vivir en la red de forma seudónima o anónima, contribuir, acumular reputación y participar en la cámara de contribuidores. La cámara de ciudadanos es solo una de las dos cámaras, y existen vías alternativas de verificación de unicidad para quienes prefieran no asociarse.
Ambas cámaras deben aprobar. Es el contrapeso mínimo para que ni la élite ni la mayoría desinformada puedan capturar el sistema solos.
10
La financiación viene de: donaciones (con quadratic funding: muchas pequeñas pesan más que pocas grandes), servicios premium opcionales para comunidades, y subvenciones públicas (encaja en programas de cohesión social, digitalización, multilinguismo). Todo el código es abierto. La infraestructura es replicable.
El sistema empieza con 10-50 personas creando y participando de aplicaciones útiles. Si la información que recibes es mejor que en cualquier otro sitio, te quedas y traes a otros. Si no, el proyecto muere y no pasa nada. Selección natural. Escala por la misma razón que escalaron los protocolos de internet: porque son útiles, no porque son invertibles.
Hispania no sustituye comunidades existentes. Las conecta. Asociaciones locales, colectivos profesionales, comunidades de interés, clubs de pensamiento. Cada grupo mantiene su identidad. Hispania aporta herramientas, base legal y conexión con el resto. Cada nodo recibe recursos proporcionales a su actividad y decide internamente cómo usarlos.
A largo plazo: nodo hispanohablante como primer nodo de una red global de protocolos culturales. Los estándares se copian, no se imponen. Cada comunidad hace fork y lo adapta.
11
12
| Fase | Objetivo | Entregable concreto | Crítico para avanzar |
|---|---|---|---|
| 0 — Ahora | Validar que la tesis funciona sin tecnología | 50 historias de ayuda real entre personas reales. Blog/wiki en español. Comunidad Telegram activa. Otras RRSS | ¿Escala? |
| 1 | Prototipo con agentes | Agentes comunitarios (forks de OpenClaw interactuando en RRSS, contabilidad reputación, asesoría, mediación). Se suman agentes personales. | ¿Los agentes mejoran la coordinación realmente? |
| 2 | Descentralizar identidad y reputación | Nombres descentralizados + subdominios. Tokens soulbound. Mecanismos anti-Sybil activos. Primeras comunidades-nodo integradas. | ¿La descentralización añade valor o solo complejidad? |
| 3 | Gobernanza y escala | Dos cámaras operativas. Mercados de predicción para verificación. Apertura a nodos en otros idiomas. | ¿El modelo de gobernanza resiste la escala? |
Cada fase tiene una pregunta crítica. Si la respuesta es no, el proyecto pivota o muere. No hay compromiso con una arquitectura específica.
Identidad basada en Nostr. Primer punto de contacto: un bot agéntico desplegado simultáneamente en Telegram, Discord y otras plataformas mediante bridges. Este bot ejecuta las primeras funciones: registro de identidad, matching de ayuda, acumulación de reputación, primeras métricas de la función de optimización. Es la forma más rápida de testear el sistema de gobernanza y reputación con usuarios reales, sin exigir que cambien de plataforma.
Caso 1 — Ayuda con reputación. Alguien plantea un problema. Quien le ayuda recibe reputación validada por el receptor. Esa reputación es un token no transferible (soulbound) que da peso en decisiones de gobernanza. No se especula. Solo se gana ayudando.
Caso 2 — Construir juntos. La revolución tecnológica ha eliminado las barreras para crear, pero ha multiplicado la soledad del creador. Hoy cualquiera puede construir solo, pero lo que se construye solo rara vez sirve a otros. Las comunidades existentes giran en torno a líderes con incentivos desalineados. Hispania es el espacio neutral donde la contribución se mide, se reconoce y se traduce en productos reales que la gente usa de verdad.
Caso 3 — Mercado de segunda mano con confianza. Reputación inmutable: no puedes abandonar un perfil con malas valoraciones y crear uno nuevo. Mecanismos de subasta diseñados con teoría de juegos que facilitan acuerdos donde ambas partes ganan, generando transacciones que hoy no ocurren por desconfianza. Es una aplicación inmediata con demanda masiva.
Caso 4 — Desarrollo colaborativo de aplicaciones. Mucha gente está desarrollando aplicaciones que luego lanza en solitario en plataformas cada vez más saturadas. El coste de implementar una idea ha caído bruscamente, pero eso significa que las ideas por sí solas ya no son el diferencial — la capacidad de ejecutar en comunidad sí lo es. Hispania facilita que los creadores se encuentren, combinen habilidades y construyan juntos aplicaciones con tracción desde el día uno, porque nacen con una comunidad que las usa, las testea y las mejora.
Caso 5 — Fork de Alignment Forum / LessWrong. Un espacio de deliberación en español donde las ideas se debaten con profundidad, las contribuciones se valoran por calidad y no por viralidad, y la reputación ganada tiene peso real en la gobernanza de Hispania. La comunidad hispanohablante necesita su propio espacio de pensamiento riguroso sobre tecnología, ética e IA.
Caso 6 — Reputación como ventaja ante la automatización. Las profesiones de consultoría se enfrentan a una disrupción sin precedentes por la IA. Quien hoy ayuda en Hispania — resolviendo dudas legales, fiscales, técnicas, de salud — construye un historial de reputación verificable e inmutable. Cuando la automatización transforme estas profesiones, esa reputación será un activo invaluable: prueba objetiva de experiencia real con personas reales. Ser de los primeros en construirla es una ventaja estratégica.
Los casos de uso anteriores son ejemplos iniciales. Las aplicaciones concretas que Hispania construya las decidirá la comunidad. Existe un formulario abierto donde cualquiera puede proponer aplicaciones, votar las existentes y participar en la priorización. Este proceso es en sí mismo un ejercicio de la gobernanza que Hispania propone: decisiones colectivas basadas en utilidad real, no en la visión de un fundador.
13
| Riesgo | Severidad | Mitigación | ¿Resuelto? |
|---|---|---|---|
| A nadie le importa | Crítica | Fase 0 lo testea sin inversión. Si no hay 50 intercambios reales, no se sigue. | No. Es la hipótesis central. |
| Captura por oligarquía | Alta | Cámara de ciudadanos (1p=1v). Nadie imprescindible. | Parcialmente. Requiere masa crítica. |
| Ataque Sybil | Alta | Niveles progresivos + mecanismos defensivos + honeypots. | Diseño robusto. Faltará calibrar parámetros. |
| Agentes tramposos | Alta | Arquitectura optimista + honeypots + auditoría. Castigo reputacional disuasorio. | Gestionable. Carrera armamentística. |
| Complejidad técnica excesiva | Media | Agentes absorben complejidad. Empezar simple. Descentralizar progresivamente. | Depende de ejecución. |
| Falta de financiación | Media | Coste cercano a cero con agentes. Donaciones + subvenciones. | Viable si el equipo es pequeño. |
| La función de optimización no funciona | Alta | Diseño iterativo. Métricas desde el día uno. Pivote si no funciona. | No. Es la segunda hipótesis central. |
14
Este proyecto no tiene un diseño cerrado. Las siguientes decisiones se irán tomando con datos reales. Se listan aquí para que sea explícito qué está resuelto y qué no.
1. Identidad: ¿Nostr, nombres descentralizados, ambos, otro?
Propuesta: Nostr como base, nombres descentralizados (ej. ENS) como capa legible. Alternativa: AT Protocol (más maduro como red social, menos descentralizado). Depende de dónde estén los primeros usuarios.
2. ¿Blockchain desde el inicio o después?
Propuesta: empezar off-chain para iterar rápido, anclar on-chain cuando la reputación tenga masa crítica. Riesgo: migrar después es complejo.
3. ¿Qué cadena para coordinación?
Opciones con ecosistemas maduros: Ethereum L2, NEAR, Solana, Cosmos, BTC sidechain o algo propio. Criterios: coste por transacción, ecosistema de desarrolladores, interoperabilidad. Puede ser más de una.
4. ¿Cómo se mide el éxito de la función de optimización?
Sin métricas concretas, no hay forma de saber si funciona. Definirlas es la tarea más importante de la Fase 1.
5. ¿Cómo se garantiza el alma del agente?
Propuesta: fork de OpenClaw con documento de alma, arquitectura optimista con castigo reputacional. Honeypots + auditoría estadística + detección de anomalías. No hay solución perfecta — se gestiona, no se resuelve.
6. ¿Cuál es la interfaz del usuario?
Opciones: app nativa, web app, bot de Telegram/Discord (vía OpenClaw), o combinación. Depende de dónde estén los usuarios.
7. ¿Cómo se incorporan comunidades existentes?
Propuesta: cada comunidad mantiene su canal (Telegram, Discord) y Hispania se integra vía agentes-puente. Pero hay que validarlo.
8. Modelo económico sostenible.
Donaciones + quadratic funding + subvenciones + servicios premium. ¿Es suficiente? Se sabrá en Fase 1-2.