Descentralización en redes sociales: arquitectura, protocolos y medición

Alcance y los tres modelos de descentralización

Las redes sociales descentralizadas no son un único diseño. El término abarca al menos tres arquitecturas distintas, y confundirlas lleva a malas decisiones de ingeniería. Las redes federadas (sistemas basados en ActivityPub como Mastodon, Lemmy y PixelFed) funcionan en servidores operados de forma independiente que intercambian mensajes. Las redes basadas en relés (Nostr) publican eventos firmados en múltiples relés, y los clientes eligen qué relés leer y escribir. Las redes sociales respaldadas por blockchain almacenan identidad, grafos sociales o referencias de contenido en un libro mayor distribuido, a menudo con el contenido en sí en IPFS o almacenamiento similar.

Cada modelo descentraliza cosas diferentes. La federación descentraliza el alojamiento y la moderación, pero mantiene la identidad ligada a un servidor de origen. Las redes de relés descentralizan la publicación y la resistencia a la censura, pero trasladan el filtrado a los clientes. Los modelos blockchain descentralizan la identidad y las reclamaciones de propiedad, pero añaden latencia de consenso y costo. Una pregunta útil para cualquier plataforma es: ¿cuál de la identidad, el almacenamiento de contenido, la clasificación del feed y la moderación puede cambiar unilateralmente un solo operador?

Este artículo asume que puede ejecutar herramientas de línea de comandos, hacer solicitudes HTTP y leer JSON. No asume que opere un servidor social. Donde la selección de endpoints importa, la elección concreta del proveedor corresponde a RPC Assistant; esta página se centra en la metodología y la medición reproducible.

• Federada: protocolo compartido, servidores independientes, moderación local del servidor.
• Basada en relés: eventos firmados, múltiples relés, filtrado del lado del cliente.
• Respaldada por blockchain: identidad o referencias de contenido ancladas en el libro mayor, almacenamiento externo para los datos.

Modelo mental: identidad, almacenamiento, clasificación y moderación

Trate cada plataforma social como cuatro funciones separables. La identidad es cómo se nombra y autentica una cuenta. El almacenamiento es dónde viven las publicaciones y los medios. La clasificación es cómo se ordena un feed. La moderación es quién puede eliminar o limitar contenido. Las plataformas centralizadas agrupan las cuatro bajo un solo operador. Los diseños descentralizados las separan, y el patrón de separación predice los problemas operativos que encontrará.

En la federación, la identidad es un identificador en un servidor de origen (por ejemplo, usuario@instancia), el almacenamiento es el servidor de origen más las cachés en servidores remotos, la clasificación suele ser cronológica o del lado del cliente, y la moderación se divide entre el servidor de origen y cada servidor receptor. En las redes de relés, la identidad es una clave pública, el almacenamiento es cada relé que aceptó el evento, la clasificación la define el cliente, y la moderación es la política del relé más las listas de silenciados del cliente. En los modelos blockchain, la identidad puede ser una billetera o un nombre registrado, el almacenamiento suele estar fuera de la cadena, la clasificación la define la aplicación, y la moderación a menudo se aplica en la capa del cliente o del indexador.

Este modelo explica una sorpresa común: una publicación puede ser visible en un servidor e invisible en otro porque el servidor receptor decidió no federar o almacenó el contenido de forma diferente. Por lo tanto, la disponibilidad es una propiedad de la ruta entre servidores, no de un único origen.

Mecánica de los protocolos: ActivityPub, relés y anclaje en el libro mayor

ActivityPub define un protocolo servidor a servidor en el que los actores publican actividades (Create, Follow, Announce) en bandejas de entrada y salida. La entrega se basa en push: el servidor de origen hace POST de una actividad firmada a la bandeja de entrada de cada seguidor. Si una bandeja de entrada remota está caída, la entrega puede reintentarse o descartarse según la implementación. Por eso la fiabilidad de la federación depende de las colas de reintento y de la salud de muchos servidores independientes.

Nostr invierte el flujo. Un cliente firma un evento con una clave privada y lo publica en uno o más relés mediante WebSocket. Los lectores se suscriben a los relés y filtran eventos localmente. No hay un servidor de origen; hay un conjunto de relés que pueden aceptar o rechazar eventos según su política. La latencia está dominada por los viajes de ida y vuelta al relé y por cuántos relés consulta un cliente.

Los sistemas sociales respaldados por blockchain anclan un registro mínimo en la cadena, como un registro de perfil o un hash de contenido, y almacenan los datos en otro lugar. Las lecturas requieren un indexador o acceso RPC a la cadena. Las escrituras requieren una transacción, lo que introduce tiempo de bloque y variabilidad de tarifas. Para un tratamiento más amplio de los patrones de acceso a nodos detrás de estas lecturas, consulte la guía sobre alojamiento de nodos blockchain.

Requisitos previos y un plan de pruebas reproducible

Antes de medir nada, defina qué está probando. Un plan útil cubre tres dimensiones: disponibilidad (pueden los clientes alcanzar el servicio), latencia (cuánto tarda una lectura o escritura) y portabilidad (puede un usuario exportar y reimportar sus datos). Registre la versión del cliente, las condiciones de red y la hora del día en cada ejecución.

Use marcadores de posición para todos los endpoints. Reemplace RELAY_URL, INSTANCE_URL y RPC_URL con valores de su propia infraestructura o de un proveedor que haya seleccionado. No codifique endpoints públicos en scripts compartidos; cambian y pueden aplicarle límites de velocidad.

Ejecute cada medición al menos diez veces y reporte la mediana y el percentil 95 en lugar de una sola muestra. Una única respuesta rápida no es evidencia de fiabilidad.

• Disponibilidad: código de estado HTTP y tasa de éxito de conexión WebSocket.
• Latencia: tiempo hasta el primer byte para lecturas, tiempo de ida y vuelta para escrituras.
• Portabilidad: integridad de la exportación y éxito de la reimportación.
• Consistencia: si la misma publicación es visible desde múltiples puntos de observación.

Medición de latencia de relés e instancias con curl

Para endpoints de federación basados en HTTP, curl ofrece una lectura rápida de la alcanzabilidad y el tiempo hasta el primer byte. El siguiente script consulta un endpoint WebFinger, que los servidores federados exponen para el descubrimiento de actores, e informa los tiempos. Reemplace INSTANCE_URL y el recurso con su objetivo.

El resultado de verificación esperado es un HTTP 200 con un cuerpo JSON que contiene enlaces, además de valores de tiempo en la salida. Un 404 significa que el actor no existe en esa instancia; un tiempo de espera agotado significa que la instancia no es alcanzable desde su red. Repita desde al menos dos redes para distinguir problemas de enrutamiento local de caídas del servidor.

#!/usr/bin/env bash
# Measure WebFinger latency for a federated actor
INSTANCE_URL="https://INSTANCE_URL"
RESOURCE="acct:user@INSTANCE_URL"
for i in $(seq 1 10); do
  curl -sS -o /dev/null \
    -w "%{http_code} %{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total}\n" \
    "${INSTANCE_URL}/.well-known/webfinger?resource=${RESOURCE}"
done

Medición de viajes de ida y vuelta a relés con JavaScript

Las redes basadas en relés usan conexiones WebSocket. El siguiente script abre una conexión a RELAY_URL, envía un filtro de suscripción y registra el tiempo hasta que llega el primer evento coincidente. Usa el paquete ws y un relé de marcador de posición. Ejecútelo contra varios relés para comparar la latencia del primer evento.

Verificación esperada: el script imprime una latencia en milisegundos para cada relé, o un error si la conexión falla. Un relé que se conecta pero nunca devuelve un evento dentro de su tiempo de espera debe registrarse como tiempo de espera agotado, no como latencia cero. Agregue los resultados en una tabla con columnas para relé, tiempo de conexión, tiempo del primer evento y estado.

const WebSocket = require('ws');

const RELAY_URL = 'wss://RELAY_URL';
const TIMEOUT_MS = 5000;

function measure(relayUrl) {
  return new Promise((resolve) => {
    const start = Date.now();
    const ws = new WebSocket(relayUrl);
    let connectedAt = null;
    const timer = setTimeout(() => {
      ws.terminate();
      resolve({ relayUrl, status: 'timeout', connectedAt, firstEventAt: null });
    }, TIMEOUT_MS);

    ws.on('open', () => {
      connectedAt = Date.now() - start;
      ws.send(JSON.stringify(['REQ', 'probe', { kinds: [1], limit: 1 }]));
    });

    ws.on('message', (data) => {
      const msg = JSON.parse(data.toString());
      if (msg[0] === 'EVENT') {
        clearTimeout(timer);
        ws.close();
        resolve({ relayUrl, status: 'ok', connectedAt, firstEventAt: Date.now() - start });
      }
    });

    ws.on('error', () => {
      clearTimeout(timer);
      resolve({ relayUrl, status: 'error', connectedAt, firstEventAt: null });
    });
  });
}

(async () => {
  const results = await Promise.all([
    measure(RELAY_URL),
    measure('wss://RELAY_URL_2')
  ]);
  console.table(results);
})();

Tabla de resultados y cómo leerla

Registre cada ejecución en una tabla con las mismas columnas para que los resultados sean comparables entre relés, instancias y días. La siguiente tabla es una plantilla; complétela con sus propias mediciones en lugar de tomar cifras de otros lugares.

Lea la tabla comparando primero las medianas y luego el p95. Un relé con una mediana baja pero un p95 alto es inestable bajo carga. Un relé con una mediana alta pero un p95 ajustado es consistentemente lento, lo que aún puede ser aceptable para lecturas en segundo plano. El estado debe distinguir ok, timeout y error para que las fallas no se promedien en la latencia.

Prueba de portabilidad de datos e integridad de exportaciones

La portabilidad es la prueba práctica de la descentralización. Las plataformas federadas suelen ofrecer una exportación de seguidos y, a veces, de publicaciones. Las redes de relés dependen de que los clientes vuelvan a publicar eventos. Los modelos blockchain pueden exponer registros en cadena pero dejar los medios fuera de la cadena. Una prueba de portabilidad verifica si una exportación contiene cada elemento que espera y si una reimportación restaura el grafo social.

Procedimiento: exporte los datos de su cuenta, cuente los registros por tipo y luego impórtelos en una segunda cuenta en un servidor o cliente diferente. Compare los recuentos y verifique aleatoriamente las marcas de tiempo. Registre cualquier pérdida de medios, respuestas o relaciones de seguimiento. Este es un procedimiento manual, pero produce la evidencia más relevante para la toma de decisiones sobre el bloqueo.

Para sistemas respaldados por blockchain, la verificación equivalente es si el registro en cadena puede resolverse sin el front end original. Consulte la cadena a través de un indexador o endpoint RPC y confirme que el hash de contenido se resuelve en datos recuperables. Si el hash solo se resuelve a través de la puerta de enlace de una sola empresa, el sistema es descentralizado de nombre pero no de recuperación.

Solución de problemas comunes de descentralización

Publicaciones faltantes en servidores remotos. La entrega federada puede haber fallado o el servidor remoto puede haber bloqueado el origen. Revise los registros de entrega del origen y la política de moderación del servidor remoto. No hay un reintento global que pueda activar desde el cliente.

El relé acepta escrituras pero las lecturas no devuelven nada. Los relés pueden aceptar eventos y luego podarlos, o aplicar filtros. Consulte varios relés y compare. Si solo un relé devuelve el evento, trate ese relé como un punto único de falla para ese contenido.

Lecturas lentas de perfiles respaldados por blockchain. El cuello de botella suele ser el endpoint RPC o el indexador, no la cadena en sí. Mida el tiempo hasta el primer byte contra su RPC_URL y compare proveedores. Para la selección de endpoints, use RPC Assistant; para obtener información sobre el comportamiento de RPC, consulte la guía de endpoints RPC.

La identidad no se puede mover. Si su identificador está vinculado a un servidor de origen, la migración depende del soporte de movimiento del protocolo. Pruébelo antes de comprometerse con un servidor. La identidad basada en relés, en cambio, es un par de claves que usted controla, pero perder la clave pierde la identidad.

Limitaciones y compensaciones de cada modelo

La federación mejora la diversidad de alojamiento y la moderación local, pero no garantiza la disponibilidad: una publicación depende del servidor de origen y de la voluntad de cada servidor receptor de almacenarla en caché. Las redes de relés mejoran la resiliencia de publicación pero trasladan el filtrado y la defensa contra spam a los clientes, lo que aumenta la complejidad del cliente. Los modelos blockchain proporcionan identidad y propiedad verificables, pero añaden costo de transacción, latencia y una dependencia del indexador para lecturas prácticas.

Ninguno de estos modelos elimina la moderación; la reubican. La pregunta de ingeniería relevante es quién asume el costo de la moderación y cuán transparente es ese costo. Un administrador de servidor que debe cumplir con la ley local tiene restricciones diferentes a las de un cliente que puede silenciar localmente. Las revisiones de diseño deben indicar qué parte puede eliminar contenido y en qué condiciones.

El rendimiento también varía según la arquitectura. La latencia de la federación está dominada por la entrega servidor a servidor y el almacenamiento en caché. La latencia de los relés está dominada por los viajes de ida y vuelta WebSocket y el número de relés. Las lecturas de blockchain están dominadas por el rendimiento del RPC y del indexador. Mida cada una por separado en lugar de tratar "descentralizado" como una única clase de rendimiento.

Próximos pasos: construir una línea base de medición

Comience eligiendo una instancia federada y dos relés que realmente use, luego ejecute los scripts anteriores semanalmente y almacene los resultados en el mismo formato de tabla. Añada una prueba de portabilidad una vez por trimestre. Si opera un servidor, supervise las colas de entrega y la latencia de las solicitudes salientes; si consume datos sociales respaldados por blockchain, supervise la tasa de errores y la latencia p95 de su proveedor de RPC.

Para las decisiones de infraestructura detrás de estas mediciones, revise precios de RPC y nodos dedicados para comprender las compensaciones de costo y aislamiento. El comportamiento específico de cada red está documentado en redes compatibles, y el acceso gestionado a la API se describe en la descripción general del servicio de API. Para recomendaciones concretas de endpoints y proveedores, use RPC Assistant en lugar de adivinar a partir de listas públicas.

El objetivo no es declarar una arquitectura superior. Es saber, con sus propias cifras, dónde falla cada sistema y si su comunidad puede tolerar ese modo de falla.