Org Social: la red social que sobrevive a su propia infraestructura

Org Social es tan simple que parece nacida en una época anterior a internet. Un solo archivo de texto plano, un editor y un hosting son suficientes para interactuar con otros usuarios.

Para "crear una cuenta" basta con crear un archivo de texto plano desde cualquier editor. Tu "base de datos" es tu propia jerarquía de posts, tu "algoritmo" es la forma en que tú decidas ordenar las publicaciones de los demás, el "límite de caracteres" no existe, tu "servidor" es cualquier hosting o servidor web, tu "interfaz" es tu editor favorito y, si quieres "darte de baja", solo tienes que borrar el archivo. Y, por supuesto, la sintaxis es más completa que Markdown e igual de fácil de aprender: Org Mode. Compartes y editas donde quieras, y lo usas como un microblog, un diario, un foro, un tablón de anuncios o un blog. Tu archivo, tus reglas.

Detrás hay una infraestructura que enriquece la interacción y la conexión con otros sistemas o formatos (fediverso, RSS, clientes...). Cada elemento añade un nivel más de comodidad, pero ninguno es imprescindible: ¡son 100 % opcionales! Y aquí es donde quiero entrar.

Me gustaría desmontar pieza a pieza qué hace cada uno y explicar el porqué de su existencia.

Capa 0: un archivo de texto plano

Todo empieza y termina aquí. Un archivo llamado social.org, en UTF-8, con saltos de línea LF.

La cabecera es tu perfil. Son palabras clave de Org Mode:

#+TITLE: Mi diario
#+NICK: Alice
#+DESCRIPTION: Escribo sobre Emacs y café
#+AVATAR: https://alice.com/avatar.jpg
#+LINK: https://alice.com
#+FOLLOW: https://bob.com/social.org
#+FOLLOW: amiga https://carol.net/social.org

Debajo, en una sección * Posts, van tus publicaciones. Cada una es un encabezado con una marca de tiempo en formato RFC 3339, que hace de identificador único:

** 2025-05-01T12:00:00+0100
:PROPERTIES:
:LANG: es
:TAGS: emacs org-social
:END:

Hoy he descubierto Org Social y no puedo parar de escribir.

Y ya tienes una red social.

Cualquiera puede hacer curl a tu archivo, leerlo con sus propios ojos o con un cliente o script, y seguirte añadiendo tu URL a su #+FOLLOW:.

La propia interacción vive dentro del formato. No hay botones mágicos, hay propiedades:

• Responder es un post con :REPLY_TO: <url>#<id> apuntando al original.
• Reaccionar es una respuesta con solo :MOOD: ❤ y el cuerpo vacío.
• Compartir es :INCLUDE: con la referencia al post ajeno.
• Votar en una encuesta es responder con :POLL_OPTION:.
• Mencionar a alguien es un enlace [[org-social:https://bob.com/social.org][Bob]].

Como es texto plano, puedes editarlo todo a mano si te apetece.

Al terminar, guardas el archivo y lo subes a tu servidor.

Todas las redes sociales descentralizadas tienen un punto débil, da igual la que te venga a la cabeza. Traté este tema en No existe la descentralización total, pero, en resumen, siempre hay que decidir cuál de estos cinco puntos sacrifica la red:

• Identidad
• Conectividad
• Descubrimiento
• Coste
• Moderación

Org Social sacrifica el descubrimiento. Nadie te puede descubrir si no le das tu URL, igual que ocurre con una cuenta de correo electrónico. Y eso hace que algunas interacciones sean imposibles de reconstruir. Por ejemplo, ¿qué pasa si alguien a quien no sigues participa en un hilo que has creado? Pues que, si no lo sigues, no te enteras.

Por eso necesitamos capas superiores que mitiguen el problema, aunque solo debes usarlas si lo crees necesario. Puede darse el caso de que todos los que participáis os sigáis mutuamente y no necesitéis nada más. En caso contrario, necesitarás un Relay: un índice.

Capa 1: el cliente

Puedes consultar cada feed directamente con curl o con tu navegador. Sin embargo, igual que ocurre con tu listado de feeds RSS/Atom, lo que al final hacemos todos por comodidad es usar un cliente. Lee todas las fuentes, las ordena, las filtra y las mezcla, creando un listado más cómodo de leer y que además puedes navegar. Con Org Social ocurre lo mismo.

Existe un cliente para Emacs, otro para iOS, otro para Android (en alfa mientras escribo estas líneas), implementaciones de línea de comandos y un visor web público que no requiere cuenta ni cliente. Los clientes crean un timeline mezclando todos los feeds que sigues y te permiten responder, reaccionar, compartir y votar en encuestas. Pero todos los cambios ocurren en tu propio archivo, no en un servidor central, y la lectura es volátil, ya que se construye en caliente.

Por otro lado, el cliente hace de traductor entre Org Social y la interfaz que elijas. Y es una buena puerta de entrada para quienes ya están familiarizados con X/Twitter o Mastodon, o para quienes no quieren complicarse aprendiendo la sintaxis.

Capa 2: el Relay

El Relay es un servidor que escanea la red de archivos social.org y construye un índice: usuarios, menciones, respuestas, grupos e hilos. Lo hace leyendo los #+FOLLOW: de cada feed que conoce y descargando los archivos que encuentra. También puedes registrar tu feed manualmente para que lo lea.

No almacena contenido, solo direcciones. Anota quién menciona a quién, qué responde a qué y qué pertenece a cada hilo.

Ahora puedes crear un cliente o un script que pregunte al Relay por la información que te permite reconstruir aquello en lo que antes estabas ciego:

# ¿Quién me ha mencionado?
curl "https://relay.org-social.org/notifications/?feed=..."

# Dame el hilo completo de este post
curl "https://relay.org-social.org/replies/?post=..."

# Búscame todo lo que hable de Emacs
curl "https://relay.org-social.org/search/?q=emacs"

Y no solo eso: cada persona puede tener su propio Relay, en local o en un servidor. Su instancia se conectará a otros Relays públicos e intercambiarán información para que toda la red conozca los feeds que existen y sus relaciones.

Además, ofrece otras funcionalidades, como notificaciones en tiempo real, feeds RSS/Atom, un buscador de posts o puentes con ActivityPub/Mastodon. Sí, puedes seguir cuentas de Mastodon desde Org Social, o enterarte de las novedades de Org Social desde tu cliente RSS/Atom favorito.

Capa 3: Org Social Host

Es duro que te exijan un hosting para empezar a participar en la red. Por eso existe un servicio de hosting gratuito y abierto, integrado con los clientes, que pone tu social.org en línea con solo pulsar un botón.

Eliges un nick y recibes dos direcciones:

• public-url: la que compartes con todo el mundo, por ejemplo https://host.org-social.org/alice/social.org.
• vfile: una URL secreta y firmada que hace de contraseña. Quien la tenga puede sobrescribir tu archivo, así que guárdala bien.

Si usas un cliente, todo esto es automático y nunca llegas a ver la URL secreta, ya que se guarda en tu configuración. Todo ocurre por detrás.

Si tienes curiosidad, registrarte es una sola petición:

curl -X POST https://host.org-social.org/signup \
  -H "Content-Type: application/json" \
  -d '{"nick": "alice"}'

Y sobrescribir tu archivo, otra:

curl -X POST https://host.org-social.org/upload \
  -F "vfile=TU_VFILE" \
  -F "file=@social.org"

Tampoco te ata para el futuro: puedes pedirle una redirección permanente (HTTP 301) hacia tu nueva URL y tus seguidores ni se enteran. Sus clientes siguen la redirección solos, aunque conviene avisarles para que actualicen su #+FOLLOW:. Es una puerta de entrada, no un requisito.

También puedes levantarlo en tu propio servidor, bloqueando el registro público y usando tu propio dominio.

Además, tiene una ventaja que los más veteranos creando apps habrán intuido: facilita la sincronización entre dispositivos. Puedes, por ejemplo, escribir en el cliente del móvil y continuar en el de Emacs con sencillas peticiones HTTP. Sin recurrir a protocolos antiguos ni a APIs de terceros.

Capa 4: Mirror o CDN

¿Usas un lector de RSS/Atom? Entonces ya sabes que, cuantos más feeds sigues, más lento va.

Da igual lo rápido y paralelizado que descargue. Siempre habrá cortes de conexión, timeouts, errores y redirecciones. Y si un feed es muy grande, el cliente tiene que parsearlo entero para quedarse con lo que le interesa.

En mi caso, sigo 250 feeds. ¿Descargarlos y parsearlos cada vez que hago scroll? Inviable. ¿Cachearlos? Entonces el problema pasa a ser cuándo invalidar la caché.

Aquí es donde entra el Mirror. Es un servidor que mantiene una copia actualizada de todos los feeds y te ahorra el parseo, la ordenación, la construcción de hilos y la consolidación de menciones. Expone una sencilla API REST que devuelve JSON listo para usar en un cliente.

Puedes considerarlo un cliente de clientes, o un cliente generalista sin interfaz. Internamente, trabaja sin parar para tener la copia más reciente y preparar la información ya procesada, de forma que sea fácil de consumir.

Por ejemplo, si quiero construir el timeline con los posts de Bob y Carol de los últimos 14 días:

curl --get "https://mirror.org-social.org/api/posts/" \
  --data-urlencode "following=https://bob.com/social.org" \
  --data-urlencode "following=https://carol.net/social.org" \
  --data-urlencode "sinceDays=14"

No sustituye al Relay; de hecho, lo necesita para saber qué feeds existen y cuáles han cambiado. Y lo más importante: es de solo lectura. Nunca edita ni borra nada en el origen. Para publicar, sigues escribiendo en tu propio archivo. Su única puerta de entrada es un webhook que un cliente puede llamar para avisar de que un feed ha cambiado y de que el Mirror debe actualizarlo:

curl -X POST "https://mirror.org-social.org/api/webhook/refresh/" \
  -H "Content-Type: application/json" \
  -d '{"feed": "https://alice.com/social.org"}'

Es opcional. El cliente lo llama justo después de publicar o de subir una nueva versión del archivo a tu hosting, para que el Mirror actualice su copia al momento y no espere al siguiente ciclo de actualización.

Capa 5: Push

El Relay ya emite notificaciones en tiempo real con Server-Sent Events, que los clientes pueden escuchar para avisarte de menciones, respuestas y reacciones. Pero los móviles no dejan que una app mantenga conexiones abiertas en segundo plano, así que ahí hay que usar notificaciones push. Es la capa más específica de todas, ya que cada plataforma, iOS y Android, tiene su propio sistema de notificaciones con sus propios certificados y tokens.

Si esta capa cae, lo único que se pierde es la comodidad de recibir avisos en el móvil cuando la app está cerrada.

Capa 6: Live Preview

Un post de Org Social tiene una dirección con el formato https://<host>/social.org#<timestamp>. Por ejemplo, mi primer post: https://host.org-social.org/andros/social.org#2025-08-14T09:11:00+0200. Funciona bien entre clientes de Org Social, pero ¿qué pasa si quieres compartirlo en otra red social? Nada bonito: se compartirá el archivo social.org entero.

Live Preview convierte un post en una página web. Le pasas la URL del post, descarga el social.org original (directamente de su origen, sin pasar por el Relay), busca la publicación y genera una tarjeta HTML con sus metadatos Open Graph: nick, avatar, texto y fecha. Lista para compartir en cualquier red social.

Por ejemplo, la URL de arriba se convierte en:

https://preview.org-social.org/?post=https%3A%2F%2Fhost.org-social.org%2Fandros%2Fsocial.org%232025-08-14T09%3A11%3A00%2B0200

Y si lo comparto en redes sociales, se verá así:

Además, los clientes usan este formato de enlace en su opción de compartir.

De esta misma necesidad nació otra funcionalidad muy interesante: generar un blog HTML a partir de tu social.org, si lo tienes alojado en host.org-social.org.

Por ejemplo, mi representación web de Org Social sería preview.org-social.org/blog/andros.

Escribes en Org Mode, subes el archivo al hosting (si quieres, con un simple curl) y automáticamente se genera tu blog HTML, listo para compartir. No es perfecto, ya que no controlas el diseño, pero te ahorras tener que ejecutar un generador de sitios estáticos.

Resumen

Al final no son capas, sino piezas que orbitan alrededor de tu social.org.

flowchart TB
    Archivo["social.org"]
    Cliente["Cliente"]
    Relay["Relay"]
    Host["Host"]
    Mirror["Mirror"]
    Push["Push"]
    Preview["Live Preview"]

    Cliente -- "lee y escribe" --> Archivo
    Cliente -- "sube y sincroniza" --> Host
    Host -- "aloja" --> Archivo
    Host -- "registra feeds" --> Relay
    Relay -- "indexa" --> Archivo
    Cliente -- "menciones, hilos y búsqueda" --> Relay
    Mirror -- "qué feeds existen y cuáles cambian" --> Relay
    Mirror -- "copia" --> Archivo
    Cliente -- "timeline en JSON y webhook" --> Mirror
    Relay -- "notificaciones en tiempo real" --> Push
    Push -- "avisos en el móvil" --> Cliente
    Preview -- "lee" --> Archivo
    Cliente -- "enlace para compartir" --> Preview

Uses lo que uses la única pieza imprescindible es tu social.org.

Si mañana se apagan todos los servidores de Org Social, ¿qué pierdes? Comodidad. ¿Y qué te queda? Tu archivo, intacto, en tu disco. Lo subes a cualquier otro sitio y sigues publicando.

Pocas redes sociales pueden decir lo mismo.