Redes sociales descentralizadas: protocolos, arquitectura y una ruta de implementación práctica

Qué cambia realmente la descentralización de las redes sociales

Una red social descentralizada elimina el único punto de estrangulamiento del que dependen las plataformas centralizadas: un operador que aloja cuentas, clasifica el feed y puede eliminar unilateralmente a un usuario. En la práctica, la descentralización es un espectro. Una red federada como el fediverso mantiene el contenido en servidores operados de forma independiente que hablan un protocolo compartido, de modo que un usuario de un servidor puede seguir y responder a un usuario de otro. Una red social basada en blockchain lleva la identidad, las publicaciones o el grafo social a un libro mayor, de modo que cualquier cliente que pueda leer la cadena puede reconstruir el estado de la red.

La consecuencia importante para la ingeniería es que el cliente ya no es el límite del producto. En un diseño federado, el servidor es la unidad de moderación y disponibilidad; en un diseño basado en cadena, el endpoint RPC y el indexador son la unidad de disponibilidad de lectura. Ambos diseños trasladan los problemas difíciles de 'construir un feed' a 'acordar un protocolo, verificar firmas y mantener lecturas consistentes'.

• Federado: servidores independientes, protocolo compartido, moderación local, identidad portátil dentro del protocolo.
• Basado en blockchain: identidad y contenido anclados en el libro mayor, reconstrucción del lado del cliente, lecturas dependientes de RPC.
• Híbrido: transporte federado para acciones sociales, cadena para identidad o pagos.

Suposiciones y requisitos previos antes de construir

Esta guía asume que puedes ejecutar un servidor pequeño o contenedor, que tienes Node.js 18+ o Python 3.10+ disponible, y que tienes un RPC_URL para cualquier cadena que pretendas leer. No asume un proveedor específico; la selección de endpoint es una decisión separada cubierta en el material del Asistente RPC enlazado abajo. Si estás evaluando infraestructura para una aplicación social basada en cadena, comienza por la guía de endpoints RPC multicadena y la guía de endpoints RPC antes de hacer benchmarks.

Para trabajo federado necesitas un dominio que controles y la capacidad de servir HTTPS, porque los actores de ActivityPub se identifican mediante URLs HTTPS y las firmas están vinculadas a esas URLs. Para trabajo basado en cadena necesitas un endpoint con capacidad de archivo si planeas rellenar publicaciones históricas, ya que los grafos sociales crecen y las consultas de historial completo contra un nodo podado fallarán.

Modelo mental: federación versus anclaje en libro mayor

Las redes sociales federadas son paso de mensajes entre servidores. Cada cuenta es un 'actor' con una bandeja de entrada y una de salida. Cuando publicas, tu servidor entrega una Actividad firmada a las bandejas de entrada de los servidores de tus seguidores. Esos servidores verifican la firma HTTP contra la clave pública de tu actor, luego almacenan y renderizan la publicación localmente. No hay una base de datos global; el estado de la red es la unión de lo que cada servidor eligió aceptar y conservar.

Las redes sociales ancladas en libro mayor son reconstrucción de estado a partir de un registro. Una publicación es una transacción o un registro firmado referenciado en cadena; el grafo social se deriva leyendo eventos y aplicándolos en orden. La cadena proporciona orden y evidencia de manipulación, pero no proporciona un feed. Aún necesitas un indexador para convertir eventos crudos en líneas de tiempo, recuentos de seguidores y árboles de respuestas. Ese indexador es donde vive la mayor parte de tu riesgo operativo.

• Federación: la entrega es push y por servidor; el fallo es parcial y local.
• Libro mayor: la entrega es de escritura única; las lecturas dependen de la frescura del indexador y la disponibilidad del RPC.
• Ambos: la identidad es una clave pública o par de claves, y la verificación es el límite de seguridad.

Verificar un actor federado con una solicitud ejecutable

Antes de confiar en cualquier comportamiento de federación, confirma que un documento de actor es accesible y está bien formado. Los actores de ActivityPub se sirven como JSON con un encabezado Accept. Reemplaza el host de marcador de posición con un servidor que operes o estés evaluando.

Una respuesta correcta devuelve el tipo de contenido application/activity+json (o un perfil compatible), un id que coincide con la URL solicitada, una publicKey con un owner, y URLs de inbox/outbox en el mismo origen. Si el id no coincide con la URL que solicitaste, la verificación de firma posterior fallará, que es la causa más común de los informes 'mi servidor no puede seguir a nadie'.

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

Verificar la entrega a la bandeja de entrada y el manejo de firmas

Los fallos de federación suelen manifestarse como no entrega silenciosa en lugar de errores. El diagnóstico es inspeccionar la cola de entrega saliente de tu servidor y los registros del servidor receptor para ver los resultados de verificación de firma. Una comprobación mínima es confirmar que la clave pública de tu actor es obtenible y que el keyId en tu firma resuelve al mismo actor.

El script a continuación obtiene un actor e imprime los campos que importan para la verificación de firma. Ejecútalo contra tu servidor y contra un par con el que intentas federar; una discrepancia en la propiedad de la clave o una redirección en la URL del actor explica la mayoría de los fallos.

import json, urllib.request

def actor(url):
    req = urllib.request.Request(url, headers={"Accept": "application/activity+json"})
    with urllib.request.urlopen(req, timeout=10) as r:
        data = json.load(r)
    print("id:", data.get("id"))
    print("inbox:", data.get("inbox"))
    print("outbox:", data.get("outbox"))
    key = data.get("publicKey", {})
    print("keyId:", key.get("id"))
    print("owner:", key.get("owner"))

actor("https://YOUR_DOMAIN/users/alice")

Indexar eventos sociales en cadena a través de RPC

Para una red social basada en cadena, la ruta de lectura es un indexador que escanea registros en busca de los eventos de tu contrato social y los escribe en un almacén consultable. El procedimiento a continuación es un esqueleto de diagnóstico: obtiene el último bloque, luego recupera registros para una dirección de contrato en un rango acotado. Usa un RPC_URL de marcador de posición y una dirección de contrato real que controles.

Mantén el rango de bloques pequeño en la primera ejecución. Los endpoints públicos a menudo limitan los rangos de getLogs, y se requieren endpoints de archivo para rellenos profundos. Si necesitas lecturas históricas consistentes, un nodo dedicado elimina la variación de límite de tasa compartido que hace impredecible la sincronización del indexador; consulta opciones de nodo dedicado y precios de RPC para la compensación operativa.

const RPC_URL = process.env.RPC_URL;
const ADDRESS = "0xYOUR_SOCIAL_CONTRACT";

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params })
  });
  const body = await res.json();
  if (body.error) throw new Error(JSON.stringify(body.error));
  return body.result;
}

(async () => {
  const latest = parseInt(await rpc("eth_blockNumber", []), 16);
  const from = "0x" + (latest - 500).toString(16);
  const to = "0x" + latest.toString(16);
  const logs = await rpc("eth_getLogs", [{ address: ADDRESS, fromBlock: from, toBlock: to }]);
  console.log("blocks", from, to, "events", logs.length);
})();

Resultados de verificación esperados y qué te dicen

Una comprobación de federación saludable devuelve un documento de actor cuyo id es igual a la URL solicitada, un inbox en el mismo origen, y un owner de publicKey que coincide con el id del actor. Una comprobación de indexador saludable devuelve un arreglo de registros sin errores y un rango de bloques que avanza entre ejecuciones. Si el arreglo de registros está vacío, confirma la dirección del contrato y el tema del evento antes de asumir que el indexador está roto.

Registra cada ejecución en una tabla de resultados en lugar de confiar en una sola observación. La tabla a continuación es una plantilla; complétala con tus propias mediciones y no publiques cifras que no hayas observado.

• | Comprobación | Método | Observado | Criterio de aprobación |
• | Documento de actor | curl con encabezado Accept | (registrar) | id coincide con URL, owner de clave coincide |
• | Entrega a bandeja de entrada | registro de entrega del servidor | (registrar) | Actividad firmada aceptada, sin 4xx |
• | Escaneo de registros | eth_getLogs rango acotado | (registrar) | sin errores, eventos analizados |
• | Latencia de lectura | llamadas RPC cronometradas | (registrar) | dentro de tu SLO |

Medir latencia y disponibilidad sin adivinar

Las aplicaciones sociales descentralizadas son intensivas en lectura: las líneas de tiempo, los perfiles y los árboles de respuestas se obtienen con mucha más frecuencia que la escritura de publicaciones. Mide la ruta de lectura por separado de la ruta de escritura. Para lecturas respaldadas por RPC, cronometra un lote fijo de llamadas (por ejemplo, eth_blockNumber y eth_getLogs en un rango conocido) a un intervalo constante y registra p50 y p95. Para lecturas federadas, cronometra las obtenciones de actor y outbox en varios servidores pares, ya que la latencia entre servidores domina.

Ejecuta la misma medición contra al menos dos endpoints o dos servidores pares para que puedas distinguir un proveedor lento de una red lenta. Si estás comparando proveedores para una aplicación social basada en cadena, el mejor proveedor RPC para proyectos Web3 y la guía de alojamiento de nodos blockchain cubren los criterios operativos; la elección real del endpoint corresponde al Asistente RPC, no a un benchmark que no ejecutaste.

import time, statistics, urllib.request, json

RPC_URL = "RPC_URL"

def call(method, params):
    body = json.dumps({"jsonrpc":"2.0","id":1,"method":method,"params":params}).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:
        json.load(r)
    return (time.perf_counter() - start) * 1000

samples = [call("eth_blockNumber", []) for _ in range(20)]
print("p50_ms", round(statistics.median(samples), 1))
print("p95_ms", round(sorted(samples)[int(len(samples)*0.95)-1], 1))

Solución de problemas que parecen errores de descentralización

La mayoría de los informes de 'la descentralización está rota' son fallos ordinarios de sistemas distribuidos. En el lado federado, las principales causas son redirecciones de URL de actor, desfase de reloj que rompe la validez de la firma, y servidores que bloquean agentes de usuario desconocidos. En el lado de la cadena, las principales causas son límites de rango de getLogs, leer de un nodo podado cuando el indexador necesita historial, y reorganizaciones que invalidan bloques indexados recientemente.

Maneja las reorganizaciones explícitamente: rastrea una profundidad de confirmación y vuelve a escanear los últimos N bloques en cada ejecución. Maneja los fallos de federación explícitamente: registra el estado HTTP y el resultado de verificación de firma para cada intento de entrega, y reintenta con retroceso exponencial. Ninguno de los dos problemas se resuelve añadiendo más servidores; ambos se resuelven haciendo observable el fallo.

• Discrepancia de id de actor: corrige la URL canónica y cualquier redirección de proxy inverso.
• Firma rechazada: verifica el reloj del sistema y la rotación de claves.
• getLogs vacío: verifica dirección, tema y rango de bloques contra un evento conocido.
• Línea de tiempo obsoleta: verifica el retraso del indexador y la profundidad de confirmación.

Limitaciones y compensaciones de cada arquitectura

Las redes federadas heredan la moderación y disponibilidad de cada servidor. Eso es una característica para la gobernanza comunitaria y una responsabilidad para el tiempo de actividad: si tu servidor cae, las identidades de tus usuarios se oscurecen aunque el protocolo sea abierto. La portabilidad existe en principio, pero migrar seguidores y contenido entre servidores sigue siendo operativamente difícil.

Las redes ancladas en libro mayor heredan el perfil de disponibilidad y costo de la cadena y su capa RPC. Las escrituras cuestan gas o tarifas, las lecturas dependen de indexadores que debes operar o confiar, y la permanencia del contenido corta en ambos sentidos: la eliminación se convierte en una convención social en lugar de una garantía. Ninguna arquitectura es estrictamente mejor; la elección depende de si tu comunidad valora más el control de moderación local o el estado global verificable.

Próximos pasos: de la verificación a un despliegue funcional

Comienza levantando un actor federado y un indexador contra una testnet, luego ejecuta los procedimientos de verificación anteriores hasta que ambos pasen de manera consistente. Solo entonces añade un segundo servidor o un segundo endpoint RPC, para que puedas atribuir fallos a una capa específica. Si estás eligiendo cadenas para una aplicación social, revisa las redes soportadas y la descripción general del servicio API antes de comprometerte con un diseño de indexador.

Para la selección de endpoint específicamente, usa el Asistente RPC en lugar de adivinar a partir de una lista: está enfocado en recomendaciones breves y directas de proveedores y redes, mientras que esta guía cubre la arquitectura y el método de medición. Mantén tu tabla de mediciones con el despliegue para que los cambios futuros se comparen contra líneas base observadas, no suposiciones.