Las redes sociales descentralizadas suelen prometer libertad, pero casi siempre te cambian una dependencia por otra: si no es un servidor, es un relay; si no es una plataforma, es una capa de infraestructura que igual controla algo. s@, pronunciado “sat-at”, va por otro camino. Su apuesta es mucho más radical: que una red social pueda vivir sobre sitios estáticos, sin servidores propios, sin relays y con los posts cifrados como archivos JSON.
No es una idea lista para competir con X, Bluesky o Mastodon. Está en versión 0.1.0 y todavía huele a experimento. Pero justo por eso vale la pena mirarla: porque empuja una pregunta incómoda para toda la web social de 2026. ¿Cuánta infraestructura hace falta realmente para que dos personas compartan ideas en internet?
¿Qué es exactamente s@?
s@ es un protocolo social descentralizado creado por el desarrollador remysucre y publicado como proyecto abierto bajo el nombre satellite. La lógica es simple: cada usuario usa su propio dominio o un sitio estático —por ejemplo, uno alojado en GitHub Pages— como perfil, almacenamiento y punto de publicación. En vez de guardar todo en una base de datos central, el protocolo distribuye archivos JSON cifrados dentro de una estructura fija como posts/, follows/ y keys/.
La identidad no depende de una cuenta dentro de una app, sino del dominio mismo. Si controlas el dominio y puedes publicar ahí por HTTPS, esa es tu identidad. El documento de descubrimiento satproto.json expone la versión del protocolo —hoy 0.1.0— y la clave pública del usuario. A partir de ahí, el navegador hace el resto: agrega feeds, descifra mensajes y publica nuevos posts.
La parte más interesante es el modelo de privacidad. s@ usa claves X25519 para intercambio criptográfico, XChaCha20-Poly1305 para cifrar el contenido y sealed boxes de libsodium para compartir la clave de lectura con cada seguidor autorizado. Dicho en español simple: tus posts no quedan “privados porque la plataforma promete portarse bien”, sino porque están cifrados desde el diseño. Si no tienes la clave, no lees nada.
¿En qué se diferencia de Bluesky, Mastodon o Nostr?
La comparación útil no es “¿puede reemplazarlos mañana?”, sino “¿qué sacrifica y qué gana?”. ActivityPub, la base del fediverso, permite interoperabilidad entre instancias, pero sigue necesitando servidores y administradores. AT Protocol, la infraestructura de Bluesky, empuja la portabilidad y la identidad más allá de una sola app, aunque en la práctica todavía gira mucho alrededor de la red principal. Si quieres ver cómo ese ecosistema sigue madurando, ya revisamos el caso de Periwinkle, el hosting gestionado para PDS de Bluesky.
s@ corta todavía más profundo: elimina por completo la capa intermedia. No hay instancia, no hay relay y no hay firehose. Tus datos viajan desde tu propio sitio al navegador de tus contactos. Eso lo vuelve elegantemente minimalista, pero también mucho más limitado. No hay ambición de convertirse en una plaza pública global. Es, como dice su propia documentación, una red pensada para ti y tus amigos, no para influencers.
También es una señal de hacia dónde se está moviendo la web social. Mientras unos proyectos exploran redes abiertas desde el iPhone, como contamos con AltStore PAL y su salto al fediverso, s@ prueba el extremo opuesto: una red mínima, privada y casi artesanal. Donde Bluesky busca escalar y ActivityPub busca federar, s@ busca reducir.
Lo brillante y lo incómodo de una red social sobre archivos estáticos
La propuesta tiene varias ventajas reales, sobre todo para quienes construyen productos y no solo los consumen:
- Infraestructura casi gratis: al vivir sobre hosting estático y CDN, el costo operativo puede ser ridículamente bajo comparado con una red social tradicional.
- Soberanía de identidad: tu nombre de dominio es tu cuenta. No dependes de que una empresa conserve tu usuario o mantenga tu perfil activo.
- Privacidad por arquitectura: el hosting puede servir tus archivos, pero no leerlos si están cifrados correctamente.
- Modelo anti-spam: para ver posts de alguien debe existir seguimiento mutuo. Eso corta de raíz la lógica de difusión masiva y muchos incentivos del spam.
Ahora lo incómodo. El propio diseño trae fricciones que no son pequeñas. Como se apoya en sitios estáticos, no hay tiempo real nativo ni notificaciones mágicas. El cliente tiene que consultar periódicamente si aparecieron novedades. Además, cuando dejas de seguir a alguien, el sistema debe rotar claves, volver a cifrar los posts y regenerar acceso para el resto. Eso puede ser elegante desde la seguridad, pero pesado desde la experiencia.
También hay una barrera brutal de onboarding. Hoy el camino recomendado es hacer fork del repositorio, activar GitHub Pages y visitar la URL generada. Para una persona técnica eso es casi divertido. Para el usuario normal, está a años luz de “descarga la app y entra”. Y sin una experiencia simple, el protocolo difícilmente salga del nicho hacker que hoy lo está explorando.
¿Para quién puede servir una idea así?
La respuesta corta: no para todo el mundo. Pero sí para varios casos donde las redes sociales masivas son un mal encaje. Comunidades pequeñas, grupos privados, colectivos que valoran soberanía del dato, proyectos experimentales de identidad digital y productos que quieran combinar publicación simple con privacidad fuerte tienen aquí un laboratorio muy serio.
Incluso si s@ nunca despega como red social en sí, ya aporta algo útil: muestra que no toda “descentralización” necesita blockchain, tokens o capas enteras de infraestructura. A veces basta con recuperar una intuición vieja de la web —el sitio propio como unidad básica— y actualizarla con buena criptografía. Esa mezcla de web 1.0 y seguridad moderna tiene algo refrescante en un momento donde muchas plataformas venden complejidad como si fuera innovación.
Por qué importa
s@ importa porque pone presión sobre una suposición que llevamos años aceptando: que toda red social relevante necesita una empresa detrás, una base de datos central o una red de nodos siempre encendidos. Este protocolo dice lo contrario. Dice que, para ciertas relaciones y ciertas comunidades, quizá alcance con archivos estáticos, cifrado bien hecho y un navegador.
No parece el futuro de la red social masiva. Pero sí puede ser una pista del futuro de la red social íntima: menos alcance, más control; menos algoritmo, más propiedad; menos plataforma, más web. Y en 2026, cuando tantas discusiones sobre descentralización siguen atrapadas entre hype y dependencia real, esa claridad vale bastante más de lo que parece.
