Redes sociales descentralizadas: protocolos, arquitectura y un plan de pruebas reproducible

Qué descentralizan realmente las redes sociales descentralizadas

Las redes sociales descentralizadas describen redes en las que las funciones centrales de una plataforma social —identidad, alojamiento de contenido, descubrimiento y moderación— no están todas controladas por una sola empresa. La palabra importante es todas. Una plataforma puede descentralizar el alojamiento manteniendo un único proveedor de identidad, o descentralizar la identidad manteniendo un único algoritmo de feed. Esos son compromisos diferentes y fallan de maneras distintas.

El modelo mental práctico consiste en separar cuatro capas: identidad (quién eres), contenido (dónde viven las publicaciones), distribución (cómo llegan las publicaciones a los seguidores) y gobernanza (quién puede eliminar o clasificar contenido). Los diseños federados suelen descentralizar el contenido y la distribución entre servidores, mientras que la identidad está limitada a un servidor de origen. Los diseños basados en blockchain normalmente descentralizan la identidad y las referencias de contenido a un libro mayor, pero la distribución y la moderación a menudo permanecen fuera de la cadena. Ningún modelo es automáticamente más privado o más resistente; cada uno mueve el límite de confianza en lugar de eliminarlo.

Esta guía trata las redes sociales descentralizadas como un tema de ingeniería: qué protocolos transportan los datos, cómo verificar que una implementación se comporta según lo documentado y qué mediciones debe ejecutar usted mismo antes de hacer afirmaciones sobre rendimiento.

• Federado: servidores independientes interoperan mediante un protocolo abierto como ActivityPub.
• Basado en blockchain: la identidad, la propiedad o los hashes de contenido se registran en un libro mayor compartido.
• Híbrido: libro mayor para identidad y pagos, servidores convencionales para medios y feeds.
• Entre pares: contenido replicado entre clientes o retransmisores sin un host central.

Supuestos y requisitos previos para los procedimientos

Las comprobaciones a continuación suponen que dispone de un terminal con curl, Node.js 18 o superior y Python 3.9 o superior. Para las comprobaciones de redes sociales basadas en blockchain necesita acceso a un endpoint RPC de la red correspondiente; utilice un marcador de posición como RPC_URL y proporcione su propio proveedor. Si está eligiendo un proveedor para una aplicación social que lee identidad o referencias de contenido en la cadena, la guía de endpoints RPC explica qué comparar, y el servicio de API RPC describe los patrones de acceso gestionado.

Ningún procedimiento aquí requiere acceso privilegiado a un servidor social. Todas las comprobaciones son de solo lectura y pueden ejecutarse contra su propia implementación o una instancia pública que permita la inspección. No ejecute pruebas de carga contra instancias que no opere.

Arquitectura federada: servidores, actores y entrega a bandejas de entrada

En una red federada al estilo ActivityPub, cada usuario se representa como un actor con un identificador estable alojado en un servidor de origen. Cuando el usuario publica, el servidor de origen almacena el objeto y lo entrega a las bandejas de entrada de los seguidores remotos. Los servidores remotos deciden entonces si aceptan, muestran o descartan ese contenido según sus propias políticas. Por eso la moderación es local: el servidor emisor no puede obligar a un servidor receptor a conservar una publicación.

La consecuencia para los operadores es que la federación es un problema de entrega tanto como un problema de almacenamiento. Un servidor lento en firmar y entregar actividades aparecerá ante sus usuarios como un servidor cuyas publicaciones no llegan a la red más amplia. Un servidor lento en obtener actores remotos mostrará hilos incompletos. Ambos son medibles y ambos dependen de la salud de la pila HTTP saliente del servidor y de su base de datos, no solo del protocolo.

• Los documentos de actor describen la identidad y las claves públicas.
• La bandeja de salida enumera las actividades creadas por un actor.
• La bandeja de entrada recibe las actividades entregadas por otros servidores.
• Las firmas HTTP autentican la entrega entre servidores.

Inspección de un documento de actor federado con curl

El primer diagnóstico para cualquier implementación federada es si el documento de actor es accesible y está bien formado. Reemplace ACTOR_URL con el identificador de actor que desea inspeccionar. La respuesta debe ser JSON con id, type, inbox y outbox.

Una comprobación exitosa devuelve HTTP 200 y un cuerpo JSON cuyo id coincide con la URL solicitada. Si el cuerpo es HTML, probablemente esté accediendo a una redirección o a una página de error. Si falta el campo inbox, el actor no puede recibir actividades federadas y la entrega fallará silenciosamente desde la perspectiva del emisor.

curl -sS -D headers.txt \
  -H 'Accept: application/activity+json' \
  "$ACTOR_URL" -o actor.json

head -n 1 headers.txt
python3 - <<'PY'
import json
with open('actor.json') as f:
    actor = json.load(f)
for key in ('id', 'type', 'inbox', 'outbox'):
    print(key, '=>', actor.get(key))
PY

Redes sociales basadas en blockchain: qué almacena y qué no almacena el libro mayor

Las redes sociales basadas en blockchain utilizan un libro mayor para las partes que se benefician de un estado compartido y a prueba de manipulaciones: registro de identidad, propiedad de contenido, aristas del grafo social o hashes de contenido. Los medios y los textos largos suelen permanecer fuera de la cadena porque almacenarlos en la cadena es caro y permanente. Por lo tanto, el libro mayor es una capa de coordinación, no una red de entrega de contenido.

Esta separación importa cuando se evalúa la fiabilidad. Una publicación puede estar anclada en la cadena mientras sus medios no están disponibles porque el host fuera de la cadena se cayó. Un perfil puede ser propiedad de una billetera mientras el front end que lo muestra depende de un único proveedor RPC. Cuando mida una aplicación social basada en blockchain, mida la ruta de lectura del libro mayor y la ruta de medios fuera de la cadena por separado.

• En la cadena: identidad, propiedad, referencias y, a veces, pagos o propinas.
• Fuera de la cadena: medios, texto de formato largo, índices y clasificación de feeds.
• Dependencia de RPC: cada lectura en la cadena pasa por un proveedor de nodos.
• Compromiso de permanencia: los datos en la cadena son duraderos pero costosos de cambiar.

Lectura del estado social en la cadena a través de un endpoint RPC

El siguiente script de Node.js realiza una llamada de solo lectura contra un endpoint compatible con EVM. Utiliza eth_blockNumber y eth_getBlockByNumber como comprobación mínima de salud antes de cualquier llamada a nivel de aplicación. Reemplace RPC_URL con el endpoint de su proveedor. Para redes e identificadores de cadena, consulte el directorio de redes compatibles.

Una respuesta saludable devuelve un número de bloque en hexadecimal y un objeto de bloque con una marca de tiempo. Si el número de bloque está desactualizado en relación con el tiempo de bloque esperado de la red, el endpoint está retrasado. Si la solicitud expira, el fallo está en la ruta de transporte o del proveedor, no en la lógica de la aplicación social.

const RPC_URL = process.env.RPC_URL;

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 })
  });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const body = await res.json();
  if (body.error) throw new Error(body.error.message);
  return body.result;
}

const blockNumber = await rpc('eth_blockNumber');
const block = await rpc('eth_getBlockByNumber', [blockNumber, false]);
console.log('block', parseInt(blockNumber, 16));
console.log('timestamp', parseInt(block.timestamp, 16));

Un procedimiento de medición reproducible para cualquier implementación

Las afirmaciones sobre el rendimiento de las redes sociales descentralizadas solo son útiles si son reproducibles. Ejecute el mismo procedimiento contra cada implementación candidata y registre valores brutos en lugar de conclusiones. La siguiente tabla es una plantilla; complétela con sus propias mediciones y mantenga el método idéntico entre filas.

Ejecute cada métrica al menos tres veces en diferentes momentos del día. Registre el endpoint, la región y la versión del cliente junto con los números. No compare filas medidas con métodos diferentes. Si necesita un endpoint dedicado para eliminar la varianza del proveedor compartido de la fila RPC, la opción de nodo dedicado es el control relevante, y los precios de RPC explican cómo se asigna la capacidad.

Resultados de verificación esperados y cómo interpretarlos

Un actor federado configurado correctamente devuelve JSON con un id coincidente y un inbox accesible. Un endpoint RPC configurado correctamente devuelve un número de bloque que avanza entre dos llamadas separadas por el tiempo de bloque de la red. Un host de medios configurado correctamente devuelve HTTP 200 para una muestra de archivos adjuntos de publicaciones recientes.

Cuando un resultado se desvía, clasifique el fallo antes de cambiar algo. Un inbox faltante es un error de configuración del protocolo. Un número de bloque desactualizado es un error de infraestructura o del proveedor. Un 404 de medios es un error de almacenamiento o retención. Cada clase tiene un propietario diferente y una solución diferente, y mezclarlas conduce a cambios que no abordan la causa.

• Error de protocolo: documento de actor mal formado o claves de firma faltantes.
• Error de entrega: acumulación en la cola de salida o fallo de DNS/TLS.
• Error del proveedor: latencia RPC, limitación de velocidad o cabeza desactualizada.
• Error de almacenamiento: medios eliminados, movidos o nunca replicados.

Solución de problemas comunes en redes sociales descentralizadas

Las publicaciones no se federan. Compruebe primero el documento de actor, luego la cola de entrega saliente. Si el actor es válido pero las entregas fallan, inspeccione TLS y la resolución DNS desde el servidor. La federación depende de nombres de host resolubles públicamente y certificados válidos.

Los hilos se muestran incompletos. El servidor receptor no puede obtener actores u objetos remotos. Esto suele ser un problema de HTTP saliente o un límite de velocidad impuesto por el servidor remoto. Revise los registros en busca de tiempos de espera de obtención y respuestas HTTP 429.

Las lecturas de perfil en la cadena fallan de forma intermitente. El endpoint RPC está limitando la velocidad o retrasándose. Compare los números de bloque entre dos proveedores antes de asumir que el contrato tiene la culpa. La guía de RPC multicadena cubre patrones de conmutación por error.

Los medios desaparecen mientras las publicaciones permanecen. El host fuera de la cadena no replicó el contenido o lo dejó expirar. Para publicaciones ancladas en blockchain, esta es la brecha de durabilidad más común, porque la referencia del libro mayor sobrevive a los medios a los que apunta.

Limitaciones y compromisos que no se pueden eliminar por diseño

La descentralización mueve la confianza; no la elimina. Las redes federadas concentran el poder en los administradores de servidores, que pueden defederar, moderar o cerrar una comunidad. Las redes basadas en blockchain concentran el poder en quien controla los contratos, el front end y la ruta RPC. Los usuarios que no pueden ejecutar infraestructura siguen dependiendo de alguien.

También hay costos duros. La federación multiplica el trabajo de almacenamiento y entrega a medida que los servidores se siguen entre sí. El almacenamiento en la cadena es permanente y tiene un precio acorde, lo que empuja la mayor parte del contenido fuera de la cadena y reintroduce el riesgo de disponibilidad. La moderación en una red federada es local y, por lo tanto, inconsistente entre servidores, lo que es una característica para algunas comunidades y una responsabilidad para otras. Cualquier decisión de arquitectura debe indicar cuál de estos compromisos acepta.

Próximos pasos para desarrolladores y operadores

Si está construyendo un servicio federado, comience validando los documentos de actor y las colas de entrega en un entorno de pruebas antes de abrir la federación. Si está construyendo una aplicación social basada en blockchain, separe la ruta de lectura del libro mayor de la ruta de medios y mida ambas. Para los equipos que ejecutan su propia infraestructura, la guía de alojamiento de nodos cubre la base operativa que ambos modelos comparten.

Para la selección de endpoints, mantenga la decisión separada de la arquitectura. La biblioteca RPC Assistant contiene comparativas enfocadas como la mejor API RPC de Ethereum y el mejor proveedor RPC de Solana; utilícelas cuando necesite una recomendación concreta de proveedor en lugar de una discusión de diseño. Sea cual sea el camino que elija, registre sus mediciones con el método anterior para que el siguiente operador pueda reproducirlas.