Aplicaciones de redes sociales descentralizadas: arquitectura, protocolos y realidad operativa

Qué descentralizan realmente las aplicaciones de redes sociales descentralizadas

Una aplicación de redes sociales descentralizada es un cliente que lee y escribe datos sociales a través de infraestructura que ninguna empresa controla por completo. Esa es la única definición que se mantiene en toda la categoría. Todo lo demás —si las publicaciones viven en servidores federados, relays de gossip o contratos inteligentes— es una elección de implementación con diferentes modos de fallo.

La forma útil de evaluar cualquier aplicación de redes sociales descentralizada es preguntar qué capa está descentralizada y qué capa sigue efectivamente centralizada. Las aplicaciones federadas estilo Mastodon descentralizan el alojamiento y la moderación, pero aún dependen de DNS, TLS y los operadores de servidores. Las aplicaciones estilo Nostr descentralizan la publicación mediante relays, pero dependen de la disponibilidad de los relays y del filtrado del lado del cliente. Las aplicaciones sociales on-chain descentralizan la identidad y la liquidación, pero generalmente dependen de indexadores y endpoints RPC para que las lecturas sean lo suficientemente rápidas para un feed.

Este artículo cubre las tres arquitecturas dominantes, cómo probar la infraestructura de la que depende cada una y dónde los equipos diagnostican mal los problemas con mayor frecuencia. No recomienda una aplicación específica. Para elecciones concretas de endpoints y proveedores, utilice el RPC Assistant.

• Modelo federado: servidores independientes interoperan mediante un protocolo abierto como ActivityPub.
• Modelo de relays: los clientes publican eventos firmados en múltiples relays y obtienen datos de muchos a la vez.
• Modelo on-chain o híbrido: la identidad, los punteros de contenido o los pagos se liquidan en una blockchain; las lecturas pasan por RPC e indexadores.

Supuestos y requisitos previos para los diagnósticos

Los procedimientos a continuación asumen que tiene una terminal con curl, Node.js 18 o posterior y Python 3.9 o posterior. Asumen que puede acceder a Internet público y que tiene valores de marcador de posición para cualquier endpoint que no controle. Reemplace RPC_URL, RELAY_URL e INSTANCE_URL con valores de su propio entorno; no pegue claves privadas en el historial del shell.

Para los componentes on-chain, necesita un endpoint RPC para la red correspondiente. Si aún está eligiendo uno, el RPC Assistant cubre la selección de endpoints y el directorio de redes de OnFinality enumera las cadenas compatibles. Para cargas de trabajo en producción, los nodos dedicados eliminan los efectos de vecino ruidoso que distorsionan las mediciones de latencia.

• curl para comprobaciones a nivel HTTP contra instancias y endpoints RPC.
• Node.js para comprobaciones de relays WebSocket y lotes JSON-RPC.
• Python para muestreo de latencia repetible y salida tabular.
• Una hoja de cálculo o tabla de terminal para registrar resultados; no confíe en una sola muestra.

Arquitectura federada: servidores, bandejas de entrada y el costo de la federación

En una aplicación federada, cada instancia aloja cuentas y almacena publicaciones localmente. Cuando un usuario sigue a alguien en otra instancia, los dos servidores intercambian actividades por HTTP, normalmente firmadas con HTTP Signatures. El servidor receptor coloca la actividad en la bandeja de entrada local de cada seguidor. El feed que ve un usuario se ensambla a partir de copias locales, no de una consulta global.

Este diseño otorga a los operadores de instancias un poder de moderación real y brinda a los usuarios portabilidad entre servidores, pero convierte la entrega en un problema por servidor. Una instancia lenta o mal configurada no solo afecta a sus propios usuarios; retrasa la entrega a todos los que siguen cuentas allí. La federación también implica que el almacenamiento crece con el grafo social que sigues, porque las publicaciones remotas se almacenan en caché localmente.

La consecuencia práctica es que las aplicaciones federadas se diagnostican mejor en la capa HTTP. Si faltan publicaciones, verifique si la instancia emisora puede alcanzar el endpoint de bandeja de entrada de la instancia receptora, si las firmas se validan y si el servidor receptor está poniendo en cola las entregas.

• Un 401 o 403 en la bandeja de entrada generalmente significa que falló la validación de la firma, no que el servidor esté caído.
• Un 202 en la bandeja de entrada significa que la actividad fue aceptada para su procesamiento; no garantiza que se haya entregado a los seguidores.
• Un time_total alto en la obtención del actor sugiere que la instancia está sobrecargada o que el servidor remoto es lento.

curl -sS -o /dev/null -w 'status=%{http_code} time_total=%{time_total}s\n' \
  -H 'Accept: application/activity+json' \
  "$INSTANCE_URL/users/admin"

curl -sS -o /dev/null -w 'inbox_status=%{http_code} time_total=%{time_total}s\n' \
  -X POST -H 'Content-Type: application/activity+json' \
  --data '{"type":"Ping"}' \
  "$INSTANCE_URL/inbox"

Arquitectura de relays: eventos firmados y lecturas multi-relay

Las aplicaciones basadas en relays invierten el modelo federado. Los clientes firman eventos con un par de claves y los publican en relays. Los relays almacenan y reenvían eventos, pero no poseen la identidad. Un lector normalmente se conecta a varios relays y fusiona los resultados, filtrando por autor y tipo de evento. Esto hace que la publicación sea resistente a la caída de cualquier relay individual, pero traslada la complejidad al cliente y a la selección de relays.

La pregunta operativa clave para una aplicación basada en relays no es si un relay está activo, sino si el conjunto de relays del que depende ofrece una cobertura y latencia aceptables. Un relay que acepta escrituras pero descarta eventos silenciosamente es peor que uno que los rechaza, porque el cliente no puede notar la diferencia sin verificar otros relays.

La comprobación a continuación abre un WebSocket a un relay, envía una suscripción mínima e informa si el relay responde dentro de un tiempo de espera. Ejecútela contra cada relay de su conjunto configurado.

// relay-check.mjs — run with: node relay-check.mjs
const RELAY_URL = process.env.RELAY_URL || 'wss://relay.example.com';
const ws = new WebSocket(RELAY_URL);
const started = Date.now();
const timer = setTimeout(() => {
  console.log(`${RELAY_URL} timeout after ${Date.now() - started}ms`);
  ws.close();
  process.exit(1);
}, 5000);

ws.addEventListener('open', () => {
  ws.send(JSON.stringify(['REQ', 'probe', { kinds: [1], limit: 1 }]));
});

ws.addEventListener('message', (event) => {
  const msg = JSON.parse(event.data);
  if (msg[0] === 'EOSE' || msg[0] === 'EVENT') {
    clearTimeout(timer);
    console.log(`${RELAY_URL} responded in ${Date.now() - started}ms`);
    ws.close();
  }
});

ws.addEventListener('error', () => {
  clearTimeout(timer);
  console.log(`${RELAY_URL} connection error after ${Date.now() - started}ms`);
  process.exit(1);
});

Aplicaciones on-chain e híbridas: dónde entra la latencia RPC en el feed

Las aplicaciones sociales on-chain almacenan alguna combinación de identidad, hashes de contenido, seguimientos y pagos en una blockchain. La cadena proporciona garantías de orden y disponibilidad, pero no es una base de datos de feeds. Las lecturas las sirven nodos RPC y, en la mayoría de las aplicaciones en producción, un indexador que observa eventos de contratos y construye vistas consultables.

Aquí es donde las aplicaciones de redes sociales descentralizadas heredan con mayor frecuencia características de rendimiento centralizadas. La cadena puede ser descentralizada, pero si cada solicitud de feed llega a un solo proveedor RPC, ese proveedor ahora está en la ruta crítica. Lo mismo ocurre con el indexador: si se retrasa, los usuarios ven publicaciones obsoletas aunque la cadena esté sana.

El diagnóstico a continuación mide la latencia JSON-RPC y la consistencia de la altura de bloque entre dos endpoints. Ejecútelo contra sus URL RPC primaria y de respaldo y registre los resultados en una tabla. Una gran diferencia en la altura de bloque entre endpoints es una señal de problema más fuerte que una sola solicitud lenta.

import json, time, urllib.request

ENDPOINTS = {
    "primary": "RPC_URL",
    "fallback": "RPC_URL_FALLBACK",
}

def rpc(url, method, params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(url, data=body, headers={"Content-Type": "application/json"})
    start = time.perf_counter()
    with urllib.request.urlopen(req, timeout=10) as resp:
        payload = json.loads(resp.read())
    return payload, (time.perf_counter() - start) * 1000

for name, url in ENDPOINTS.items():
    samples = []
    height = None
    for _ in range(5):
        payload, ms = rpc(url, "eth_blockNumber", [])
        samples.append(ms)
        height = int(payload["result"], 16)
    print(f"{name}: median={sorted(samples)[2]:.1f}ms height={height}")

Un procedimiento de medición reproducible y tabla de resultados

Las mediciones solo son útiles si son repetibles. Utilice la misma máquina, la misma ruta de red y la misma ventana de tiempo para cada endpoint que compare. Ejecute al menos 20 muestras por endpoint e informe la mediana y el p95 en lugar de un único número del mejor caso. Registre la marca de tiempo y la región de la máquina que realiza la medición, porque la latencia de RPC y relays está dominada por la distancia de red.

La tabla a continuación es una plantilla. Rellénela con sus propios valores medidos; no copie números de ningún artículo, incluido este. El procedimiento es el entregable, no un benchmark.

Interprete la tabla comparando componentes, no persiguiendo números absolutos. Si su p95 de RPC es varias veces la mediana, tiene un problema de latencia de cola que se manifestará como estancamientos intermitentes del feed. Si las tasas de error de los relays difieren marcadamente, el conjunto de relays de su cliente está desequilibrado. Si la obtención del actor de la instancia es lenta pero la bandeja de entrada acepta actividades, la entrega aún puede funcionar mientras las páginas de perfil se sienten rotas.

Verificar que una publicación realmente se propagó

Una respuesta de escritura exitosa no es prueba de propagación. En aplicaciones federadas, el servidor emisor devuelve éxito una vez que ha puesto en cola la actividad. En aplicaciones de relays, un relay puede confirmar un evento y aun así no servirlo a los lectores. En aplicaciones on-chain, una transacción puede incluirse mientras el indexador aún no ha procesado el bloque.

Verifique la propagación en la capa de lectura. Para aplicaciones federadas, obtenga la publicación desde una segunda instancia que siga al autor. Para aplicaciones de relays, consulte un relay diferente para el mismo ID de evento. Para aplicaciones on-chain, lea el evento del contrato desde un segundo endpoint RPC y compare el número de bloque con la altura reportada por su indexador.

Si la escritura tuvo éxito pero la lectura falla, el problema casi siempre está en la capa de entrega o indexación, no en el cliente. Esa distinción ahorra horas de depuración del componente equivocado.

• Federado: lea la publicación desde una segunda instancia; un 404 allí significa que la entrega no se completó.
• Relay: consulte el ID del evento en un relay al que el autor no publicó; la ausencia es esperada, la presencia confirma la propagación entre relays.
• On-chain: compare la altura del indexador con la cabeza de la cadena; un retraso de más de unos pocos bloques indica un problema de indexación.

Solución de problemas por síntoma

La mayoría de las fallas reportadas en aplicaciones de redes sociales descentralizadas caen en un pequeño número de categorías. Relacione el síntoma con la capa antes de cambiar la configuración.

El feed está vacío pero la cuenta existe: verifique si el cliente puede alcanzar sus relays o instancias, luego compruebe si el indexador o la caché local tienen datos. Un feed vacío con una cuenta sana generalmente significa una falla en la ruta de lectura.

Las publicaciones se publican pero nadie las ve: verifique la propagación en la capa de lectura. En aplicaciones federadas, esto suele ser un problema de firma o de bandeja de entrada en el lado receptor. En aplicaciones de relays, suele ser un relay que acepta escrituras pero no sirve lecturas.

Tiempos de espera intermitentes: mida el p95, no la mediana. La latencia de cola en conexiones RPC o de relays frecuentemente proviene de la reutilización de conexiones, límites de tasa o un único backend degradado detrás de un balanceador de carga.

Datos on-chain obsoletos: compare la altura del indexador con la cabeza de la cadena desde dos endpoints RPC independientes. Si ambos endpoints coinciden y el indexador se retrasa, el problema es el indexador, no la cadena.

Limitaciones y compensaciones de cada modelo

Las aplicaciones federadas ofrecen una moderación sólida y portabilidad, pero concentran el costo operativo en los operadores de instancias y hacen de la entrega entre instancias una fuente persistente de latencia y fallos. Las aplicaciones de relays ofrecen publicación resistente, pero trasladan las decisiones de filtrado y confianza a los clientes, y los conjuntos de relays pueden degradarse silenciosamente. Las aplicaciones on-chain ofrecen identidad y liquidación verificables, pero dependen de infraestructura RPC e indexación que a menudo es menos descentralizada que la propia cadena.

Ninguno de estos modelos elimina la necesidad de medición operativa. La descentralización cambia quién es responsable de un componente; no elimina el componente. Los equipos que tratan a los proveedores RPC, relays e indexadores como dependencias medidas lanzan aplicaciones más confiables que los equipos que los tratan como magia.

También hay una compensación de gobernanza. La moderación federada es local y rápida pero inconsistente entre instancias. La moderación on-chain es transparente pero lenta y costosa. La moderación de relays es mínima por diseño, lo que traslada la carga al filtrado del lado del cliente y a la elección del usuario.

Próximos pasos para desarrolladores y operadores

Comience instrumentando la capa de la que realmente depende su aplicación. Si opera una instancia federada, mida la aceptación en la bandeja de entrada y la latencia de obtención del actor. Si construye un cliente de relays, mida el tiempo de respuesta y la tasa de error por relay. Si construye una aplicación social on-chain, mida la latencia RPC y el retraso del indexador juntos, porque cualquiera de los dos puede estancar un feed.

Para lecturas on-chain en producción, pase de endpoints públicos compartidos a nodos dedicados para que sus mediciones reflejen su propia capacidad en lugar de un grupo compartido. Revise el modelo de precios de RPC antes de escalar y utilice el RPC Assistant cuando necesite una recomendación concreta de endpoint para una red específica.

Finalmente, mantenga un registro escrito de su procedimiento de medición y su tabla de referencia. Cuando un feed se estanque dentro de seis semanas, la forma más rápida de encontrar la causa es comparar con una línea base en la que confíe.

• Instrumente la ruta de lectura, no solo la de escritura.
• Registre líneas base con marcas de tiempo y regiones.
• Separe la salud de la cadena de la salud del indexador en aplicaciones on-chain.
• Vuelva a medir después de cualquier cambio de proveedor o conjunto de relays.