Arquitectura de plataformas de redes sociales descentralizadas: protocolos, nodos y verificación

Alcance y respuesta directa

Una plataforma de redes sociales descentralizada es una red social en la que ningún operador único controla todo el sistema. Las cuentas, las publicaciones y las políticas de moderación residen en servidores operados de forma independiente o se replican en relays y ledgers, y los clientes utilizan protocolos abiertos para descubrir e intercambiar contenido. El término abarca redes federadas construidas sobre ActivityPub, redes basadas en relays como Nostr y aplicaciones sociales respaldadas por blockchain donde las referencias de identidad o contenido se anclan en la cadena.

Este artículo está escrito para ingenieros y operadores que necesitan comprender la arquitectura, levantar un nodo o relay y verificar que la infraestructura se comporta correctamente. No recomienda una plataforma única. Las opciones concretas de endpoints y proveedores pertenecen a la base de conocimientos de RPC Assistant, mientras que la metodología para medir la fiabilidad se cubre aquí.

• Modelo federado: servidores independientes intercambian actividades firmadas a través de ActivityPub.
• Modelo de relay: los clientes publican eventos firmados en muchos relays y leen de muchos relays.
• Modelo de ledger: la identidad, la propiedad o los punteros de contenido se registran en una blockchain.
• Modelo híbrido: un front end federado con identidad o pagos en la cadena.

Suposiciones y requisitos previos

Los procedimientos a continuación asumen un host Linux con Docker, curl y Python 3 disponibles, un nombre de dominio que usted controle y terminación TLS a través de un proxy inverso. Para software federado necesita HTTPS entrante en el puerto 443 y un certificado válido. Para componentes basados en relays o cadenas necesita HTTPS saliente y, para el trabajo con cadenas, un endpoint RPC que usted controle o en el que confíe.

También debe decidir qué va a medir antes de desplegar. La fiabilidad percibida de una plataforma social es función de la disponibilidad del servidor, la latencia de entrega de la federación, la aceptación del relay y, para los componentes en cadena, la consistencia del RPC. Cada uno de estos tiene una prueba diferente.

• Un host con al menos 2 vCPU y 4 GB de RAM para una instancia federada pequeña.
• Un registro DNS que apunte al host y un certificado TLS.
• Docker y Docker Compose para un despliegue reproducible.
• Una RPC_URL para cualquier componente de identidad o contenido respaldado por cadena.
• Un registro de mediciones para que los resultados sean comparables a lo largo del tiempo.

Modelo mental: identidad, contenido y entrega

Cada plataforma de redes sociales descentralizada responde de manera diferente a tres preguntas: quién posee una identidad, dónde se almacena el contenido y cómo llega el contenido a los lectores. En los sistemas federados, la identidad es un identificador en un dominio, el contenido se almacena en el servidor de origen y la entrega ocurre mediante solicitudes POST de servidor a servidor que transportan actividades JSON firmadas. En los sistemas de relays, la identidad es una clave pública, el contenido es un evento firmado y la entrega significa publicar el evento en múltiples relays que pueden o no almacenarlo. En los sistemas de ledger, la identidad o la propiedad es un par de claves con estado en la cadena, y el contenido puede seguir viviendo fuera de la cadena con solo referencias registradas.

Esta distinción importa operativamente. Un servidor federado que está caído pierde su línea de tiempo local, pero otros servidores conservan copias en caché de algunas publicaciones. Un relay que rechaza un evento significa que ese evento es invisible para los clientes que solo leen ese relay. Un endpoint RPC de cadena que devuelve estado obsoleto puede hacer que una verificación de identidad o propiedad sea incorrecta aunque el contenido social en sí esté bien.

• Federación: actividades firmadas, inbox/outbox por actor, reintentos de entrega.
• Relays: eventos firmados, múltiples lectores independientes, sin ordenación global.
• Ledger: identidad de par de claves, referencias en la cadena, cargas fuera de la cadena.
• Moderación: política local por servidor o relay, no global.

Despliegue de un nodo federado con Docker Compose

El siguiente archivo Compose es un patrón mínimo para un servidor federado. Reemplace la imagen con el software que haya elegido y establezca las variables de entorno para su dominio. El objetivo es un despliegue reproducible que pueda reiniciar y medir, no una configuración reforzada para producción.

services:
  social:
    image: your-federated-server:latest
    restart: unless-stopped
    environment:
      LOCAL_DOMAIN: social.example.com
      DB_HOST: db
      DB_NAME: social
      DB_USER: social
      DB_PASS: ${DB_PASS}
      REDIS_HOST: redis
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: social
      POSTGRES_USER: social
      POSTGRES_PASSWORD: ${DB_PASS}
    volumes:
      - db-data:/var/lib/postgresql/data
  redis:
    image: redis:7
    restart: unless-stopped
volumes:
  db-data:

Verificación del comportamiento de federación y relays

Después de que el servicio arranque, verifique que el endpoint del actor sea accesible y devuelva el documento JSON-LD esperado. Para software compatible con ActivityPub, la URL del actor suele ser https://social.example.com/users/admin. Una respuesta correcta incluye el id del actor, inbox, outbox y la clave pública. Si la respuesta es HTML o una página de inicio de sesión, la federación fallará porque los servidores remotos esperan JSON.

Para sistemas basados en relays, publique un evento de prueba firmado y luego consúltelo en varios relays. El resultado esperado es que al menos un relay devuelva el evento y que la firma se verifique. Registre qué relays aceptaron y cuáles rechazaron el evento, porque la aceptación del relay no está garantizada y es una fuente común de contenido faltante.

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

curl -sS -X POST https://relay.example.com/ \
  -H 'Content-Type: application/json' \
  -d '{"type":"EVENT","pubkey":"PUBKEY","content":"test","sig":"SIGNATURE"}'

Medición de la fiabilidad de RPC y relays

Los componentes sociales respaldados por cadena dependen de endpoints RPC, y los componentes basados en relays dependen de la disponibilidad del relay. Mida ambos con la misma disciplina: número fijo de solicitudes, intervalo fijo y una tabla de resultados registrada. No informe un único número de latencia como benchmark; informe la distribución y el recuento de errores.

Ejecute el siguiente script de Python contra una RPC_URL y una URL de relay. Envía un número fijo de solicitudes, registra el éxito, el error y la latencia, e imprime una tabla Markdown que puede pegar en sus propias notas. Reemplace RPC_URL y RELAY_URL con sus propios endpoints.

import json, statistics, time, urllib.request

RPC_URL = "RPC_URL"
RELAY_URL = "https://relay.example.com/"
N = 50

def timed(url, payload=None):
    start = time.perf_counter()
    try:
        req = urllib.request.Request(url, data=payload,
            headers={"Content-Type": "application/json"})
        with urllib.request.urlopen(req, timeout=5) as r:
            r.read()
        return True, (time.perf_counter() - start) * 1000
    except Exception:
        return False, (time.perf_counter() - start) * 1000

for name, url, payload in [
    ("rpc", RPC_URL, json.dumps({"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}).encode()),
    ("relay", RELAY_URL, None),
]:
    results = [timed(url, payload) for _ in range(N)]
    ok = [ms for success, ms in results if success]
    print(f"| {name} | {N} | {len(ok)} | {N-len(ok)} | {statistics.median(ok) if ok else 'n/a'} |")

Lectura de la tabla de resultados

El script imprime una tabla con columnas para objetivo, solicitudes, éxitos, errores y latencia mediana. Un resultado saludable tiene cero errores y una latencia mediana consistente con la distancia de su red. Un resultado con errores intermitentes generalmente apunta a limitación de velocidad, problemas de TLS o un endpoint sobrecargado. No compare medianas entre diferentes recuentos de solicitudes o intervalos.

Complete los valores medidos de su propia ejecución. Si necesita un endpoint gestionado para el lado del RPC, las páginas de RPC Assistant sobre la mejor API RPC de Ethereum y el mejor proveedor RPC de Solana explican cómo elegir uno; el procedimiento de medición anterior es el que utiliza para confirmar la elección.

Solución de problemas comunes

Los fallos de federación suelen manifestarse como servidores remotos que no reciben publicaciones. Verifique que el endpoint del actor devuelva JSON, que la clave de firma coincida con la publicada en el documento del actor y que la cadena de certificados TLS esté completa. Muchos servidores rechazan certificados autofirmados e intermedios caducados.

Los fallos de relay suelen manifestarse como eventos que se publican correctamente pero nunca aparecen en los lectores. Verifique la firma del evento, los tipos de evento aceptados por el relay y si el relay requiere pago o autenticación. Para componentes respaldados por cadena, verifique que el endpoint RPC esté en la red correcta y que el número de bloque esté avanzando; un endpoint obsoleto puede devolver estado antiguo sin error.

• El actor devuelve HTML: verifique la negociación de contenido y los encabezados del proxy inverso.
• Firma rechazada: verifique los ID de clave y la serialización canónica.
• El relay rechaza el evento: verifique el tipo de evento, el tamaño y la firma.
• RPC devuelve un bloque obsoleto: compare los números de bloque entre dos endpoints.
• Errores TLS: verifique la cadena de certificados completa.

Limitaciones y compensaciones

Las plataformas de redes sociales descentralizadas intercambian simplicidad operativa por control. La federación aumenta la latencia de entrega y convierte la moderación en un problema de política por servidor. Los sistemas de relays mejoran la resistencia a la censura pero no garantizan que un relay determinado almacene su evento. La identidad respaldada por ledger ofrece fuertes garantías de propiedad pero añade dependencia de RPC y riesgo de gestión de claves.

Ninguno de estos modelos elimina la necesidad de una infraestructura fiable. Un servidor federado sigue siendo un servidor que puede caerse, y un relay sigue siendo un servicio que puede limitar la velocidad. La diferencia es que el fallo es local en lugar de global, lo cual es el principal beneficio arquitectónico y el principal costo operativo.

Próximos pasos

Comience con un solo nodo y un registro de mediciones. Una vez que tenga números de referencia, compárelos con un endpoint gestionado o un segundo relay para ver si su cuello de botella es local o ascendente. Para componentes respaldados por cadena, revise la guía de endpoints RPC y la guía de endpoints RPC multicadena antes de escalar, y utilice la opción de nodo dedicado cuando necesite un rendimiento predecible.

Si está eligiendo un endpoint para una red específica, utilice las páginas de RPC Assistant en lugar de adivinar. El artículo que está leyendo le proporciona el método; la elección del endpoint es una decisión separada que depende de su cadena, su presupuesto de latencia y su presupuesto.

• Lea la guía de endpoints RPC para la configuración de referencia.
• Compare proveedores con la guía de endpoints RPC multicadena.
• Revise los precios de RPC antes de comprometerse con un proveedor.
• Verifique las redes compatibles antes de desplegar un componente respaldado por cadena.