Redes sociales descentralizadas: arquitectura, protocolos y una verificación reproducible del estado de los nodos

Alcance y respuesta directa

Una red social descentralizada es cualquier sistema social en el que ningún operador único tiene control exclusivo sobre la identidad, el almacenamiento de contenido y la clasificación del feed. En la práctica encontrarás dos familias: redes federadas como Mastodon, Lemmy y Friendica, donde cada servidor es una entidad independiente que interoperan con otros mediante protocolos abiertos; y redes basadas en blockchain, donde las publicaciones, la identidad o la reputación se registran en un libro mayor distribuido y los clientes leen ese estado a través de endpoints RPC.

Este artículo está escrito para ingenieros y operadores que necesitan razonar sobre estos sistemas en lugar de elegir una aplicación favorita. Cubre el mecanismo de cada diseño, un procedimiento reproducible para inspeccionar la superficie de protocolo de un servidor federado y un flujo de trabajo de diagnóstico para la infraestructura RPC y de nodos de la que dependen los clientes sociales basados en blockchain. Las elecciones concretas de endpoints y proveedores corresponden al Asistente RPC, no a este artículo; esta página se centra en la metodología que puedes aplicar a cualquier proveedor.

• Diseño federado: servidores independientes, protocolo compartido, moderación local.
• Diseño blockchain: libro mayor compartido, firma del lado del cliente, lecturas y escrituras RPC.
• Diseño híbrido: transporte federado con identidad o anclaje en cadena.
• La verificación siempre es algo que ejecutas contra tus propios nodos y endpoints.

Supuestos y requisitos previos

Los procedimientos siguientes asumen que tienes un terminal con curl, Python 3.9 o superior y acceso de red a los servidores que deseas inspeccionar. Para la sección de blockchain necesitas una RPC_URL para la red a la que apunta tu cliente y, si pretendes probar escrituras, una cuenta de prueba con fondos. Nunca pegues una PRIVATE_KEY real en el historial de un shell compartido; usa una variable de entorno o una clave desechable en una testnet.

No necesitas ejecutar tu propio servidor social para seguir el artículo. Las comprobaciones federadas son solicitudes HTTP de solo lectura. Las comprobaciones RPC son llamadas JSON-RPC de solo lectura. Si más adelante pasas al autoalojamiento, revisa las consideraciones de alojamiento de nodos en la guía de alojamiento de nodos blockchain y la cobertura de redes que se indica en redes compatibles.

Modelo mental: federación frente a libro mayor

En una red federada, cada servidor almacena las publicaciones de sus propios usuarios y una copia en caché del contenido de los servidores que sigue. Los servidores se descubren entre sí mediante WebFinger e intercambian actividades por HTTP. El protocolo es el contrato; el servidor es la unidad de moderación. Esto significa que la disponibilidad de una publicación depende de la política y el tiempo de actividad del servidor de alojamiento, no de un consenso global.

En una red basada en blockchain, el libro mayor es la fuente de verdad compartida para todo lo que el protocolo registra —a menudo identidad, hashes de publicaciones, propinas o reputación—. Los clientes leen el estado a través de JSON-RPC y envían transacciones firmadas para las escrituras. La experiencia social se ensambla en el lado del cliente a partir de los datos del libro mayor más el almacenamiento fuera de la cadena, como IPFS. Esto desplaza la cuestión de la fiabilidad de «¿está el servidor activo?» a «¿es mi endpoint RPC consistente y de baja latencia?».

Una forma útil de compararlos es por dominio de fallo. Las redes federadas fallan por servidor y por relación de federación. Las redes blockchain fallan por proveedor RPC y por cadena, mientras que el libro mayor sigue siendo la referencia. Ambos diseños siguen dependiendo de infraestructura web ordinaria para el descubrimiento, los medios y la entrega al cliente.

• Federado: la identidad está limitada al servidor; la portabilidad depende de las herramientas de migración.
• Blockchain: la identidad está limitada a la clave; la portabilidad depende de la custodia de la clave.
• Federado: la moderación es local y explícita.
• Blockchain: la moderación es filtrado del lado del cliente o reglas a nivel de protocolo.
• Ambos: los clientes son la capa real de experiencia de usuario.

Inspección de la superficie de protocolo de un servidor federado

Antes de confiar en un servidor federado, confirma que realmente habla el protocolo que afirma. Los dos endpoints siguientes son convenciones documentadas en el ecosistema ActivityPub: WebFinger resuelve una cuenta a una URL de actor, y el documento de actor describe la bandeja de entrada y la bandeja de salida de la cuenta. Sustituye social.example y alice por el servidor y la cuenta que estás comprobando.

Una respuesta WebFinger exitosa devuelve un documento JSON con un array links que contiene un enlace self de tipo application/activity+json. Una obtención exitosa del actor devuelve un documento JSON-LD con los campos inbox, outbox y preferredUsername. Si cualquiera de las solicitudes devuelve HTML, una página de inicio de sesión o un 404, el servidor no está exponiendo una superficie de federación estándar y tu cliente debe tratarlo como opaco.

curl -sS "https://social.example/.well-known/webfinger?resource=acct:alice@social.example" \
  -H "Accept: application/jrd+json" | python3 -m json.tool

curl -sS "https://social.example/users/alice" \
  -H "Accept: application/activity+json" | python3 -m json.tool

Verificación del comportamiento de federación con una pequeña sonda en Python

Una sola solicitud demuestra poco. Una sonda breve que sigue el documento de actor y comprueba la bandeja de salida te da una señal repetible que puedes ejecutar de forma programada. El script siguiente resuelve una cuenta, obtiene el actor e informa si los campos esperados están presentes. No publica nada y no requiere credenciales.

Ejecútalo contra varios servidores de la misma federación para ver cuáles exponen una superficie consistente. Registra los resultados en una tabla con columnas para servidor, estado de WebFinger, estado del actor y presencia de bandeja de salida. No rellenes los valores esperados de memoria; deja que la sonda los produzca.

import json, sys, urllib.request

def get(url, accept):
    req = urllib.request.Request(url, headers={"Accept": accept, "User-Agent": "federation-probe/1.0"})
    with urllib.request.urlopen(req, timeout=10) as r:
        return r.status, json.loads(r.read().decode())

def probe(server, user):
    wf_url = f"https://{server}/.well-known/webfinger?resource=acct:{user}@{server}"
    status, wf = get(wf_url, "application/jrd+json")
    actor = next((l["href"] for l in wf.get("links", []) if l.get("rel") == "self"), None)
    if not actor:
        return {"server": server, "webfinger": status, "actor": None, "outbox": False}
    a_status, doc = get(actor, "application/activity+json")
    return {"server": server, "webfinger": status, "actor": a_status, "outbox": "outbox" in doc}

if __name__ == "__main__":
    print(json.dumps(probe(sys.argv[1], sys.argv[2]), indent=2))

Procedimiento de tabla de resultados para comprobaciones de federación

Usa una tabla Markdown para registrar lo que realmente devuelve tu sonda. Una plantilla en blanco se ve así: | Servidor | Estado de WebFinger | Estado del actor | Bandeja de salida presente | Notas |. Rellena cada fila a partir de una ejecución real y conserva el JSON sin procesar junto a la tabla para que un revisor pueda reproducirlo. No publiques cifras que no hayas medido; una tabla de estados es más útil que una tabla de conjeturas.

Si estás comparando servidores sociales autoalojados frente a gestionados, la misma tabla sirve. La diferencia es que las filas autoalojadas dependen de tu propio tiempo de actividad, mientras que las filas gestionadas dependen del operador. Para el lado de la infraestructura del autoalojamiento, consulta opciones de nodos dedicados y la descripción general del servicio RPC.

Clientes sociales basados en blockchain y su dependencia de RPC

Cuando un cliente social lee la identidad o los registros de publicaciones de una cadena, cada carga del feed se convierte en una o más llamadas JSON-RPC. Por lo tanto, la fiabilidad percibida del cliente es función de la latencia, la consistencia y la tasa de errores del RPC. Una primera comprobación útil es confirmar que el endpoint está en la cadena que esperas y que avanza. Las llamadas siguientes son métodos JSON-RPC estándar; sustituye RPC_URL por el endpoint de tu proveedor.

eth_chainId confirma la identidad de la cadena, y eth_blockNumber confirma que el nodo sigue la cabeza. Si el ID de cadena no coincide con la configuración de tu cliente, el cliente leerá silenciosamente el estado equivocado. Si el número de bloque está desactualizado respecto a un explorador público, el endpoint está retrasado y tu feed puede mostrar contenido obsoleto.

curl -sS -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -sS -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'

Medición de latencia y consistencia RPC para un feed social

Una sola muestra de latencia es ruido. Para caracterizar un endpoint para un cliente social, muestrea el mismo método de lectura repetidamente y registra la distribución. El script de Python siguiente llama a eth_blockNumber diez veces, imprime cada latencia e informa la dispersión. Ejecútalo contra cada endpoint candidato y compara las tablas en paralelo.

La consistencia importa tanto como la velocidad. Si dos endpoints de la misma cadena devuelven números de bloque que difieren en más de unos pocos bloques, tu cliente puede ver un estado inconsistente según a qué endpoint llegue. Para un feed social esto puede manifestarse como publicaciones que aparecen y desaparecen. Registra tanto la latencia como la concordancia del bloque cabeza en tu tabla de resultados.

import json, os, statistics, time, urllib.request

RPC_URL = os.environ["RPC_URL"]

def call(method, params=None):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params or []}).encode()
    req = urllib.request.Request(RPC_URL, data=body, headers={"Content-Type": "application/json"})
    start = time.perf_counter()
    with urllib.request.urlopen(req, timeout=10) as r:
        payload = json.loads(r.read().decode())
    return time.perf_counter() - start, payload.get("result")

latencies, heads = [], []
for _ in range(10):
    dt, head = call("eth_blockNumber")
    latencies.append(dt * 1000)
    heads.append(int(head, 16))

print("samples_ms", [round(x, 1) for x in latencies])
print("median_ms", round(statistics.median(latencies), 1))
print("head_spread_blocks", max(heads) - min(heads))

Solución de problemas comunes

Las comprobaciones federadas fallan de algunas formas reconocibles. Un 404 en WebFinger suele significar que el servidor no implementa el endpoint o que la cuenta no existe. Una respuesta 200 con un cuerpo HTML significa que un proxy inverso o un muro de inicio de sesión interceptó la solicitud; revisa el encabezado Accept y la configuración del proxy del servidor. Un documento de actor sin outbox sugiere una implementación parcial o una cuenta restringida.

Las comprobaciones RPC fallan de manera diferente. Un objeto de error JSON-RPC con código -32601 significa que el método no es compatible con ese endpoint. Un tiempo de espera agotado o un restablecimiento de conexión apunta a limitación de velocidad o filtrado de red. Una discrepancia en el ID de cadena significa que estás apuntando a la red equivocada. Un número de bloque obsoleto significa que el nodo está sincronizando o retrasado. Para una lista de verificación más amplia de problemas de endpoints, consulta la guía de endpoints RPC y la guía de endpoints multicadena.

Si ejecutas tu propio servidor social, los mismos modos de fallo se aplican a tu nodo: presión de disco, retraso de sincronización y límites de velocidad. La guía de alojamiento de nodos cubre el lado operativo.

• WebFinger 404: endpoint ausente o cuenta inexistente.
• HTML en lugar de JSON: proxy o muro de inicio de sesión.
• JSON-RPC -32601: método no compatible con el endpoint.
• Discrepancia de ID de cadena: red incorrecta configurada.
• Cabeza obsoleta: nodo sincronizando o limitado por velocidad.

Limitaciones y compensaciones

Las redes federadas intercambian consistencia global por autonomía local. Una publicación puede ser visible en un servidor y no en otro, y las decisiones de moderación no se propagan de manera uniforme. Esto es una característica para la gobernanza comunitaria y un defecto para los usuarios que esperan un único feed global. El descubrimiento entre servidores también es desigual; WebFinger y los documentos de actor están estandarizados, pero la búsqueda y la recomendación no lo están.

Las redes basadas en blockchain intercambian simplicidad operativa por verificabilidad. Cada lectura depende de un proveedor RPC, y cada escritura requiere gestión de claves. El almacenamiento en cadena es caro, por lo que la mayoría de los diseños mantienen los medios fuera de la cadena y anclan solo hashes o identidades. Esto significa que la afirmación de «descentralizado» se aplica a capas específicas, no a toda la pila. Sé preciso sobre qué capa estás evaluando.

Ninguno de los dos diseños elimina la necesidad de infraestructura ordinaria: TLS, DNS, almacenamiento en caché y monitoreo. Una red descentralizada con un único endpoint RPC sobrecargado o un único proxy inverso mal configurado está, en la práctica, centralizada en el punto de fallo.

Próximos pasos

Empieza ejecutando la sonda de federación contra tres servidores que realmente uses y registra los resultados en una tabla. Luego ejecuta el script de latencia RPC contra dos endpoints de la cadena a la que apunta tu cliente y compara la latencia mediana y la dispersión de la cabeza. Estas dos mediciones te dirán más sobre tu experiencia real que cualquier comparación de características.

Si estás eligiendo un endpoint para un cliente social basado en blockchain, usa el Asistente RPC para la decisión concreta del proveedor y vuelve aquí para el método de medición. Para la planificación de costos a medida que crece tu cliente, revisa precios de RPC. Para orientación específica de red, explora redes compatibles. Para infraestructura social autoalojada, las páginas de nodo dedicado y servicio API describen las opciones operativas.

• Ejecuta la sonda de federación en tus propios servidores.
• Mide la latencia RPC y la dispersión de la cabeza antes de comprometerte.
• Documenta los resultados en una tabla reproducible.
• Vuelve a ejecutar tras cualquier cambio de proveedor o servidor.