Comparación entre Bluesky y el fediverso

Diferencias clave de arquitectura: entrega de mensajes vs. montón compartido

• Fediverso: usa un modelo de “entrega de mensajes”, similar al correo electrónico

  • Los mensajes se entregan directamente a destinatarios específicos
  • Los mensajes solo se envían a los servidores necesarios, lo que lo hace eficiente
  • Una persona puede operar un nodo incluso con hardware económico

• Bluesky: usa un modelo de “montón compartido”

  • Todos los mensajes se almacenan en un “relay” central
  • Los usuarios filtran la información relevante desde el relay
  • Requiere una infraestructura centralizada a gran escala
  • El costo de operar el relay aumenta rápidamente (de 1 TB a 5 TB en solo 4 meses)

Problema de la vista global y la centralización

• Bluesky: se enfoca en mantener una vista coherente de toda la red

  • Todas las app views necesitan información global, como los bloqueos completos
  • Las listas de bloqueo son públicas, lo que genera problemas de privacidad
  • Es difícil de implementar sin control centralizado

• Fediverso: cada servidor aplica sus propias políticas de forma independiente

  • Ofrece más autonomía a los usuarios
  • Está diseñado para que la información de bloqueo no sea pública

Comparación de apertura del protocolo

• Fediverso/ActivityPub: estándar abierto adoptado por la W3C

  • Cualquiera puede implementarlo libremente
  • Garantiza interoperabilidad entre distintos programas
  • Evoluciona de forma comunitaria a través de los FEP

• Bluesky/AT Protocol: protocolo impulsado por una empresa

  • Aún no tiene una posición consolidada como estándar abierto
  • Tiene limitaciones en escalabilidad y sostenibilidad

La centralización de los mensajes directos (DM)

• Bluesky: todos los DM pasan por un servidor central

  • Se envían a través de la empresa Bluesky, sin importar el PDS del usuario o el relay
  • La empresa Bluesky puede acceder a todos los DM
  • Esto contradice la idea de una “salida confiable”

• Fediverso: mecanismo de entrega directa entre servidores

  • Solo el administrador de tu propio servidor puede acceder a los mensajes

Problemas en la implementación de identidades portables

• Bluesky: usa DID, pero sigue dependiendo de la centralización

  • did:web y did:plc dependen de DNS y de un registro central
  • Al inicio, todas las cuentas usaban las mismas rotationKeys
  • Las claves de los usuarios son administradas por Bluesky

• Fediverso: el concepto de identidad nómada sigue evolucionando

  • Protocolos como Zot ofrecen una portabilidad más amplia
  • Sigue mejorando de forma continua mediante propuestas como FEP-ef61

Presión comercial y sostenibilidad

• Bluesky: depende de financiamiento de capital de riesgo

  • Existe la percepción de que “la organización es el enemigo del futuro”
  • Hay presión comercial por la introducción de cuentas pagadas y publicidad
  • La presión por generar retornos para inversionistas podría obstaculizar la descentralización

• Fediverso: diversidad de operadores y modelos de financiamiento

  • Está conformado por un ecosistema de nodos comerciales, no comerciales y personales
  • No tiene un único punto de falla

Conclusión

• Bluesky puede ser una excelente alternativa a X por su interfaz amigable y una experiencia similar a Twitter
• Sin embargo, no es una alternativa al fediverso debido a su diseño centralizado, costos operativos, vulnerabilidades de privacidad y dependencia corporativa
• Ambos sistemas tienen objetivos y filosofías de diseño fundamentalmente distintos, e idealmente podrían evolucionar de forma complementaria

[hongminhee]

También está esta réplica: https://hackers.pub/@yurume/0195cc17-b1ed-712e-9ecf-dcc49158220a