¿Por qué Bluesky no es una red peer-to-peer?

Artículo original ↗ Discusión en Hacker News ↗

La arquitectura de Bluesky, que se apoya en servidores de datos personales y nodos “relay” centralizados en lugar de una red peer-to-peer completa, se examina por cómo equilibra descentralización, capacidad de búsqueda y despliegue práctico a escala. Los comentaristas la comparan con ActivityPub/Mastodon y Nostr, debatiendo modelos de identidad (dominios frente a claves públicas), moderación y resistencia a la censura, el coste y la fragilidad del autohospedaje, y los retos de incorporación de usuarios como elegir un servidor. Otros cuestionan si alguno de estos diseños técnicos importa para la adopción masiva, argumentando que los efectos de red, el posicionamiento del producto y la calidad del contenido determinarán en última instancia si Bluesky puede reemplazar de forma significativa a plataformas estilo Twitter.

Arquitectura P2P vs Federada vs Centralizada

  • Varios comentaristas señalan que el modelo de Bluesky se parece menos a un P2P puro y más a la web o a GitHub: servidores de “datos personales” de los usuarios más una infraestructura mayor para la agregación.
  • Los críticos argumentan que los relays de Bluesky/los “big graph servers” crean puntos inevitables de control central; los defensores dicen que los relays son “buses” enchufables y que los PDS pueden conectarse a muchos relays o directamente, por lo que la autoridad no es fija.
  • Algunos sugieren que un P2P real con publicaciones autenticadas y borrado eventual es posible, pero en la práctica es difícil de hacer cumplir.

Descubrimiento, búsqueda y escala

  • Una postura sostiene que los grandes servicios de indexación/búsqueda no son estrictamente necesarios; los grafos sociales, las etiquetas y las vistas de “amigos de amigos” pueden ofrecer descubrimiento a escala humana.
  • Otros insisten en que la búsqueda global (por hashtag/tema, entre millones de usuarios) es esencial para muchos casos de uso reales y requiere inevitablemente mucho almacenamiento e indexación centralizada.
  • La replicación completa al estilo del fediverso se critica por ser costosa para el medio ambiente y técnicamente cara a escala global.

Comparaciones con ActivityPub / Mastodon / Nostr

  • ActivityPub se considera viable pero defectuoso en la práctica: mala migración de cuentas, múltiples identidades por tipo de app, ausencia de un modo cliente-a-servidor ampliamente usado y sin un fácil “trae tu propio dominio” en las implementaciones principales.
  • Ecosistema de Mastodon: hay muchos nodos, pero unos pocos grandes dominan por los costes, la comodidad y la gravedad social. Las instancias pequeñas/autohospedadas pueden sentirse aisladas porque solo ven los datos que han recuperado explícitamente.
  • Nostr es elogiado por su especificación central simple, pero criticado por la identidad basada en claves privadas, que muchos ven como inutilizable para usuarios mainstream y culturalmente ligada a comunidades de “crypto”.

Identidad: dominios vs claves públicas

  • La identidad basada en DNS de Bluesky (handles como hostnames, a menudo en dominio propio) es ampliamente apreciada; hay debate sobre redirecciones simples HTTP o CNAME desde dominios personales a perfiles.
  • A algunos les preocupa que los dominios son escasos, expiran y centralizan el control en registros y registradores; abogan por identidades con claves públicas como anclas duraderas e independientes de la ubicación del almacenamiento.
  • Otros responden que las claves son ilegibles, difíciles de teclear y no significan nada para usuarios normales; ningún esquema único satisface por completo la memorabilidad, la descentralización y la seguridad.

Moderación, poder y objetivos

  • Narrativas contrapuestas: Bluesky como respuesta a prohibiciones de alto perfil frente a Bluesky como intento de hacer a los proveedores “reemplazables” y reducir la captura de la plataforma, no de eliminar la moderación.
  • Hay tensión entre querer sistemas resistentes a la censura y reconocer que cualquier infraestructura financiada por anuncios o centralizada tiende a acumular poder de moderación.

Posicionamiento del producto y experiencia de usuario

  • Algunos ven Bluesky como “Twitter más lento” con una diferenciación poco clara y búsqueda débil; otros valoran precisamente esa sensación más lenta, menos algorítmica y con menor toxicidad.
  • Una crítica clave es que los desarrolladores se centran en minucias del protocolo mientras descuidan el posicionamiento de mercado y los modelos de negocio a largo plazo.
  • Descubrir contenido de calidad sigue siendo un problema: sin un grafo social fuerte ni algoritmos, a los nuevos usuarios les cuesta encontrar feeds que valgan la pena.

Obstáculos técnicos para un P2P verdadero

  • Más allá de NAT/firewalls, los comentaristas destacan los límites de batería y ancho de banda de los teléfonos: los enlaces permanentes entre pares requieren keepalives frecuentes, que son costosos.
  • Los marcos existentes para atravesar NAT (ICE/WebRTC, redes superpuestas) ayudan, pero añaden complejidad; no existe un “equivalente P2P de TCP/IP” disponible universalmente.
  • Algunos sostienen que gran parte de la complejidad arquitectónica de Bluesky está impulsada por la necesidad de sortear estas restricciones de despliegue del mundo real.