El estado de la web descentralizada en 2026

Una red social es descentralizada en sentido práctico cuando un usuario puede cambiar de proveedor sin perder su identidad, sus datos o sus seguidores, y ActivityPub, el AT Protocol y Solid cumplen cada uno un subconjunto distinto de esa prueba.

Elegir un servidor y seguir unas cuantas cuentas es la parte fácil. El vocabulario que acompaña a estas redes (PDS, relay, AppView, Pod, WebID) se acumula rápidamente, y nada de eso importa demasiado hasta el día en que quieres mudarte.

Este es un informe de situación sobre los tres protocolos que hoy importan para la web descentralizada. Explica cómo cada uno modela la identidad, los datos y la audiencia, indica en qué punto se encuentra cada uno en términos de adopción y de especificación, mantiene separadas las cuentas registradas de los usuarios activos en las cifras, y termina con un servicio que puedes poner en marcha en una tarde.

¿Qué significa descentralizado en la práctica?

Descentralizado significa que puedes abandonar a quien aloja tu cuenta y llegar a otro sitio con tres cosas intactas: tu identidad (el nombre por el que la gente te conoce y las credenciales que lo respaldan), tus datos (publicaciones, contenido multimedia, seguimientos, ajustes) y tu audiencia (las personas que te siguen y que continúan recibiendo lo que publicas). Si pierdes cualquiera de las tres, el cambio equivale a empezar de cero con pasos adicionales.

Cada protocolo a continuación se mide contra esa prueba, no contra cuántos servidores existen ni quién escribió el software. El recuento de servidores te habla de redundancia. La prueba de tres partes te habla de dependencia del proveedor (lock-in).

¿Cómo federa ActivityPub entre instancias?

ActivityPub, una Recomendación del W3C desde el 23 de enero de 2018, federa haciendo que cada servidor entregue las actividades de un usuario directamente en los inboxes de los servidores que alojan a los seguidores de ese usuario. Cada usuario es un actor con un inbox y un outbox; publicar escribe en tu outbox, y tu servidor hace un POST de la actividad al inbox de cada seguidor. No hay índice central, solo servidores enviándose JSON unos a otros.

Mastodon, Pixelfed, Lemmy y PeerTube lo implementan todos, y por eso una cuenta de Mastodon puede seguir un canal de PeerTube o una comunidad de Lemmy.

La identidad es donde falla la prueba. Un handle como @user@instance.example pertenece a la instancia, de modo que una cuenta que no se haya migrado antes de que su servidor cierre no puede recuperarse en ningún otro sitio. El traslado de cuenta de Mastodon envía una actividad Move que transfiere a los seguidores a la nueva cuenta, pero la documentación es clara en que todo lo que publicaste se queda atrás, y el archivo que puedes descargar no se puede cargar en otra cuenta de Mastodon. Puntuado contra la prueba: la audiencia sobrevive a un traslado planificado, los datos sobreviven parcialmente como exportación, la identidad no sobrevive en absoluto.

AT Protocol: identidad portable, infraestructura concentrada

En el AT Protocol, la identidad de un usuario es un DID que ningún servidor posee, y sus publicaciones, seguimientos y perfil residen en un Personal Data Server (PDS) que puede trasladarse a otro host sin que el DID cambie. Por encima del PDS se sitúan los relays, que rastrean cada PDS y emiten un único firehose, y las AppViews, que indexan ese firehose en el producto que renderiza un cliente. La especificación es publicada y mantenida por Bluesky Social PBC.

La portabilidad tiene límites. La guía oficial de migración de cuentas trata estos pasos como algo que queda fuera del protocolo propiamente dicho y que puede cambiar más adelante, y te remite a la CLI goat o a una herramienta comunitaria en lugar de a un flujo dentro de la aplicación. Bryan Newbold, ingeniero de protocolo de Bluesky, escribió en octubre de 2025 que trasladar una cuenta ha funcionado en la red en producción desde principios de 2025, pero sigue siendo una tarea para desarrolladores, y que los PDS que opera Bluesky no aceptarán la entrada de una cuenta migrada.

La segunda salvedad es operativa. El Transparency Report 2025 de Bluesky indica que la compañía aloja más cuentas que nadie y es donde se registra la mayoría de la gente, con el resto de la red repartida entre miles de Personal Data Servers, operados en su mayoría por terceros. Ninguna cifra oficial cuantifica qué proporción de la red pasa por el relay y la AppView que opera Bluesky. Los críticos sostienen que los hosts de PDS independientes y los proyectos de infraestructura comunitaria siguen apoyándose en servicios centrales operados por Bluesky, y algunos concluyen que la red no está descentralizada en la práctica; eso es un juicio, no una medición. Puntuado contra la prueba: la identidad y los datos sobreviven a un cambio de proveedor por diseño, los seguidores te acompañan porque los registros de seguimiento referencian DIDs, y las capas por encima del PDS siguen siendo en su mayoría de una sola empresa.

Solid: pods de datos sin un mercado de consumo

Solid almacena los datos de un usuario en un Pod que este controla y exige que cada aplicación solicite acceso. Un WebID identifica a la persona, el Pod es un servidor HTTP que contiene recursos RDF, y las aplicaciones leen y escriben esos recursos una vez que las reglas de autorización lo permiten. En la prueba del cambio de proveedor, Solid tiene el diseño más limpio de los tres: la identidad, los datos y las reglas de acceso residen todos con el usuario, y una aplicación es simplemente un cliente.

La adopción no está a la altura del diseño. El Solid Protocol es un borrador de un W3C Community Group (v0.11.0, 12 de mayo de 2024), no un estándar del W3C, y el índice TR no muestra ninguna versión nueva publicada desde entonces; las versiones anteriores fueron la 0.9.0 (diciembre de 2021) y la 0.10.0 (diciembre de 2022), y el trabajo sobre la 0.12.0 permanece en el borrador del editor. Las especificaciones de extensión de las que dependen las aplicaciones —WebID Profile, Type Indexes y Application Interoperability— siguen siendo borradores, y la especificación permite dos sistemas de autorización incompatibles, WAC y ACP, con libertad para que los servidores implementen cualquiera de los dos. Las herramientas y la documentación van por detrás de los otros dos protocolos.

El obstáculo práctico es dónde registrarse. solidproject.org enumera alrededor de quince servicios de pods alojados, en su mayoría pequeños o experimentales, e Inrupt, la empresa cofundada por Tim Berners-Lee, comercializa ahora infraestructura de wallets empresariales para negocios. Noel De Martin, desarrollador de aplicaciones Solid, señaló en 2024 que la ausencia de un mercado de pods de consumo es el mayor freno para Solid: pedirle a alguien que inicie sesión con Solid lo obliga a buscar primero un proveedor, y ahí es donde la mayoría se detiene.

¿Cuántos usuarios tienen Bluesky y Mastodon?

El Transparency Report 2025 de Bluesky (29 de enero de 2026) contabilizó 41,41 millones de cuentas al cierre de 2025, frente a 25,94 millones, entre los PDS alojados por Bluesky y los independientes; la compañía monitoriza pero no publica una cifra de usuarios activos mensuales. El informe normaliza sus datos de moderación por cada 1.000 usuarios activos mensuales sin indicar el denominador.

Mastodon sí publica una cifra propia para toda la red, en la página de servidores de joinmastodon.org, y los rastreadores de terceros que consultan las APIs de estadísticas de las instancias publican las suyas. Las cifras no coinciden. TechCrunch informó en febrero de 2026 que el propio sitio de Mastodon daba unos 785.000 activos mensuales, mientras que los rastreadores oscilaban entre unos 750.000 y un millón según a cuál preguntaras. Esos rastreadores sitúan las cuentas registradas en torno a los 10 millones repartidos en unos 10.000 servidores, aunque los totales varían en un millón o más entre rastreadores, dependiendo de cómo trata cada uno a los servidores que han dejado de tener actividad.

En Mastodon, los registros y los activos difieren en un orden de magnitud, y la proporción de Bluesky es desconocida. Una comparación que enfrenta los registros de una red con los activos de otra está comparando magnitudes distintas.

¿Qué puedes construir sobre ActivityPub, Solid y Bluesky?

Los tres protocolos son HTTP puro, y por eso basta con una terminal para inspeccionarlos:

# ActivityPub: resolve a handle with WebFinger, then fetch the actor document
curl -s 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
curl -s -H 'Accept: application/activity+json' https://mastodon.social/users/Mastodon

# Solid: read an RDF resource from a pod as Turtle (replace with a real pod URL)
curl -s -H 'Accept: text/turtle' https://alice.example.org/profile/card

WebFinger es el RFC 7033 y una convención del ecosistema Mastodon, no forma parte de ActivityPub en sí. Los servidores Solid deben servir los recursos RDF como Turtle o JSON-LD cuando se les solicite.

El proyecto más accesible es un feed personalizado de Bluesky. Un feed personalizado de Bluesky es un servicio HTTP que devuelve una lista ordenada de URIs de publicaciones; la AppView recupera y renderiza esas publicaciones por sí misma, por lo que el servicio de feed nunca tiene que almacenar ni servir el contenido de las publicaciones. Se requieren dos rutas XRPC, y el léxico getFeedSkeleton define los parámetros (feed, limit hasta 100, cursor) y el error UnknownFeed:

// feedgen.mjs — run with: node feedgen.mjs
import { createServer } from 'node:http';

const SERVICE_DID = 'did:web:feeds.example.com';
const FEED_URI = 'at://did:plc:yourpublisherdid/app.bsky.feed.generator/weekend';

// A real generator fills this from a firehose consumer or a database.
const POSTS = [
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux6xlrdb42v',
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux7x2uvip2v',
];

const json = (res, status, body) => {
  res.writeHead(status, { 'content-type': 'application/json' });
  res.end(JSON.stringify(body));
};

createServer((req, res) => {
  const { pathname, searchParams } = new URL(req.url, 'http://localhost');

  if (pathname === '/xrpc/app.bsky.feed.describeFeedGenerator') {
    return json(res, 200, { did: SERVICE_DID, feeds: [{ uri: FEED_URI }] });
  }

  if (pathname === '/xrpc/app.bsky.feed.getFeedSkeleton') {
    if (searchParams.get('feed') !== FEED_URI) {
      return json(res, 400, { error: 'UnknownFeed', message: 'Feed not found' });
    }
    // Requests may carry a JWT signed by the user's key. A feed that is
    // identical for every user can ignore it, as this one does.
    const limit = Math.min(Number(searchParams.get('limit') ?? 50), 100);
    const start = Number(searchParams.get('cursor') ?? 0);
    const page = POSTS.slice(start, start + limit);
    const cursor = start + limit < POSTS.length ? String(start + limit) : undefined;
    return json(res, 200, { feed: page.map((post) => ({ post })), cursor });
  }

  json(res, 404, { error: 'NotFound' });
}).listen(3000);

El cursor es opaco para la AppView y enteramente tuyo; un índice de posición basta para una lista fija, y el tutorial oficial recomienda un cursor compuesto de timestamp más CID una vez que las publicaciones provienen de un índice en vivo. Para pasar a producción, despliega sobre HTTPS, publica un documento DID que apunte al host (el starter kit lo configura como un did:web por defecto) y ejecuta su script publishFeedGen.ts para crear el registro app.bsky.feed.generator en tu propio repositorio. A partir de ahí, el feed aparece en la aplicación de Bluesky como cualquier otro.

Situación actual

Medidos contra la prueba del cambio de proveedor, ActivityPub traslada los seguidores pero no la identidad, el AT Protocol traslada las tres cosas sobre el papel mientras la mayor parte de la red sigue pasando por el relay y la AppView de una sola empresa, y Solid lo traslada todo en principio, sin un mercado de consumo que lo lleve a la práctica. Elige el protocolo cuyo modo de fallo puedas asumir y luego dedica un fin de semana al generador de feeds anterior: es el camino más corto entre leer sobre la web descentralizada y operar una parte de ella.

Preguntas frecuentes

¿Pueden seguirse mutuamente los usuarios de Bluesky y de Mastodon?

No de forma nativa: ActivityPub y el AT Protocol no interoperan, así que los seguimientos entre redes pasan por un puente. Bridgy Fed, gestionado por la organización sin ánimo de lucro A New Social, es opt-in: un usuario de Bluesky sigue a @ap.brid.gy, y un usuario del fediverso sigue a @bsky.brid.gy@bsky.brid.gy. Las cuentas puenteadas aparecen como user.instance.ap.brid.gy en Bluesky y como handle@bsky.brid.gy en el fediverso. Solo se puentean las publicaciones totalmente públicas, y las publicaciones del fediverso de más de 300 caracteres se truncan en Bluesky.

¿Cuál es la diferencia entre did:plc y did:web en el AT Protocol?

El AT Protocol admite únicamente dos métodos DID. did:plc, desarrollado por Bluesky Social PBC, registra los identificadores en el directorio PLC, admite rotación y recuperación de claves, y es lo que el instalador oficial del PDS crea para las cuentas nuevas. did:web deriva el identificador de un nombre de host que tú controlas, solo permite identificadores a nivel de nombre de host sin rutas, y no ofrece recuperación si pierdes el dominio, por lo que resulta adecuado para servicios como los generadores de feeds.

¿Puedo usar mi propio dominio como handle de Bluesky sin alojar un PDS?

Sí. Un handle es un nombre de host DNS vinculado bidireccionalmente a tu DID, y ese vínculo es independiente de qué PDS almacena tus datos. Publica el DID en uno de estos dos lugares: un registro DNS TXT llamado _atproto.tudominio con el valor did= seguido de tu DID completo, o una respuesta en texto plano en https://tudominio/.well-known/atproto-did. La especificación recomienda el método DNS para particulares; el método HTTPS está orientado a servicios grandes.

Si alojo yo mismo un Personal Data Server, ¿puedo seguir usando la aplicación de Bluesky?

Sí. El PDS oficial se distribuye como una imagen Docker para un VPS con una dirección IPv4 pública, un registro DNS wildcard y los puertos 80 y 443 abiertos; Bluesky recomienda 1 GB de RAM y 20 GB de almacenamiento para entre 1 y 20 usuarios. Inicia sesión introduciendo la URL de tu PDS en la aplicación. La configuración por defecto apunta a la AppView, el relay y el directorio PLC de Bluesky, por lo que el PDS sigue dependiendo de servicios operados por Bluesky por encima de la capa de datos.