Bluesky registra ATProto como marca registrada
La adquisición por parte de Bluesky de la marca registrada “AT Protocol”, supuestamente para impedir que otra empresa restringiera el uso comunitario, ha renovado el escrutinio sobre cuán descentralizado es realmente el ecosistema de AT Protocol. Los comentaristas debaten si el control de Bluesky sobre componentes clave como el directorio de identidades PLC, los principales relays y la app cliente dominante deja la red efectivamente centralizada, pese al diseño del protocolo para alojamiento y apps independientes. Otros señalan implementaciones alternativas, el trabajo en curso de estandarización en IETF y la infraestructura de terceros como evidencia de que el ecosistema puede evolucionar más allá de un único custodio corporativo, siempre que mejoren la gobernanza y las herramientas de migración.
Origen y propósito de la marca registrada
- Otra empresa (Atsign, Inc.) había solicitado “ATPROTOCOL” y, según se informó, amenazaba con emprender acciones legales por el uso que otros hacían del término.
- Bluesky adquirió la marca para impedir que esa entidad restringiera el uso por parte de la comunidad y ahora la concede bajo licencia a otros proyectos.
- Algunos ven esto como una medida defensiva pragmática; otros se preocupan por el control a largo plazo, aunque hay indicios de que más adelante podría transferirse a una organización neutral.
Gobernanza, PLC e independencia
- ATProto se está estandarizando mediante un grupo de trabajo de IETF; al principio algunos no estaban seguros de si IETF o los WGs pueden poseer marcas registradas.
- Bluesky es una public benefit corporation, pero los comentaristas señalan que eso no garantiza decisiones centradas en el usuario.
- El directorio de identidades PLC sigue viéndose como un punto central de control; la transferencia a una organización de gobernanza separada se considera ya tardía.
- Existe preocupación de que las sanciones de EE. UU. o presiones similares puedan llevar a una desactivación a nivel de identidad.
“Instancias”, topología y centralización
- Un hilo importante debate si es preciso decir que Bluesky opera la “única instancia viable”.
- Postura pro-ATProto: no hay “instancias” en el sentido de Mastodon; el alojamiento (PDS), la indexación/relays y las apps están desacoplados; cualquiera puede ejecutar cada pieza, y ya existen varias pilas independientes.
- Críticos: en la práctica, la mayor parte de los datos y del tráfico siguen pasando por la infraestructura de Bluesky, por lo que la centralización efectiva sigue siendo alta.
Autoalojamiento, DIDs y migración
- Los usuarios pueden autoalojar PDS y usar
did:webpara evitar PLC, pero los DIDs son inmutables: no puedes migrar dedid:plcadid:websin perder tu grafo. - Esto se ve como una limitación importante para quienes empezaron con la configuración predeterminada de Bluesky.
- Las herramientas GUI para migración de PDS han mejorado, pero la migración de DID sigue sin resolverse.
Wsocial y limitación de tasa
- El problemático lanzamiento de Wsocial se cita como evidencia de control central: su tráfico alcanzó los límites de tasa del relay y, en la práctica, no pudieron participar sin coordinación.
- Otros responden que la limitación de tasa y la coordinación con el operador son normales en sistemas federados (comparándolo con Mastodon y el correo electrónico) y que existen otros relays e índices.
Comparaciones con ActivityPub y Nostr
- Algunos sostienen que ActivityPub/Nostr son más claramente descentralizados y más fáciles/baratos de desplegar.
- Los partidarios de ATProto responden que ATProto apunta a un conjunto de problemas distinto (escala alta, capa de datos compartida, portabilidad de apps), más parecido a “RSS tipado”, y que ya funcionan sobre la pila varias apps y servicios que no son de Bluesky.
Confusión histórica con “AT protocol”
- Un subhilo menciona el antiguo conjunto de comandos “AT” de los módems, a veces llamado informalmente “AT protocol”, pero la mayoría coincide en que esto no afecta en la práctica a la marca registrada.