El experto en estándares web Robin Berjon plantea en su blog una provocación de diseño: ejecutar el protocolo de redes sociales federadas ActivityPub sobre la infraestructura del AT Protocol (ATProto), el conjunto de herramientas sobre el que opera Bluesky. El texto parte de la rivalidad tribal entre las comunidades de ambos ecosistemas para defender que ambos pueden combinarse con un esfuerzo moderado.
Berjon distingue ATProto de Bluesky: el primero es una caja de herramientas genérica para construir aplicaciones sociales y servir de base a un Servidor de Datos Personal (PDS), mientras que la aplicación concreta de Bluesky (app.bsky) es propietaria y los endpoints com.atproto están concebidos como estándar abierto. Entre sus propiedades destaca el uso de identidad enchufable, que no depende del servidor, y repositorios de datos firmados, lo que otorga a los usuarios una salida creíble de la plataforma. La federación al estilo email, modelo subyacente de ActivityPub, es más susceptible de captura, como demuestra que aproximadamente el 85% del correo electrónico esté en Gmail.
La propuesta concreta consiste en reutilizar el documento de Actor de ActivityPub como capa de indirección que apunte a las rutas xrpc del PDS en ATProto. Berjon identifica dos obstáculos técnicos: que los XRPC no admiten métodos sobrecargados (el inbox de ActivityPub requiere GET y POST) y un desajuste entre los sistemas de identidad y handle. Ambos considera subsanables con ajustes menores en lexicons o en el documento de actor, por lo que concluye que la integración es más factible de lo que sugieren los debates en línea y merece exploración seria.