Basta de suplicar, pagando sin soberania, para comunicarte. La revolucion de los faros.

🗼

La revolución de los faros propios

Cómo dos aparatos olvidados en un placard pueden más que un datacenter de millones de dólares

🧉 XionIA — Comunicación libre desde el Sur Global

📖 Imaginate este pueblo

Imaginá un pueblo donde todas las cartas, todas las llamadas y todos los mensajes tenían que pasar por una sola oficina de correos. Una única oficina, en el centro del pueblo, manejada por una empresa extranjera.

El dueño de esa oficina podía:

• 👀 Leer tus cartas antes de entregarlas.
• 🚫 Decidir cuáles entregar y cuáles no.
• 🔇 Echarte del servicio si no le gustaba lo que decías.
• 💰 Vender tus datos a quien pagara.

Y lo peor: si esa oficina se caía, todo el pueblo se quedaba sin comunicarse. Nadie podía hablar con nadie.

Ese pueblo se llama Internet. Y esa oficina se llama WhatsApp, Telegram, Gmail, Facebook.

❌ El problema de siempre

Hoy, cuando tu hijo le manda un mensaje a la abuela, ese mensaje no va directo de su teléfono al de ella. Pasa por servidores gigantes en otro país. Servidores que alguien más controla, que pueden leer, guardar y vender lo que tu familia dice.

Durante años, la solución que nos vendieron fue: "protejamos esa gran oficina central con más candados". Más seguridad en el servidor. Más firewalls. Más equipos caros defendiendo el edificio.

Pero eso es defender la oficina del otro. Y mientras exista esa oficina, siempre habrá alguien que puede leer tus cartas.

🔦 La revolución: cada casa tiene su propia antorcha

En XionIA cambiamos la pregunta. En vez de "¿cómo defendemos la gran oficina?", nos preguntamos: "¿y si la oficina no hiciera falta?"

La respuesta fue crear los faros propios.

Un faro es como una antorcha en la ventana de tu casa. Su trabajo es simple: ayudar a que dos personas se encuentren para hablar. Cuando tu hijo quiere hablar con la abuela:

1. Tu hijo enciende su antorcha. 🔦
2. La abuela enciende la suya. 🔦
3. Los dos faros se ven, se saludan, y conectan directo las dos casas. 💬
4. A partir de ahí, la charla es solo entre ellos dos. Nadie más la ve.

No hay oficina central. No hay servidor gigante. No hay dueño extranjero leyendo tus cartas.

🏠 ¿Y quién puede tener un faro? Cualquiera.

Esta es la parte más linda de la revolución: tener un faro propio es fácil y barato. No necesitás ser ingeniero. No necesitás una empresa. No necesitás un datacenter.

Un faro puede funcionar en:

📺

Una TV Box
de esas baratas que venden en cualquier lado

💻

Una netbook vieja
esa que tenías guardada en el placard

📱

Una tablet
o cualquier dispositivo con internet

Es como cuando en el barrio cada vecino prendía su luz: ninguna empresa podía dejar a todo el barrio a oscuras de un solo golpe.

⚡ ¿Cuánta potencia tiene un faro?

Acá viene lo que parece magia, pero es pura matemática. Un faro no necesita ser una supercomputadora. ¿Por qué? Porque su trabajo es liviano: solo ayuda a que dos dispositivos se encuentren. Después, la charla va directo entre ellos.

Un solo faro modesto puede coordinar:

10.000+

dispositivos conectados a la vez

200 bytes

por cada señal (un susurro)

< 5 watts

de consumo eléctrico

Es como un cartero que solo entrega la invitación a la fiesta, pero no va a la fiesta. Hace su trabajo rápido, consume casi nada, y se queda libre para la siguiente invitación.

🏚️ Nuestro ejemplo real: dos carcachas

Y esto no es teoría. En un rincón de Argentina, desde una casa común y corriente, hoy están funcionando dos faros montados sobre hardware que mucha gente tiraría:

💻

Faro Maestro 01

Una netbook que dormía en un placard

• Procesador de 2 núcleos
• 4 GB de memoria
• Disco de 128 GB
• Batería propia (no se apaga si corta la luz) 🔋

📱

Faro Maestro 02

Una tablet que ya nadie usaba

• Procesador de 2 núcleos
• 4 GB de memoria
• Disco de 64 GB
• Batería propia (no se apaga si corta la luz) 🔋

Dos aparatos que iban a terminar en la basura. Hoy coordinan una red libre.

Con esos dos aparatos juntos, podemos dar servicio a

200.000 a 300.000

personas hablando al mismo tiempo

Consumiendo menos electricidad que una lamparita 💡

💸 ¿Y cuánto cuesta esto vs. lo tradicional?

Acá está la comparación que nadie te cuenta. Para darle comunicación a unas 300.000 personas al mismo tiempo:

Concepto	Servidores tradicionales	Dos carcachas XionIA
Hardware	Decenas de miles de dólares	Aprox. 150 dólares (o 0 si ya los tenés)
Alquiler de servidores / mes	Miles de dólares	0 (corre en tu casa)
Internet / mes	Miles de dólares (ancho de banda de datacenter)	Tu conexión de casa (ya la pagás)
Electricidad / mes	Miles de dólares + refrigeración	Menos de 2 dólares
TOTAL por año	Cientos de miles de dólares	Menos de 50 dólares

La misma cantidad de gente comunicándose. Una diferencia de miles de veces en costo.

* Cifras estimadas e ilustrativas para comparar órdenes de magnitud.

🤔 ¿Y por qué es posible algo así?

Porque las empresas tradicionales cargan con todo: guardan tus mensajes, tus fotos, tus videos, tus datos. Eso necesita edificios enteros de servidores.

XionIA no guarda nada de eso. El faro solo dice "ustedes dos, conéctense", y se corre del medio. Tu charla, tus fotos y tus archivos viajan directo entre tu dispositivo y el de la otra persona.

Menos trabajo = menos máquinas = menos plata. Y lo más importante: menos lugares donde alguien pueda espiar.

🛡️ El nodo puro: lo único que defendemos

Como ahora cada familia tiene su propio faro, ya no existe un servidor central que proteger. No hay edificio que defender. No hay oficina que cuidar.

Entonces, ¿qué defendemos? Solo una cosa: tu dispositivo y tu identidad.

A eso lo llamamos el nodo puro. Es tu teléfono, tu computadora, tu TV Box. Y lo más importante que guarda: tu identidad digital, que es como tu firma personal, única y secreta. Solo tuya.

🔑 Tu identidad digital es tuya.
No la guardamos nosotros. No la tiene ninguna empresa. No está en ningún servidor lejano. Vive en tu dispositivo, cifrada, y solo vos la controlás.

Por eso decimos que defendemos solamente al nodo puro: porque cuando cada casa es autosuficiente, ya no hay un punto central que atacar. El único "tesoro" que queda por cuidar es tu propia identidad, y esa la cuidás vos, en tu casa, en tu aparato.

⚖️ Antes vs. Ahora

Antes (Internet de siempre)	Ahora (XionIA)
Tu mensaje pasa por servidores de una empresa 😟	Tu mensaje va directo a la otra persona 😊
Una empresa puede leer lo que decís 👀	Nadie puede leerlo, ni siquiera nosotros 🔒
Te pueden banear o censurar 🚫	Nadie puede echarte de tu propia red ✅
Si cae el servidor, todos pierden conexión 💥	La red sigue funcionando, casa por casa 🏘️
Dependés de una empresa extranjera 🌎	La red es de tu comunidad, de tu barrio 🇦🇷

👨‍👩‍👧‍👦 ¿Qué significa esto para tu familia?

• 💬 Tus hijos pueden hablar con la abuela sin que nadie escuche.
• 📷 Las fotos familiares no terminan en servidores extranjeros entrenando inteligencias artificiales.
• 🏥 Un médico puede atender a distancia con la historia clínica protegida.
• 📚 Una escuela puede tener su propio canal sin depender de plataformas privadas.
• 🕊️ Si alguien intenta cortar la comunicación, no puede apagar a todos de un golpe, porque cada casa es su propia antorcha.

La tecnología deja de ser algo que te prestan, y pasa a ser algo que es tuyo.

😊 Lo que NO cambió (y está bien)

No tenés que aprender nada raro. No tenés que ser técnico. No tenés que configurar cosas complicadas.

Seguís haciendo lo mismo de siempre:

• 💬 Mandar mensajes a quien quieras.
• 📞 Llamar a tu familia.
• 📄 Compartir documentos.

La única diferencia es que ahora, por debajo, la charla es tuya. No de una empresa.

🗼🧉

La soberanía no se pide.
Se comparte.

Cada faro que se enciende es una familia que recupera su voz. Cada casa que se suma hace que la red sea más libre, más fuerte y más nuestra.

Dos carcachas en una casa de Argentina
pueden más que un datacenter de millones de dólares.
Esa es la revolución.

Construido con orgullo, código y aguante.
Desde el Sur Global, para el mundo. 🌎

🏷️ XionIA · Comunicación soberana · Infraestructura libre

"La identidad pertenece a la familia. Los secretos no pertenecen a nadie más."

XionIA-Faraday U2P. Explicado para los domingos en Familia.

XionIA Faraday · Desde Corrientes, Argentina 🧉

Perforamos el laberinto de las telefónicas: así logramos que dos celulares argentinos se hablen en secreto, sin pedirle permiso a nadie

No es una VPN. No es un túnel. Es un barrio entero que aprendió a hablar en código. ⚡

👵👴 Para mi familia (y para cualquiera que no sabe nada de esto)

Logramos que una computadora en casa y dos celulares (uno de Claro y otro de Personal, con datos móviles) se manden mensajes directamente entre ellos, con un cifrado que nadie puede leer: ni la telefónica, ni el gobierno, ni el vecino chusmo.

¿Por qué es difícil? Porque las telefónicas meten a miles de clientes detrás de una sola dirección (como un edificio con un solo timbre), y hacen malabares para que nadie de afuera pueda escribirte directamente. A ese laberinto se lo llama CGNAT, y es famoso por romper cualquier sistema de comunicación directa.

Nosotros lo perforamos. Y cuando el laberinto es tan malo que ni perforándolo se puede (el peor caso, que explicamos abajo), el sistema tiene un plan B que nunca falla: un cartero que entrega la carta sin poder abrirla. En esta nota te lo contamos todo, con dibujos y sin palabras raras. ☕

📖 El diccionario del barrio (30 segundos y entendés todo)

🏢 NAT / CGNAT:

El "portero" del edificio. Tu celu no tiene dirección propia en Internet: comparte la del edificio, y el portero decide adónde va cada carta.

🤝 P2P (peer a peer):

Que dos vecinos se pasen notas directamente, de mano en mano, sin pasar por ninguna oficina.

🔒 E2E (extremo a extremo):

La carta viaja en una caja fuerte que solo abren el que la escribe y el que la recibe. El cartero ve la caja, nunca el contenido.

🗼 Faro:

Un amigo con casa visible que presenta a los vecinos: "fulano está en tal ventana". Después los vecinos hablan solos.

📮 Relay:

El cartero. Cuando no se puede hablar directo, la carta pasa por él… pero va cerrada con llave que él no tiene.

🕵️ DPI:

El espía de la telefónica que mide la forma de los sobres para adivinar qué protocolo usás y estrangularlo.

🏢 El problema: el portero paranoico (CGNAT)

Imaginá un edificio con una sola puerta a la calle. Adentro viven miles de personas (los celulares y computadoras de los clientes de una telefónica). El portero (NAT) reparte numeritos internos y traduce: "la carta que llega al buzón 4.532 es para el depto 3B".

Hasta ahí, más o menos bien. Pero las telefónicas argentinas usan un portero aún peor, el CGNAT simétrico: no solo comparte la dirección del edificio entre varios edificios vecinos, sino que cambia el numerito de buzón según a quién le escribas. Si vos le escribís a María, el portero te da el buzón 100. Si le escribís a Juan, te da el 200. Y si María quiere responderte usando el buzón 100… el portero de Juan no lo reconoce y tira la carta a la basura. 🗑️

Con ese portero, que dos vecinos se hablen directo parece imposible. Por eso casi todos los sistemas se rinden y usan una oficina central (un servidor) que reenvía todo. Nosotros no nos rendimos.

🛡️ ¿Y WireGuard? (con todo respeto)

WireGuard es excelente y lo usamos de inspiración: su filosofía de "núcleo criptográfico chico, claves efímeras, todo sobre UDP" es oro. Pero es una VPN: un túnel entre tu dispositivo y un servidor. No fue diseñado para que dos vecinos cualesquiera se encuentren solos en medio del laberinto.

• Bajo CGNAT agresivo, sus mapeos de puertos se caen si no hay tráfico constante.
• Cuando dos nodos están atrapados detrás de CGNAT simétrico estricto, el hole punching clásico es matemáticamente imposible: sin un servidor TURN externo, la conexión muere.
• Sus tramas tienen tamaño y encabezados fijos: un espía DPI las reconoce de lejos y puede estrangularlas.

Nosotros no copiamos WireGuard. Le sacamos el alma (su filosofía de transporte y criptografía) y la pusimos al servicio de otra arquitectura: no un túnel hacia un servidor, sino un sistema operativo de red donde cada nodo habla con cada nodo.

⚡ La solución: U2P, el idioma secreto del barrio

Dentro de nuestro kernel construimos el Unified UDP Protocol (U2P). Cuatro pilares lo hacen posible:

1️⃣ Una sola ventana para todo

En vez de que cada función abra su propia ventana al mundo, toda la casa usa una única ventana: por ahí se pregunta al Faro, por ahí se golpea la puerta del vecino, por ahí pasan las cartas cifradas. Como la ventana nunca deja de moverse, el portero jamás la cierra. Ese es el truco que heredamos del alma de WireGuard.

2️⃣ El código de la pareja

Cada pareja de vecinos calcula un numerito de sesión que da igual desde ambos lados, ordenando sus identidades alfabéticamente (como "Fernández y López" da lo mismo lo diga uno u otro). Así, cuando llega una carta, la casa sabe al instante a qué conversación pertenece. Y si el celu cambia de antena 4G o pasa de Wi-Fi a datos, la conversación sigue viva.

3️⃣ Llaves que se autodestruyen

Antes de hablar, los vecinos hacen un apretón de manos mágico de 2 mensajes que genera una llave única para esa conversación. Cada 1.000 cartas o 5 minutos, la llave cambia sola. Si algún día alguien roba una llave, no puede leer ni el pasado ni el futuro. Además, cada carta lleva un número de serie sellado con tinta indeleble: si un espía fotocopia una carta y la reenvía, el número repetido la delata.

4️⃣ El cartero ciego

Si el laberinto de porteros es tan malo que lo directo no cierra, el sistema conmuta en menos de 50 milisegundos a un relay incondicional: las cartas pasan por el Faro, pero van en una caja fuerte cifrada y firmada que el Faro no puede abrir. Solo ve el peso del paquete y lo entrega. Nadie en el medio lee ni modifica un solo bit.

🗺️ El mapa del sistema

        XIONIA KERNEL (tu máquina)
              │
              ▼
        ┌───────────┐
        │    U2P    │  ← una sola ventana UDP
        │ Transport │
        └─────┬─────┘
              │
     ┌────────┴────────┐
     ▼                 ▼
 P2P DIRECTO       RELAY E2E
 (si el portero     (el cartero
  lo permite)        ciego)
     └────────┬────────┘
              ▼
          INTERNET
              ▼
        ┌───────────┐
        │  U2P Peer │
        └─────┬─────┘
              ▼
        KERNEL REMOTO (el vecino)

Directo cuando se puede. Relay cuando no. El relay es el último recurso de conectividad, nunca el centro de la red. Y en ambos caminos, la carta va cifrada de extremo a extremo.

🔬 La prueba en la calle: tres telefónicas, tres nodos reales

No probamos esto en un laboratorio con redes prolijas. Lo probamos en la trinchera: una computadora detrás de Fibertel y dos celulares con datos móviles de operadores distintos.

Conexión	Resultado
🖥️ Xeon (Fibertel) ↔ 📱 Claro (datos)	✅ DIRECTO
📱 Claro ↔ 📱 Personal (datos)	✅ DIRECTO
🖥️ Xeon ↔ 📱 Personal (el peor caso)	✅ RELAY E2E

¿Por qué el tercer caso va por relay? Porque es la combinación maldita: dos porteros simétricos estrictos enfrentados, cada uno cambiando los buzones según el destino. Ahí ni Dios perfora: WireGuard necesitaría un servidor TURN externo. Nosotros tenemos el cartero ciego integrado, y ningún mensaje se pierde jamás.

🔐 Blindaje: seis inteligencias artificiales nos auditaron

Sometimos el código a una auditoría donde varias IAs revisaron línea por línea. Detectaron dos agujeros teóricos y los cerramos antes de publicar:

🚫 Nadie puede desviar tu conversación:

Durante el golpe de puertas inicial cualquiera puede sugerir una dirección. Pero una vez que la conversación empezó, solo una carta con sello válido puede cambiar la dirección de entrega. Un mentiroso que invente paquetes no puede redirigir tu tráfico.

🔢 El número de serie va sellado:

El contador de cada carta quedó atado criptográficamente al sello. Un espía no puede alterarlo sin romper la verificación. Lo que antes era un campo "administrativo" ahora es parte del blindaje.

Y todo el motor pasó pruebas de estrés con 20 hilos transmitiendo en simultáneo, 100% libre de carreras de datos.

📊 ¿En qué nos diferenciamos?

Característica	VPN tradicional	WireGuard	XionIA U2P
Objetivo	Túnel a servidor	VPN segura	Red P2P soberana
P2P nativo	Limitado	No es su objetivo	Sí ✓
Atravesar CGNAT	Depende	Fuera del núcleo	Parte del transporte
Relay E2E integrado	Variable	TURN externo	Fallback incluido
Forward Secrecy	Variable	Claves estáticas	Efímeras por sesión
Identidad	Cuentas/IPs	Claves fijas	DIDs firmados

Nota honesta: no pretendemos "ser mejores que WireGuard" en general. Resolvemos problemas distintos: ellos hacen túneles VPN; nosotros hacemos el transporte nativo de un sistema operativo de red distribuido.

🔮 Lo que viene: disfraz y faros de barrio

🕵️ Anti-DPI (camuflaje): vamos a inyectar ruido aleatorio, variar el tamaño de los sobres y alterar los ritmos de envío, para que el espía de la telefónica solo vea pasar tráfico caótico e indistinguible. Nada de huellas digitales fijas.

🗼 Nodo-Faro (descentralización total): hoy el Faro es un amigo con casa fija. Mañana, cualquier nodo con una ventana visible podrá actuar como Faro de otros, presentando vecinos y coordinando apretones de manos. Si tumban un Faro, la red sigue viva. Es la arquitectura de BitTorrent y Tor, aplicada a nuestra soberanía.

🖥️ Derinkuyu Desktop: la consola-escritorio donde todo esto se vuelve usable: chat, archivos firmados, IA distribuida, federación y drones, en una sola interfaz.

💚 ¿Por qué hacemos esto, familia?

Porque tus palabras son tuyas. Porque la comunicación no debería depender de la buena voluntad de una corporación o de un botón de un gobierno. Porque desde Corrientes también se puede construir tecnología soberana que no le pide permiso a nadie.

No queremos una VPN dentro del sistema.
Queremos que el sistema tenga su propio transporte seguro.
Y ya está corriendo en el código. ⚡

XionIA Faraday · Transporte U2P · Etapa 2 cerrada (commit f2fa2a4)
Posted from Corrientes, Argentina — Proyecto de software libre bajo AGPL-3.0 + Commons Clause.

Es la infraestructura, Estupid!

⚠️ INFRAESTRUCTURA CRÍTICA COMPROMETIDA

Siete estados de EE.UU. sin control sobre su propia agua potable: lo que el FBI confirmó y lo que los gobiernos deberían hacer al respecto

No fue un súper exploit militar ni magia negra. Fue negligencia arquitectónica básica: miles de controladores industriales expuestos con IPs públicas en la Internet abierta, sin cifrado, sin autenticación criptográfica. Un escaneo masivo bastó.

Fuente: Informe FBI / CISA — TMF Noticias

Qué pasó, en corto

El FBI y la CISA confirmaron que un grupo atacante tomó control de controladores lógicos programables (PLCs) — Rockwell MicroLogics, Siemens, Schneider — en plantas de agua potable de siete estados. El método no fue sofisticado:

1. Escaneo masivo vía Censys/Shodan para encontrar dispositivos con IPs públicas expuestas.
2. Conexión directa a los controladores que escuchaban sin cifrado ni autenticación.
3. Cambio de contraseñas por defecto y alteración de la lógica de control.
4. Los operadores locales quedaron fuera de sus propios sistemas.

La recomendación de emergencia de CISA fue, literalmente: "desconecten los sistemas de Internet". En pleno siglo XXI, la respuesta ante un ciberataque a infraestructura crítica es priorizar el aislamiento manual. Eso dice mucho del modelo arquitectónico vigente.

El problema no es el atacante. Es la arquitectura.

Los PLCs compromised no tenían un "bug zero-day". No fueron víctimas de un exploit militar de millones de dólares. Estaban expuestos por diseño: con IPs públicas, puertos abiertos, protocolos de comunicación sin cifrar, y autenticación basada en contraseñas de fábrica.

El modelo SCADA/IoT industrial heredado asume que "poner un firewall arriba" alcanza. La realidad demostrada — una vez más — es que todo lo que escucha en la Internet pública termina siendo encontrado, escaneado y eventualmente comprometido.

"No se puede proteger lo que está diseñado para ser visible. La superficie de ataque no se reduce con parches: se elimina con arquitectura."

La alternativa: un kernel de red soberano con superficie de ataque cero

El xionia-kernel — un proyecto de kernel de red P2P soberano escrito en Go puro, que nació de los aprendizajes y pruebas exitosas del prototipo Web5-Mesh — está siendo diseñado desde el primer commit para un mundo donde el host es hostil. Los tres principios que lo hacen estructuralmente inmune al tipo de ataque descrito:

🫥

Superficie de ataque CERO

Un nodo del kernel no tiene puertos escuchando en la Internet pública. No responde a ICMP. No existe para Shodan ni Censys. Toda comunicación viaja encapsulada sobre túneles P2P cifrados en capa overlay. Si un atacante escanea la IP pública del router de una planta, el puerto está cerrado y descarta en silencio. Sin logs, sin respuesta, sin existencia.

🔐

Autenticación por firma, no por contraseña

No existen las "contraseñas". Cada nodo tiene una identidad soberana (did:maia) generada criptográficamente. Para que dos dispositivos se hablen, se requiere un handshake Noise IK con claves públicas vinculadas a identidades verificables. Si la clave pública del emisor no está en la ACL local del nodo receptor, el paquete se destruye en user-space antes de tocar cualquier lógica de control.

📡

Off-grid: funciona sin Internet

Si cortás la WAN, la red industrial sigue funcionando dentro de la malla P2P local: Ethernet interno, Wi-Fi, enlaces de radio Sub-GHz o VHF. La telemetría, las alertas y los comandos de control circulan de nodo a nodo sin exponer un solo bit al exterior. El aislamiento físico no es una respuesta de emergencia: es el estado natural del sistema.

Comparativa directa

Aspecto	Modelo SCADA heredado	xionia-kernel
Descubribilidad	IP pública, visible en Shodan/Censys	Invisible: no escucha en Internet
Autenticación	Contraseñas de fábrica / por defecto	Firma Ed25519 + handshake Noise IK
Cifrado	Ninguno (protocolos industriales legados)	ChaCha20-Poly1305 E2E en cada paquete
Dependencia de Internet	Total — sin WAN, sin monitoreo	Ninguna — malla local autónoma
Control de acceso	Firewall perimetral (se perfora una vez)	ACL por nodo, por clave, por sesión
Respuesta ante ataque	"Desconectá de Internet"	El ataque no llega a existir

Estado actual del proyecto

Esto no es un concepto teórico. La viabilidad de las comunicaciones P2P cifradas y la capa de ruteo overlay se validó exitosamente en la maqueta de prueba Web5-Mesh (PoC). Hoy, sobre esa base probada, se está construyendo de forma modular la arquitectura definitiva del xionia-kernel en Go:

xionia-kernel/
├── go.mod ✅
├── STATUS_KERNEL.md ✅
├── RFC-0001.md ✅ APROBADO
├── pkg/
│   ├── bus/ bus.go + tests ✅
│   ├── identity/ identity.go + tests ✅
│   ├── session/ 🔄 en curso
│   ├── transport/ ⏳ interfaces → integración
│   ├── kernel/ ⏳ pendiente
│   └── signaling/ 🔴 pendiente
└── cmd/
     ├── xionia-node/ 🔴 pendiente
     └── faro-server/ 🔴 pendiente

Los componentes primitivos de criptografía (Ed25519, X25519, ChaCha20-Poly1305), los handshakes de autenticación y el transporte sobre Noise IK probados en la maqueta original se están integrando directamente como módulos nativos del kernel.

Qué gana una infraestructura que adopta esta arquitectura

• Elimina la superficie de ataque de raíz: no hay puertos expuestos a Internet, no hay contraseñas que adivinar. El vector de ataque descrito por el FBI deja de existir.
• Soberanía tecnológica real: código abierto, auditable, sin dependencias de proveedores externos ni licencias privativas.
• Continuidad operativa sin Internet: ante un corte de WAN (sabotaje o desastre), la red industrial sigue operando de forma autónoma sobre enlaces locales.
• Auditoría criptográfica de cada comando: toda instrucción de control está firmada por una identidad verificable. Trazabilidad total de quién ejecutó qué acción.
• Escalabilidad soberana: corre eficientemente en hardware modesto (Raspberry Pi, mini PCs, SBCs o TV boxes recicladas) sin requerir servidores cloud ni infraestructura costosa.

La conclusión que ningún manual de compliance te va a decir

El ataque a las plantas de agua de EE.UU. no fue un fallo de inteligencia. El FBI sabía que esos dispositivos estaban expuestos. CISA había emitido alertas. El problema no era la información: era la arquitectura.

Seguir "parcheando" un modelo que expone dispositivos industriales a la Internet abierta es ponerle un curita a una hemorragia. La pregunta que los responsables de infraestructura deberían hacerse no es "¿cómo protegemos los PLCs que ya están expuestos?", sino "¿por qué están expuestos en primer lugar, y qué arquitectura hace que eso sea imposible por diseño?"

La respuesta se está construyendo desde la trinchera: es código abierto, está escrita en Go, corre en hardware accesible y no requiere pedirle permiso a nadie. Solo necesita ejecutarse.

De la maqueta de prueba a la arquitectura real

Web5-Mesh demostró que el concepto P2P soberano funciona. El xionia-kernel lleva esa experiencia al siguiente nivel.

Web5-Mesh (Maqueta / PoC) XionChat (Pruebas sobre la red)

Escrito desde la trinchera. Corrientes, Argentina. 🧉
xionia-kernel · Red P2P soberana · Zero-Trust nativo · Sin cuentas. Sin contraseñas. Sin superficie de ataque.

XionIA Faraday — Red Soberana -- Faro Ciego -- Jaula de Faraday

Red Soberana · Fase 1 Completa · Julio 2026

XIONIA Faraday

Una red overlay soberana que elimina intermediarios obligatorios. No es un mensajero. Es un user-space kernel de comunicación con cifrado E2E, relay ciego zero-knowledge, y una Jaula de Faraday lógica que trata al host como hostil. Corre en TV boxes con 1 GB de RAM.

github.com/mamanga1/Web5-Mesh · github.com/mamanga1/xionia-xtp · MIT + Anti-Corporate · Go + Flutter + FFI

01 — Qué es

No es otro chat. Es una capa de infraestructura soberana

Web5-Mesh (nombre interno: XionIA Faraday) es una red overlay que actúa como un User-Space Kernel de comunicación. Su objetivo no es competir con WhatsApp en features, sino eliminar la dependencia de intermediarios obligatorios.

Lo que la hace diferente:

🔐 Túneles U2P

User-to-Peer directos, cifrados E2E. Sin servidor que lea, almacene o reenvíe tus mensajes en claro.

🗼 Faro Ciego

Relay zero-knowledge: solo reenvía paquetes cifrados. Opera en RAM volátil. Sin logs persistentes. Sin metadata útil.

🛡️ Jaula de Faraday

Workspace aislado (~/.xion/) con permisos estrictos. El host es tratado como hostil. Wipe total con un comando.

📺 Hardware accesible

Corre en Xeon, Raspberry Pi, TV boxes ARM64 con 1 GB RAM. El faro consume 2.6 MB de RAM.

Xionia-XTP (XionChat) es el cliente Android en Flutter que usa el motor Go de Web5-Mesh vía FFI. Chat simple, sin cuentas, sin números. Identidad did:maia:... generada localmente. Faros públicos con fallback automático.

02 — Filosofía

Privacidad ≠ Soberanía

Privacidad es defensiva: "que no me espíen". Tor, Signal. Soberanía es activa: control total sin pedir permiso a intermediarios. XionIA prioriza soberanía. Libertad positiva vs. negativa.
— MANIFIESTO.md

Signal cifra tus mensajes, pero dependés de Signal para registrarte, para que el relay funcione, para que no te baneen. Eso es privacidad sin soberanía. Si Signal cae, caés. Si te banean, desaparecés.

XionIA invierte la lógica: tu nodo es tuyo. Tu identidad se genera localmente. El faro es reemplazable, agnóstico, ciego. Si un faro cae, conectás a otro. Si todos caen, levantás el tuyo. Nadie puede banear tu DID porque no hay autoridad central que lo emita.

La distinción en una línea

Privacidad: "no me mires". Soberanía: "no te necesito".

03 — Arquitectura

El Faro Ciego: un cartero que no abre los sobres

┌─────────────────────────────────────────────────────────┐ │ NODO A NODO B │ │ did:maia:xxx did:maia:yyy │ │ ┌──────────┐ ┌──────────┐ │ │ │ Shell / │ │ XionChat │ │ │ │ Chat E2E │ │ Flutter │ │ │ │ ACL │ │ FFI → Go │ │ │ └────┬─────┘ └────┬─────┘ │ │ │ Handshake DID │ │ │ │ + msg cifrado │ │ │ ▼ ▼ │ │ ┌─────────────────────────────────────────┐ │ │ │ FARO CIEGO │ │ │ │ UDP :54321 (principal) │ │ │ │ UDP :443 (fallback) │ │ │ │ WSS :443 (último recurso) │ │ │ │ Gate DID · Relay zero-knowledge │ │ │ │ No almacena · No lee · No loguea │ │ │ └─────────────────────────────────────────┘ │ │ │ │ Red hostil (Internet, ISPs, NAT, CGNAT, DPI) │ └─────────────────────────────────────────────────────────┘

Qué sabe el faro

• Qué IP pasó el Gate DID (y la olvida en 2 horas)
• A qué IP reenviar el paquete

Qué NO sabe el faro

• Quién habla con quién
• Qué dice el mensaje
• Cuántos mensajes hay
• Qué DIDs existen
• Nada que sirva para vigilancia

Gate DID: la puerta con candado

Desde julio 2026, el faro tiene un Gate DID: solo entran nodos que presenten un handshake Ed25519 válido. El faro verifica la firma, regenera el DID desde la clave pública, y si coincide, autoriza la IP. Los bots que escanean TCP 443 reciben un 403 y desaparecen. Zero logs. Zero CPU. Zero entrada.

🛡️ [FARO-UDP] Relay Ciego en 0.0.0.0:54321 (Gate DID activo) 🛡️ [FARO-UDP] Relay Ciego en 0.0.0.0:443 (Gate DID activo) 🛡️ [FARO-WS] WebSocket TLS en 0.0.0.0:443 (Gate DID activo) [FARO-UDP] 🔑 Gate: did:maia:6hZDRM7smtQ... autorizado desde 190.220.*.* [FARO-UDP] 📥 ANNOUNCE: did:maia:6hZDRM7smtQ... desde 190.220.*.* Memoria: 2.6 MB · CPU: ~0% · Uptime: infinito (systemd START_STICKY)

04 — Criptografía

Ed25519 + X25519 + ChaCha20 + Noise IK

Ed25519

Identidad y firmas. Tu DID es tu clave pública. Firmás cada mensaje. El faro verifica tu handshake con esto.

X25519

Intercambio de claves Diffie-Hellman. Derivás una clave compartida con cada peer. Nadie más puede descifrar.

ChaCha20-Poly1305

AEAD. Cifrado autenticado. Si alguien toca un byte del ciphertext, la autenticación falla y el mensaje se descarta.

Noise IK

Handshake pattern (como WireGuard). Forward secrecy, autenticación mutua, resistencia a KCI. 2 rondas.

Noise Protocol IK — Desglose

XionIA usa el patrón IK del Noise Protocol Framework (el mismo de WireGuard). "I" = el initiator envía su clave estática inmediatamente. "K" = el responder ya conoce la clave del initiator de antemano.

── Patrón IK (Noise_IK_25519_ChaChaPoly_SHA256) ── Pre-handshake: Initiator ya conoce la clave estática pública del Responder (out-of-band) Mensaje 1 (Initiator → Responder): → e, es, s, ss Genera efímera e. Calcula DH(es) y DH(ss). Envía su clave estática s (cifrada). Autentica al Initiator. Mensaje 2 (Responder → Initiator): ← e, ee, se Genera su efímera e. Calcula DH(ee) y DH(se). Autenticación implícita del Responder. Resultado: Ambos derivan las mismas claves de transporte. Forward secrecy ✓ · Autenticación mutua ✓ · Anti-replay ✓

Propiedades de seguridad

• Forward secrecy: comprometer claves estáticas no rompe sesiones pasadas (efímeras)
• Autenticación mutua: ambos verifican la identidad del otro
• Resistencia a KCI: si roban tu clave, no pueden hacerse pasar por otros
• Anti-replay: nonce incremental + timestamp con ventana de 60 segundos
• Indistinguibilidad: con padding aleatorio, el tráfico parece ruido

05 — XionChat Android

v0.2-beta: de demo técnica a app funcional

XionChat es el cliente Android en Flutter que usa el motor Go de Web5-Mesh vía FFI (Foreign Function Interface). El binario Go se compila como libxionia.so (CGO_ENABLED=1, buildmode=c-shared) y se carga en runtime. Flutter no reimplementa nada: llama al motor real.

Lo que trae v0.2-beta

📱 Persistencia en background

Foreground Service + PARTIAL_WAKE_LOCK + START_STICKY. El nodo Go sigue vivo con la pantalla apagada. Si Android mata el proceso, se reinicia.

🔔 Notificaciones push

flutter_local_notifications. Te llega "💬 Juan: Hola" aunque la app esté cerrada. Permiso POST_NOTIFICATIONS para Android 13+.

⚡ FFI asincrónico

Las llamadas al motor Go no bloquean la UI. No más ANR al conectar. compute() + Isolate.

🔄 Reconexión automática

Si se corta internet, reintenta cada 2 segundos. UDP 54321 → UDP 443 → WSS 443. Mensajes en cola.

Arquitectura del APK

┌─────────────────────────────────────────────┐ │ ANDROID │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ XioniaService.kt (Foreground) │ │ │ │ Notificación: "Nodo mesh conectado" │ │ │ │ WakeLock · START_STICKY │ │ │ └──────────────┬──────────────────────┘ │ │ │ │ │ ┌──────────────▼──────────────────────┐ │ │ │ Flutter (main.dart) │ │ │ │ UI: chat, contactos, burbujas │ │ │ │ Polling 2s → XioniaPollMessages() │ │ │ │ Notificaciones push locales │ │ │ └──────────────┬──────────────────────┘ │ │ │ FFI │ │ ┌──────────────▼──────────────────────┐ │ │ │ libxionia.so (mobile.go) │ │ │ │ Nodo Go: goroutines, sockets │ │ │ │ UDP 54321 → UDP 443 → WSS 443 │ │ │ │ Handshake DID · ANNOUNCE /15s │ │ │ │ recover() anti-panic │ │ │ └──────────────┬──────────────────────┘ │ │ │ UDP / WSS │ └─────────────────┼───────────────────────────┘ ▼ ┌───────────────┐ │ FARO CIEGO │ │ Gate DID │ │ Relay ciego │ └───────────────┘

Specs del APK

• Tamaño: ~25 MB
• Android: 10 a 15 (API 29+), arm64-v8a
• Permisos: INTERNET, FOREGROUND_SERVICE, WAKE_LOCK, POST_NOTIFICATIONS
• Sin: cuentas, números de teléfono, email, Google Play Services
• Faros: Argentina (190.220.45.26) + Oracle (150.136.55.87), fallback automático

06 — Tabla Comparativa

XionIA vs. el ecosistema completo

Comparativa estilo eylenburg.github.io actualizada a julio 2026, con XionIA / XionChat incluida.

Aspecto	SimpleX	XMPP	Delta Chat	Matrix	Session	Signal	Telegram	Threema	XionIA / XionChat
Año	2021	1999	2017	2014	2020	2014	2013	2012	2025-26
Modelo	Decentralized (relays ciegos)	Federated	Federated (email)	Federated	Decentralized (blockchain)	Centralizado	Centralizado	Centralizado (pago)	Overlay soberano + Faro ciego
Identidad	Sin IDs persistentes	user@server	Email	@user:server	Session ID	Teléfono	Teléfono	ID anónimo pago	DID did:maia (claves locales)
E2EE	Sí (default)	OMEMO	OpenPGP	Olm/Megolm	Sí	Sí	Opcional	Sí	Siempre (Ed25519/X25519/ChaCha20)
Metadata	Muy baja	Media	Baja-media	Media	Baja	Media	Alta	Baja	Muy baja (relay zero-knowledge)
Soberanía	Alta	Alta (self-host)	Alta	Media-alta	Alta	Baja	Baja	Baja	Muy alta (nodos propios + Jaula)
Relay / Servidor	Relays ciegos	Servidores federados	Email servers	Homeservers	Oxen nodes	Centralizado	Centralizado	Centralizado	Faro ciego (zero logs, RAM-only)
NAT Traversal	Bueno	Depende	Depende	Depende	Bueno	Central	Central	Central	Excelente (UDP hole punching + U2P)
Anti-DPI	Media-alta	Baja-media	Baja	Baja	Media	Baja	Media	Baja	Alta (padding + UDP ruido)
Hardware bajo	Bueno	Variable	Bueno	Variable	Bueno	Bueno	Bueno	Bueno	Excelente (TV Box, RPi, 1 GB RAM)
Shell avanzada	No	Sí (varios)	No	No	No	No	No	No	Sí (go-prompt, autocompletado)
IA integrada	No	No	No	No	No	No	Limitada	No	Sí (llama.cpp local + P2P)
Android	✅	✅	✅	✅	✅	✅	✅	✅	✅ (XionChat Flutter)
iOS	✅	✅	✅	✅	✅	✅	✅	✅	En roadmap
Desktop	✅	✅	✅	✅	✅	✅	✅	✅	✅ (terminal)
Grupos	✅	✅	✅	Excelente	✅	✅	Excelente	✅	✅ (básicos Fase 1)
Voz / Video	✅	✅	No	✅	✅	✅	✅	✅	Planeado Fase 3 (XPT)
Facilidad uso	Alta	Media-alta	Muy alta	Alta	Alta	Muy alta	Muy alta	Alta	Media (mejorando)
Adopción	Baja-media	Media	Media	Media-alta	Baja-media	Muy alta	Muy alta	Baja-media	Muy baja (temprano)
Precio	Gratis	Gratis	Gratis	Gratis	Gratis	Gratis	Gratis	Pago único	Gratis
Licencia	AGPL	GPL	GPL	AGPL	GPL	AGPL	Propietaria	Propietaria	MIT + Anti-Corporate
Fortaleza clave	Privacidad extrema	Estándar abierto	Usa email	Interoperabilidad	Anonimato	Usabilidad	Features	Pago anónimo	Soberanía + bajo hardware + relay ciego + IA P2P

Conclusión de la tabla

XionIA se posiciona en el segmento alto de soberanía y resistencia técnica, compitiendo directamente con SimpleX y Session, pero con un enfoque más "infraestructura kernel" que mensajero puro. Nadie más ofrece shell + IA distribuida + verificación de binarios + relay ciego + TV boxes en esta etapa.

07 — Valoración

Fin de Fase 1: 8.7 / 10

8.7

Valoración global
Fin Fase 1

Cumplimiento Fase 19.0

Calidad técnica8.5

Innovación / Diferenciación9.0

Potencial de impacto8.5

Fortalezas

• Fase 1 cumplida con solidez: base criptográfica madura, relay ciego funcional, Jaula de Faraday, shell potente
• Enfoque en soberanía real, no solo privacidad
• Hardware accesible: TV boxes ARM64 con 1 GB RAM
• Seguridad por defecto: permisos 0600, padding anti-DPI, ACL explícita, wipe total
• Cliente Android con FFI al motor Go (no reimplementación)
• Gate DID anti-bots: zero logs, zero CPU para escaneos

Áreas de mejora (Fase 2)

• Auditoría cripto externa pendiente
• UX: la shell limita el público, la app Android necesita multi-device
• Testing en campo: CGNAT reales, firewalls corporativos, redes móviles argentinas
• Federación y multi-faro
• Métricas públicas: benchmarks de latencia, consumo RAM

08 — Roadmap

Lo que viene: Fase 2 y 3

🔵 Fase 2 — Infraestructura

U2P estable (conexión directa sin relay). Hosting soberano P2P. Proxy SOCKS5. IA colaborativa con llama.cpp local. Mercado P2P de modelos. Verificación de binarios con Cosign + SLSA.

🟢 Fase 3 — Expansión

XPT (Xionia Peer Transport): voz y video P2P. iOS. Multi-device. Grupos maduros con adjuntos. Federación de faros. Red de hosting soberano.

📌 Estado actual

Fase 1 cerrada el 22 de julio de 2026. XionChat v0.2-beta publicada. Dos faros en producción (Argentina + Oracle). Gate DID activo. UDP 54321 principal, UDP 443 fallback, WSS 443 último recurso.

09 — Probalo

Instalá y conectá

Android (XionChat)

# Descargar APK desde GitHub Releases → github.com/mamanga1/xionia-xtp/releases v0.2-beta · app-release.apk · ~25 MB · arm64 # Instalar (habilitar "fuentes desconocidas") → Abrir APK → Instalar de todos modos

Linux (Shell)

$ git clone https://github.com/mamanga1/Web5-Mesh $ cd Web5-Mesh $ go build -o mesh ./cmd/mesh $ ./mesh ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ XION KERNEL v1.0.0 | Modo Seguro: ON 🆔 DID: did:maia:6hZDRM7smtQ... 📡 Faro activo: 190.220.45.26:54321 (UDP) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ xion@nodo:~$ _

Levantar tu propio faro

$ go build -o faro ./cmd/faro $ sudo ./faro 🚀 Iniciando Faro Dual (UDP + WebSocket) Gate DID: solo nodos con did:maia válido 🛡️ [FARO-UDP] Relay Ciego en 0.0.0.0:54321 🛡️ [FARO-UDP] Relay Ciego en 0.0.0.0:443 🛡️ [FARO-WS] WebSocket TLS en 0.0.0.0:443 Memoria: 2.6 MB · Corre en cualquier cosa

🛡️

XIONIA Faraday — Red Soberana · Faro Ciego · Jaula de Faraday

Web5-Mesh · Xionia-XTP · MIT + Anti-Corporate

"Privacidad es que no te miren. Soberanía es no necesitarlos."

Julio 2026 · Fase 1 completa · v0.2-beta