s@ : redes sociales descentralizadas basadas en sitios estáticos

 (satproto.org)
9 puntos por GN⁺ 2026-03-13 | 1 comentarios | Compartir por WhatsApp
  • Protocolo de redes sociales descentralizadas basado en sitios web estáticos, con una estructura en la que cada usuario posee y administra directamente sus propios datos
  • Todos los datos se guardan en un almacén JSON cifrado, y el cliente del navegador agrega el feed y publica las entradas
  • Funciona sin servidores ni relays, mediante comunicación directa entre sitios web y navegadores de amigos
  • El nombre de dominio del usuario es su identidad, autenticada mediante HTTPS/TLS
  • Implementa una red social autosoberana con una estructura simple, enfocada en interacciones basadas en la confianza entre personas

Resumen del protocolo sAT

  • s@ es un protocolo de redes sociales descentralizadas basado en sitios estáticos, donde cada usuario almacena los datos en su propio sitio web
    • Todos los datos se guardan como archivos JSON cifrados, que el cliente del navegador lee para publicar entradas y agregar el feed
    • Funciona sin servidor central ni relay, y los datos se mueven directamente desde el sitio del usuario al navegador de sus amigos
  • Debe existir una relación de seguimiento mutuo para que se puedan intercambiar publicaciones, excluyendo una estructura centrada en influencers
  • El protocolo no depende de servicios de hosting específicos como GitHub Pages

Identidad

  • El nombre de dominio del usuario funciona como identidad
  • HTTPS/TLS autentica que el propietario del dominio publicó el contenido

Descubrimiento

  • En la ruta https://{domain}/satellite/profile.json se proporciona la versión del protocolo y la clave pública 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • Si se usa una ruta distinta de la predeterminada /satellite/, se puede indicar la ubicación real del repositorio con el archivo .well-known/satproto.json

Modelo de cifrado

  • Todos los datos del usuario se almacenan en un almacén JSON cifrado, y solo el usuario y sus seguidores pueden descifrarlos
  • Se utiliza un par de claves X25519: la clave pública se publica en profile.json y la clave privada se guarda en localStorage del navegador
  • Los datos de las publicaciones se cifran con XChaCha20-Poly1305, y la clave de contenido se cifra para cada seguidor con crypto_box_seal de libsodium
  • El archivo keys/_self.json contiene la clave de contenido del usuario y los secretos de publicación, y solo el propio usuario puede descifrarlo

Rotación de claves y dejar de seguir

  • Al dejar de seguir, se genera una nueva clave de contenido y se vuelven a cifrar todas las publicaciones
  • Se generan nuevos sobres de clave para los seguidores restantes y se actualiza keys/_self.json
  • El usuario al que se dejó de seguir ya no puede descifrar las publicaciones

Flujo de descifrado

  • Cuando un visitante entra al sitio de un amigo, descifra keys/{follower-domain}.json con su clave privada para obtener la clave de contenido
  • Después obtiene y descifra posts/index.json y cada publicación individual (posts/{id}.json.enc)

Estructura de datos

  • Cada publicación se guarda como un archivo cifrado por separado, y posts/index.json lista los IDs de publicaciones en orden de más reciente a más antigua
  • Ejemplo de objeto de publicación: 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • El ID de la publicación se compone de una marca de tiempo UTC ISO8601 y un hash aleatorio de 4 caracteres

Lista de seguidos

  • Se guarda como JSON en texto plano en la ruta https://{domain}/satellite/follows/index.json 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • No está cifrada, ya que la relación de seguimiento ya queda expuesta mediante los sobres de clave

Agregación del feed

  • El cliente lee la lista de seguidos y descifra las publicaciones de cada seguidor para construir un feed cronológico
  • Las publicaciones se ordenan en forma descendente según created_at

Respuestas

  • Las respuestas son publicaciones con los campos reply_to y reply_to_author definidos
  • No se admiten respuestas anidadas; solo se puede responder directamente a publicaciones de nivel superior
  • Si no se puede ver la publicación original (por ejemplo, porque no existe una relación de seguimiento), la respuesta no se muestra

Publicación

  • Crear una nueva publicación → cifrarla con la clave de contenido → subirla al sitio estático → actualizar posts/index.json
  • Para la carga se puede usar GitHub Contents API, entre otros
  • Los secretos de publicación se guardan cifrados en keys/_self.json

Ejemplo de estructura del sitio estático

{domain}/satellite/
  profile.json              # clave pública y perfil
  posts/
    index.json              # lista de IDs de publicaciones
    {id}.json.enc           # publicación cifrada
  follows/
    index.json              # lista de seguidos
  keys/
    _self.json              # clave de contenido y credenciales
    {domain}.json           # clave de contenido por seguidor

FAQ

  • “¿Es RSS + cifrado?” → Sí
  • “¿Es una versión de AT Protocol sin firehose?” → Sí
  • “¿Es escalable?” → No (“la amistad tampoco escala”)
  • “¿La s significa slow/shitty?” → Sí
  • “¿Se puede self-hostear?” → Sí, pero requiere CORS habilitado

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-03-13
Comentarios en Hacker News

  • Siento que este proyecto sufre los mismos problemas que muchas redes sociales alternativas y autohospedadas
    El diseño centrado en el cifrado suena genial, pero si cambias de dispositivo es difícil recuperar a quiénes sigues, y conceptos como un par de claves X25519 también son difíciles de entender para la gente común
    Yo creo que una estructura más realista es simplemente basada en usuario y contraseña, donde el servidor se encarga del cifrado
    Me parece que ese enfoque sí apunta a algo que puedan usar usuarios no técnicos y que pueda reemplazar a las big tech

    • Yo pienso algo parecido. Pero si de verdad queremos un mundo sin intermediarios, al final también hace falta un cambio cultural donde los usuarios no técnicos gestionen por sí mismos al menos una pequeña parte
    • Después de la configuración inicial, basta con exportar la clave privada y guardarla en un gestor de contraseñas o algo similar. Si no vas a implementar el protocolo directamente, no es tan complicado
      Aun así, quizá tendría que configurar yo mismo todo para mi familia o amigos. Pero creo que igual les gustaría bastante tener su propio sitio web
    • Según el FAQ al final del artículo, esto se parece más a un experimento conceptual al que se le quitaron algunos elementos de AT Protocol (BlueSky)
      En la práctica, puede verse como una idea para integrar blogs estáticos con BlueSky.
      Podría mejorarse usando la identidad de BlueSky o con un plugin para generadores de sitios estáticos que obtenga automáticamente la información de autenticación
    • Antes intenté la idea de usar el correo electrónico como capa de transporte para una red social, pero fracasó
      Ver este artículo relacionado
    • No sé si el objetivo es reemplazar a las big tech. Si simplemente puede servirle bien a una comunidad pequeña, yo ya lo consideraría un éxito

  • Me sorprendió la parte donde guardan la clave privada en el localStorage del navegador
    Si restableces la configuración del navegador o lo reinstalas, los datos se pierden, es difícil hacer respaldo y el acceso para malware es fácil
    Al final, si se pierde la clave también desaparece el feed para siempre, así que hay riesgo de que los usuarios abandonen la plataforma

    • De acuerdo. Viendo que usan términos como “par de claves X25519” con total naturalidad, siento que este proyecto está más cerca de un experimento conceptual que de una adopción masiva
    • Creo que esto se resuelve con un solo botón de “exportar clave a una ubicación segura”. Con código simple como URL.createObjectURL(localStorage.getItem(...)) ya podrías inducir al usuario a guardar un archivo
    • No hay que perseguir la perfección y perder una solución ‘lo suficientemente buena’. Con solo agregar funciones para descargar/subir la clave, la mayoría de los problemas quedarían resueltos
      Claro, si se pierde la clave ya no hay acceso, pero los usuarios de 2FA o de billeteras cripto también asumen responsabilidades parecidas, así que no es algo completamente imposible

  • Alguien propone usar /.well-known/ en lugar de la ruta /satellite/
    Hace referencia al estándar Well-known URI

    • Le responden en broma diciendo “.poorly-known”
    • A otro le preocupa porque recuerda que en los inicios de AT Proto usar la ruta raíz provocó una vulnerabilidad de seguridad
    • Alguien argumenta que .well-known es para todo el host, así que no encaja bien a nivel de stream. Le parece mejor mantener varios directorios separados

  • La propuesta de usar .well-known/ me parece digna de consideración seria
    Ya se usa ampliamente como estándar registrado en IANA, y ahí suelen ubicarse archivos de seguridad y descubrimiento
    Si en vez de /satellite/satproto.json se pusiera en /.well-known/satproto.json, se evitarían conflictos y quedaría más claro que es un endpoint del protocolo

    • Pero le responden que .well-known es a nivel de host, así que no sirve tanto si quieres tener varios directorios por cuenta

  • Un protocolo de red social no debería existir por la tecnología en sí, sino porque le da un beneficio directo al usuario
    Como BitTorrent, tiene que lograr que la gente participe simplemente porque lo necesita, para que aparezca el efecto de red
    Me parece más realista un enfoque que parta de la gestión de datos y la comodidad para compartirlos

    • Yo he usado varias redes sociales descentralizadas y al final la gente no entra si no hay ese estímulo de dopamina
      Lemmy y Pixelfed tenían tan poco contenido que se sentían como “lugares donde no pasa nada”
      A Signal le pasa algo parecido: como es solo para mensajería, no hay “motivo para scrollear”
      Al final, para que la gente vuelva de forma constante hacen falta contenido y FOMO (miedo a perderse algo)
    • Aun así, un buen diseño de protocolo sí importa. Si es demasiado complejo o no está preparado para el futuro, hasta una buena idea desaparece rápido

  • Si de verdad se quiere crear una red social descentralizada y mensajería E2EE de verdad, hace falta una estructura tipo Discord donde cada servidor esté realmente alojado de forma independiente
    Las cuentas deberían gestionarse con un protocolo como Nostr y funcionar sobre Yggdrasil Network para reducir la dependencia de IPv4/6 y DNS
    Si además se encapsula el tráfico en HTTPS y se automatiza el cruce de NAT, cualquiera podría operar un servidor
    Solo con una estructura así se podría salir del control de las big tech y de los gobiernos

    • Pero alguien responde que la tecnología sola no basta. Las masas al final irán a la plataforma con más capital de marketing
    • Yo creo que es mejor un enfoque de red distribuida basada en caché, como BitTorrent o IPFS
      Aunque un servidor desaparezca, los datos quedan en el edge y hasta el navegador del usuario podría cumplir el rol de host
      Ver ephemeral-p2p-project
    • Algo así ya se está probando en geogram.radio
      Cada dispositivo actúa como servidor y usan WebRTC para implementar mensajería totalmente P2P
      Incluso sin internet se pueden intercambiar datos por enlace de radio
    • Yo estoy construyendo algo parecido en Mikoto Platforms. Los “Spaces” pueden existir en cualquier nodo físico y los DM se enrutan con E2EE a través de múltiples nodos

  • Antes ya hubo intentos de redes sociales totalmente descentralizadas como FOAF o Pingback

    • Su versión moderna es Webmention
      Recomiendan la wiki de IndieWeb como buen recurso para explorar este tipo de tecnologías sociales basadas en sitios personales
    • Como otro ejemplo, también recuerdan XFN

  • Al leer la descripción “sAT Protocol es una red social descentralizada basada en sitios estáticos”, me dieron ganas de dibujar una gráfica de cejas levantándose cada vez más

    • Aun así, como el alcance del objetivo es limitado, me parece un sistema razonable
      Aunque el hecho de que el texto cifrado pueda enumerarse públicamente podría ser riesgoso en una era de computación cuántica
    • Esto se parece a una combinación de PGP + RSS. Cada feed se cifra para que solo ciertas personas puedan descifrarlo
      Funciona para redes pequeñas, pero sería difícil escalarlo por los problemas de distribución y rotación de claves
    • Yo lo entiendo como una idea de “transmitir una base de datos para que el cliente construya un sitio estático”
    • La parte de “Key Rotation (Unfollow)” la expresan en tono de broma con ASCII art

  • Desde el punto de vista del usuario, siento que primero hace falta explicar qué tipo de servicio hace esto
    Está lleno de términos técnicos como forks, rutas, JSON y cifrado, pero no se alcanza a ver el escenario de uso real

    • Aun así, tengo bastantes amigos interesados en tecnología, así que pienso probarlo con gente de “gustos paranoicos de seguridad”
      Es un espacio que Mastodon o Signal no cubren del todo, así que vale la pena experimentar con esto

  • Este tipo de experimentos de redes descentralizadas me resultan realmente fascinantes
    Aunque estructuralmente tengan muchos problemas, me gusta aprender de estas combinaciones nuevas
    Eso sí, tener que volver a cifrar y reconstruir todo el sitio cada vez que sigues o dejas de seguir a alguien es demasiado engorroso
    Además, una estructura donde no puedes ver comentarios si no sigues a alguien limita mucho la escalabilidad
    Aun así, resulta atractivo que mezcle RSS, ActivityPub y sitios estáticos
    El intento de implementar control de acceso dinámico a la lista de amigos con un sitio estático es contradictorio, pero interesante
    Al final es una estructura que me hace sentir amor y odio al mismo tiempo. Igual se agradece mucho que existan intentos así