No hay instancias en ATProto

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

Arquitectura de red y “no hay instancias”

  • ATProto separa los roles en Personal Data Servers (PDS), AppViews y Relays opcionales; el alojamiento y las aplicaciones están desacoplados.
  • Los Relays se describen como una optimización de rendimiento, no como una pieza fundamental: retransmiten eventos desde muchos PDS hacia muchas AppViews.
  • Algunos comentaristas sostienen que esto es semántico: PDS, AppViews y Relays siguen actuando como “instancias” en la práctica, solo que agrupadas de otra manera.
  • Las analogías con RSS/Google Reader ayudan a algunos lectores; otros las consideran engañosas porque las apps de ATProto son agregadores del lado del servidor con un fuerte control sobre lo que ven los usuarios.

Comparación con ActivityPub / Mastodon

  • Las instancias de ActivityPub/Mastodon agrupan identidad, alojamiento, interfaz y moderación, lo que:
    • Hace tangible la descentralización (miles de servidores, usuarios repartidos).
    • Pero te ata a una instancia y hace más difíciles la migración y la escalabilidad.
  • ATProto aspira a:
    • Identidad estable mediante DIDs y migración más সহজ entre hosts y apps.
    • Un modelo de datos compartido y tipado para que muchas apps puedan reutilizar y recombinar el mismo contenido.
  • Los críticos responden que, hoy, el ecosistema de ATProto está efectivamente dominado por un solo proveedor (Bluesky) de una forma en que Mastodon no lo está.

Moderación, censura y gobernanza

  • La moderación en ATProto ocurre en múltiples capas: alojamiento, AppViews, relays, además de servicios “labeler” estandarizados que las apps pueden elegir usar.
  • Ejemplo dado: un usuario baneado en la app principal de Bluesky sigue siendo visible a través de otra AppView que rechaza las decisiones de moderación de Bluesky.
  • Los escépticos señalan:
    • Si la mayoría de los usuarios se queda en la AppView principal de Bluesky, ser baneado allí sigue silenciando en la práctica.
    • Hoy solo existe un directorio PLC; la gobernanza se está trasladando a una entidad suiza y a IETF, pero el riesgo de centralización sigue ahí.
    • Algunos ven ATProto como “decentr-washing” hasta que existan muchas AppViews independientes y ampliamente usadas.

Costes, autoalojamiento y escalabilidad

  • Los PDS son baratos y pueden ejecutarse en pequeños VPS o incluso en hardware de la clase Raspberry Pi.
  • Los relays que reflejan toda la red actualmente se dice que funcionan por unos ~$20–30/mes; las AppViews solo son “caras” si intentas replicar el índice global de Bluesky.
  • Los defensores dicen que esto es asequible para desarrolladores aficionados y permite un mercado de infra compartida; los críticos argumentan que:
    • $30/mes y el esfuerzo operativo no son triviales en muchas regiones.
    • En la práctica, solo existen unos pocos relays y AppViews, manteniendo el poder concentrado.

Experiencia de usuario, cultura y adopción

  • Las voces pro-ATProto destacan:
    • Una mejor vía de UX para usuarios no técnicos que el onboarding de Fedi de “elige una instancia”.
    • La capacidad de reutilizar una identidad en apps muy distintas (microblogging, blogs, alojamiento de código, etc.).
  • Las voces pro-ActivityPub destacan:
    • Descentralización probada y operativa, con muchos servidores independientes y modelos de financiación.
    • Resiliencia cultural: si un gran servidor de Mastodon cae, la red en su mayor parte sigue funcionando.
  • Preguntas abiertas planteadas:
    • Si ATProto seguirá dominado por Bluesky o evolucionará hacia un ecosistema genuinamente multiproveedor.
    • Si la portabilidad técnica se traducirá en una independencia cultural y económica real respecto a la empresa fundadora.