Cómo funciona Bluesky

• BlueSky es una app de microblogging similar a Twitter y Mastodon, pero su objetivo mayor es comprobar si es posible tener aplicaciones sociales distribuidas a gran escala sobre AT Protocol (atproto)
• atproto no es blockchain, DAO ni NFT, sino un protocolo federado que usa criptografía y Merkle tree, entre otras cosas, para que los registros firmados por usuarios se repartan entre PDS, Relay y App View
• Su escalabilidad viene de una estructura en la que el Personal Data Server (PDS) del usuario no envía directamente las publicaciones a todos sus seguidores, sino que Relay reúne los datos de la red y los ofrece como firehose
• La moderación se divide bajo el modelo de “speech vs reach”, separando la réplica del contenido y el control de exposición, para que labeler, feed generator y App View apliquen filtros y bloqueos
• Los DID estables y los handles basados en dominios dan portabilidad de cuenta, pero el servicio de resolución did:plc operado por BlueSky sigue siendo un punto de debate sobre centralización

---

La relación entre BlueSky y atproto

• BlueSky hoy funciona como una aplicación de microblogging, pero dentro de la visión general es una primera aplicación para demostrar el potencial del Authenticated Transfer Protocol, es decir, atproto
• El sitio web de BlueSky dice que “las redes sociales son demasiado importantes para que las controlen unas cuantas empresas, y estamos construyendo una base abierta para una internet social donde todos puedan construir el futuro”
• Como BlueSky es una empresa, puede haber una mirada escéptica del tipo “una empresa está construyendo algo que no debería controlar una empresa”, pero el núcleo del diseño está en atproto más que en la app
• atproto es un protocolo federado para aplicaciones sociales distribuidas a gran escala

Un protocolo distribuido, no una criptomoneda

• atproto puede parecer algo parecido a las criptomonedas por expresiones como “red distribuida” y “protocolo”, pero no es una criptomoneda
• No es blockchain, DAO ni NFT, aunque sí usa algunas técnicas como criptografía y Merkle tree

Estructura básica de atproto

• atproto adopta una estructura federada donde múltiples actores operan distintas partes del sistema y se comunican entre sí
• Está diseñado pensando en una base de usuarios masiva: asigna más funciones a quienes pueden soportar la carga y reduce la carga para quienes no
• BlueSky superó los 5 millones de usuarios esa semana, al momento de escribir el texto, y se considera mucho más estable que el Twitter inicial
• Actualmente atproto se basa en un modelo 100% público y no tiene funciones como mensajes privados
  • Como es difícil implementar bien funciones privadas en un sistema federado, se prefirió hacerlo bien antes que lanzar algo con limitaciones graves
  • Por ahora, conviene usarlo solo para contenido que pueda ser público

Registros, repositorios, App View y Relay

• El usuario crea un record firmado criptográficamente, y esa firma demuestra quién es el autor
• El record sigue un esquema llamado Lexicon
• El record se guarda en un repository, que funciona como un servicio que expone HTTP y WebSocket
  • A este tipo de servicio normalmente se le llama PDS (Personal Data Server)
  • El usuario puede operar su propio PDS o usar uno hospedado por otra persona
• Las aplicaciones leen los record almacenados en la red y construyen funciones sobre ellos
  • Como estos servicios exponen una perspectiva particular de la información, se llaman App View
  • Crear una aplicación consiste en definir un Lexicon, leer los record que usan ese Lexicon e ignorar el resto
• Que los PDS se avisen directamente entre sí presenta grandes problemas de escalabilidad
  • Si cada vez que se publica algo hubiera que enviarlo directamente al repository de cada seguidor, sería ineficiente y el costo de operar repositories populares sería alto
• Relay reduce ese problema reuniendo la información de la red y exponiéndola como firehose
  • En la práctica, App View mira Relay en lugar de mirar directamente los repository
  • Cuando alguien publica, el repository avisa a Relay, y los seguidores ven el resultado de que App View filtre la salida de Relay
  • Relay puede ser grande y costoso de operar, pero también se pueden imaginar Relay más pequeños que propaguen solo un subconjunto específico de usuarios

El modelo de moderación “speech vs reach”

• Como atproto es un protocolo para aplicaciones sociales, no solo piensa en cómo conectar personas, sino también en cómo desconectarlas
• El modelo de moderación de BlueSky se divide en speech vs reach
  • La capa de speech se encarga de replicar contenido en la red sin importar su significado
  • La capa de reach da herramientas para limitar hasta dónde llega lo que el usuario no quiere ver
• Decir que BlueSky “no modera” o que “solo prioriza la libertad de expresión” no es exacto
  • Las herramientas de moderación están integradas en el propio protocolo y pueden funcionar también sobre contenido de aplicaciones distintas de BlueSky
  • El usuario puede elegir a sus propios moderadores, sin quedar sujeto a la elección —o a la falta de ella— de otras personas

Feed generator

• En atproto, el feed se separa como un servicio independiente llamado feed generator
• El feed generator recibe el firehose producido por Relay y filtra y ordena el contenido según los criterios que quiera para mostrar una lista
• El usuario puede compartir con otros usuarios los feeds que haya creado
• Ejemplos de feeds:
  • Quiet Posters: muestra publicaciones de personas que no escriben con frecuencia
  • the ‘Gram: muestra solo publicaciones con fotos adjuntas
  • My Bangers: muestra tus publicaciones populares
• Una de las fortalezas de BlueSky es que el usuario puede crear fácilmente sus propios feeds algorítmicos y compartirlos
• Los feed son una función añadida hace relativamente poco a atproto, así que puede que todavía no estén completos y podrían cambiar en el futuro

Labeler y moderación a nivel de red

• Labeler es un servicio que pone labels a contenido o cuentas
• El usuario puede suscribirse a un labeler específico y hacer que su experiencia cambie según los labels de las publicaciones
• El labeler puede funcionar como quiera su operador
  • Puede ejecutar algoritmos automáticos sobre publicaciones
  • Puede tener aprobación o rechazo manual por parte de personas
  • Puede usarse como blocklist o como filtro NSFW
• La función de label existe, pero al momento de escribir no está claro si los usuarios pueden ejecutar directamente su propio labeler
  • BlueSky opera su propio labeler
  • Todavía no se conoce una liberación externa
• Al combinar feed, App View y labeler, el usuario puede elegir su experiencia de moderación dentro y fuera de una aplicación
  • En un feed puede ver solo SFW y en otro permitir contenido NSFW
  • Puede crear y compartir blocklists
• Como las herramientas de moderación funcionan a nivel de protocolo y no de aplicación, se puede usar el mismo labeler en otras aplicaciones construidas sobre atproto
  • Si alguien crea un clon de Instagram sobre atproto, podría usar el mismo labeler de blocklists
  • Si quieres, un usuario bloqueado en un lugar puede quedar bloqueado en todos

Diferencia frente al modelo de instancias de Mastodon

• El modelo de atproto es distinto de tener una “cuenta” dentro de una “instancia” específica como en Mastodon
• Preguntas como “¿qué pasa si mi instancia se defederata?” no se aplican tan directamente
• Se puede lograr algo parecido ignorando publicaciones provenientes de un PDS específico
• Pero esa elección no la toma el dueño del servidor en nombre del usuario, sino que es una decisión del propio usuario

DID, handle y portabilidad de cuenta

• El núcleo de identidad en atproto es el DID (Decentralized Identifier)
  • Un DID de ejemplo tiene la forma did:plc:3danwc67lo7obz2fmdg6jxcr
• La identidad que el usuario ve en la práctica también usa un handle, y ese handle es un nombre de dominio
  • Por ejemplo: @steveklabnik.com
  • Quienes se registran en BlueSky pueden recibir un handle con la forma @username.bsky.social
• Como el DID es estable, aunque cambies el handle de @steveklabnik.bsky.social a @steveklabnik.com, no se interrumpe nada para tus seguidores y en la interfaz solo cambia el handle
• Para usar un dominio como handle, el PDS genera el DID y luego se agrega un TXT record al DNS de ese dominio
• Incluso quien no sabe de DNS puede registrar un dominio y configurarlo como handle mediante la alianza entre BlueSky y NameCheap, sin conocimientos técnicos
• La portabilidad de cuenta se basa en DID y firmas criptográficas
  • El contenido creado por quien usa un DID específico va firmado y se replica por la red
  • Para “cerrar” una cuenta, habría que impedir a la fuerza el uso de la clave que posee el usuario, pero por diseño ningún otro actor de la red accede a esa clave
  • Aunque un PDS se caiga, se puede hacer backfill del contenido desde la red y avisar que se migró a un nuevo PDS

Los puntos en debate de did:web y did:plc

• BlueSky soporta dos mecanismos de DID
  • did:web: mecanismo basado en nombres de dominio
  • did:plc: mecanismo propio implementado por BlueSky
• El plc de did:plc significa “placeholder”, y BlueSky planea seguir dándole soporte
• did:plc tiene la debilidad de que la información correcta debe resolverse mediante un servicio operado por BlueSky
  • Un ejemplo de consulta puede verse en plc.directory
  • Por esta estructura, existe la crítica de que BlueSky podría banear usuarios con más fuerza de la que el diseño de la red originalmente permitiría
• También hay razones para no ver esto como algo fatal
  • Si no quieres, puedes usar did:web
  • Está diseñado para que puedas migrar si aparece un sistema mejor
  • En el futuro, la gobernanza de did:plc podría moverse a un modelo de consenso
  • Otros actores también podrían operar un servicio did:plc y usarlo

Cómo se monta BlueSky sobre atproto

• BlueSky es una aplicación construida sobre la red atproto
• BlueSky opera un App View y la aplicación web que lo usa
• También opera PDS para usuarios registrados desde la webapp, además de los Relay con los que se comunican esos PDS
• BlueSky publica dos tipos de Lexicon
  • com.atproto.*: operaciones de bajo nivel necesarias para cualquier aplicación en la red
  • app.bsky.*: operaciones específicas de BlueSky
• El objetivo del producto BlueSky es que el usuario pueda usarlo sin conocer todos estos detalles técnicos
  • Como no hay instancias, no existe un flujo de elegir una instancia para crear una cuenta
  • Si el host se cae, puedes migrar, y tus seguidores ni siquiera tienen que notarlo

Crear una nueva aplicación sobre atproto

• Una aplicación de atproto empieza por crear un Lexicon
• Después opera un App View que procesa, dentro de los datos de la red, aquellos relacionados con ese Lexicon
• La aplicación debe permitir que el usuario escriba datos en su PDS usando ese Lexicon

La separación clave del diseño

• La separación de roles entre atproto y BlueSky es un elemento importante del diseño
• Una “killer app” como BlueSky da una razón para usar la red
• BlueSky también cumple una función de dogfooding, al validar si de verdad se pueden construir aplicaciones reales sobre atproto

[GN⁺]

Comentarios de Hacker News

• Parece estar muy bien diseñado y da la impresión de resolver algunos de los grandes problemas de ActivityPub
  Antes no me interesaba Bluesky, pero ahora me dan ganas de crearme una cuenta

  • El principal problema de Bluesky y del AT Protocol no está tanto en sus ventajas técnicas, sino en una fuerte actitud de NIH (Not invented here)
    En lugar de usar protocolos existentes como user@host y WebFinger, que todo el mundo usa, optaron por “usar dominios como identidad”, y como no tomaron como referencia la forma en que ACME ya resuelve esto con certificados, terminó ocurriendo que alguien se apropió del dominio s3.amazon.com en Bluesky https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
    También crearon un nuevo protocolo de llamadas remotas, XRPC, y usan Lexicon, un esquema de datos basado en generación de código cuya ventaja no está clara más allá de ser más nuevo que protobuf o jsonld
    Cuesta confiar en una “red abierta” que sigue mostrando una actitud de no querer respetar ni dialogar con otros ecosistemas, y además hace pensar cuántos errores de diseño comunes habrán terminado incluyendo por rechazar conocimiento compartido
  • El AT Protocol parece técnicamente mejor, pero socialmente da la impresión de ser una estructura propensa al fracaso
    No hay un incentivo social claro para que alguien instale y mantenga relays y servicios de moderación separados de comunidades reales, así que al final los únicos incentivos que quedan son los monetarios: servicios de pago, inserción de anuncios, extracción de datos y manipulación de información
    Si la distribución de datos y la moderación se centralizan, tanto el costo de hosting como el costo humano se vuelven un negocio grande, y eso termina yendo en una dirección que en la práctica dificulta que alguien que no sea Bluesky opere su propio relay o servicio de moderación
    A pesar de las desventajas de ActivityPub, enfoques como las “comunidades con puerta de entrada” hacen que el usuario sienta pertenencia a su servidor, y que administradores y moderadores sientan orgullo de brindar un servicio a sus usuarios
    El AT Protocol permite técnicamente varios relays y servicios de moderación, pero queda la duda de cuántos surgirán en la práctica
    Creo que es un error juzgar un protocolo de red social solo desde una perspectiva técnica y adversarial. A cambio de no depender de un servidor, también se separa de comunidades más estrechas, y deja de haber algo en juego
    No tener nada que perder en términos de datos, identidad y comunidad es una espada de doble filo

• Entiendo que por ahora solo hay un relay
  Si aparecen varios relays, cada uno verá la red de forma distinta, y el relay que incluya más publicaciones terminará siendo el mejor relay
  Conseguir diversidad de relays en vez de un solo relay dominante podría ser bastante difícil, y se parece a cuando un sistema DNS alternativo intenta ganar traction. Entonces, si mis publicaciones no quedan registradas por el relay dominante, parecería que no hay mucho que hacer
  Aún está muy verde, así que quizá no termine siendo así, y aunque exista un relay dominante, GitHub tampoco es tan malo y sí hay alternativas

  • Antes Bluesky me parecía bastante confuso, pero hace poco me di cuenta de que la confusión venía sobre todo por la terminología
    Si al sistema lo llamaran [microblog] -> [indexador] -> [cliente], sería mucho más fácil de entender
    En realidad hay más componentes, pero el funcionamiento básico de Bluesky es más o menos ese, y parece que solo le pusieron nombres distintos a lo que uno esperaría
    La razón por la que hace falta un indexador es que el ID de usuario no se mantiene estático dentro del sistema. DID:PLC empieza como una subcadena del hash, pero luego ocurre una extraña reorganización criptográfica por la “rotación de claves”, y con el tiempo el ID del usuario cambia sin que la propia persona lo note
    Piensa en un sistema como LiveJournal, pero donde los handles cambian todo el tiempo y hace falta una autoridad que rastree esos cambios. Eso sí, solo se pueden publicar mensajes cortos, sin títulos ni soporte para Markdown
    Personalmente, estoy esperando un nuevo DID:PLC que entregue una clave pública estática y firme los mensajes con la clave privada. Habría mucho menos que rastrear, y el self-hosting y el desarrollo local-first serían bastante más sencillos
  • Si hiciera falta, creo que App View, que es el cliente, podría usar varios relays en paralelo
    Sería como una interfaz local de GitHub que obtiene datos de varias instancias de GitHub, cada una alojando conjuntos de repositorios distintos, aunque a veces superpuestos
    También se parece a un cliente de Usenet que reúne grupos de noticias desde varios servidores NNTP
  • Espero que todos los relays tengan todos los datos, salvo diferencias de criterio sobre contenido ilegal
    Me da curiosidad por qué piensas que cada relay terminaría viendo la red de forma distinta

• Lo que me intriga es cómo BlueSky puede prometer de forma creíble que solo usará las partes abiertas del protocolo
  BlueSky en la práctica se ve bastante centralizado, así que no parece haber una razón técnica por la cual un cliente first-party tenga que ser necesariamente un cliente de ATProto
  A corto o mediano plazo, hacer eso sería una gran traición a la confianza de los usuarios, pero la estructura de facto distribuida de ActivityPub aquí sí parece una protección más fuerte

  • No me queda claro qué significa un cliente BlueSky first-party
    Si quieres decir que el relay first-party y el PDS podrían comunicarse entre sí usando otro protocolo, no termino de entender cuál sería la preocupación
    Dos clientes de ActivityPub también podrían hablar entre sí usando un protocolo que no sea ActivityPub
  • Se puede confiar porque todo el código es open source
    De hecho ya lo están haciendo así, y si empiezan a cambiar en otra dirección, la gente se va a dar cuenta muy rápido

• Está bien que hayan llegado a distinguir entre “expresión” y “alcance”, pero a largo plazo Mastodon se siente como la opción más inteligente por su simplicidad
  A corto plazo, como la curación del feed en Mastodon claramente es más difícil, puede ser menos divertido o menos útil
  La pregunta clave es cómo podría manipular esto un actor malicioso hipotético, probablemente rico o poderoso, si quisiera mover los hilos aquí
  En el artículo, esta parte se pasa demasiado por encima con algo como “no entiendo muy bien cómo funcionan los feeds”, y eso resulta muy sospechoso. Parece que sí saben muy bien cómo funcionarían los feeds, y que también saben que ahí hay poder y dinero, así que quieren agarrarlo

  • No parece apropiado resumirlo como “no entiendo muy bien cómo funcionan los feeds”
    El autor dice esto: “Los feeds son una función añadida recientemente a atproto, así que existen, pero puede que todavía no estén completamente terminados y podrían cambiar en el futuro. Habrá que observarlo. Desde mi perspectiva funcionan bien, pero no estoy siguiendo los detalles técnicos de bajo nivel.”
    En el párrafo inmediatamente anterior también aparece este contexto: “Una de las funciones estrella de BlueSky frente a otras herramientas de microblogging es la capacidad total de elección del usuario. Si quiero crear yo mismo un algoritmo de feed, puedo hacerlo y compartirlo fácilmente con otras personas.”
  • No veo en qué parte se dijo que no se sabe cómo funciona el feed
    El feed es de código abierto, existe ahora mismo, y hasta puedes ejecutarlo tú mismo
    Tampoco está claro a qué se refiere exactamente “mover los hilos”, ni de qué tablero está hablando ni en qué sentido. Aquí hay muchas piezas en movimiento

• La idea de que el usuario pueda elegir un proveedor de moderación independiente del proveedor de hosting suena genial
  Aun así, parece que las instancias igual tendrían que moderar para no alojar contenido ilegal en su jurisdicción
  Al final eso parece bastante difícil para quienes operan instancias, y podría llevar a bastante confusión. Puede que lo haya entendido mal

  • Quien aloja contenido tiene que afrontar las consecuencias legales del contenido que aloja, y al final no puede evitarlo
    Pero eso da igual qué protocolo se use
  • No lo entendiste mal. Creo que la descentralización de Bluesky es casi falsa
    El PDS puede correr en una caja Ubuntu más o menos normal, pero incluso este artículo reconoce que el relay es caro y es un enorme punto central de control
    ¿Cuál será el plan de Bluesky para combatir el spam? Probablemente bloquearlo en el relay
    El servidor DID también es otro punto central de control
    Aun así, por lo menos puedes correr el PDS libremente

• Como dato curioso sobre Bluesky, y enlazándolo con un artículo reciente, esto también viene a ser un nombre tomado de una persona
  El nombre de la CEO en chino significa literalmente blue sky

  • Curiosamente, Twitter ya había puesto bluesky como nombre del proyecto antes de que yo participara
    Fue coincidencia. Pero mi segundo nombre en chino significa bluesky

• También está bueno este cómic corto: https://bsky.social/about/welcome-to-bluesky-comic

• Si Bluesky dejara de dar soporte a did:plc, ¿todas las identidades PLC existentes quedarían rotas?
  Lo pregunto porque PLC parece estar estructurado de forma que hace ping a ese servicio

  • https://plc.directory se puede replicar, y si eso ocurriera, un nuevo espejo podría convertirse en el servidor autoritativo

• Soy escéptico con los labelers de terceros
  ¿Cómo se evita el abuso?

  • El usuario elige a qué labelers de terceros suscribirse
    Si un servicio de labelers empieza a abusar de su posición, el usuario simplemente puede dejar de usarlo
    Hay una explicación detallada de cómo Bluesky planea encajar los labelers en el ecosistema en https://github.com/bluesky-social/proposals/tree/main/0002-l...
  • La respuesta depende de qué tipo de abuso estés hablando
    Puedo dar mi opinión, pero la pregunta es tan amplia que no sé por dónde empezar a responder
  • Pronto vamos a publicar mucho más sobre moderación, pero la idea básica de los labelers es esta
    Cualquiera dentro de la red puede etiquetar cualquier cosa, incluidos otros labelers
    Las apps pueden mostrar qué labelers suscribir, igual que hoy muestran los feeds personalizados de Bluesky
    Las apps también pueden curar cómo se muestran y clasifican los labelers, del mismo modo que hoy muestran y ordenan feeds personalizados según su popularidad, que actualmente se expresa con likes y guardados

• El enfoque de que “las herramientas de moderación pertenecen a la capa de alcance. Toman todas las publicaciones, pero ofrecen una forma de limitar el alcance de lo que no quiero ver” termina pareciéndose a una moderación del tipo “si no te gusta, cierra los ojos”
  Sé que es una filosofía popular en Silicon Valley, pero me parece fundamentalmente defectuosa
  Hay situaciones legítimas en las que se debe impedir que otras personas no relacionadas hablen sobre cierto asunto o accedan a cierto contenido
  El ejemplo típico es el ciberacoso, el doxxing y la pornografía de venganza. Es cuando dos o más personas hablan de cómo dañar a un tercero, o publican información privada, humillante o falsa
  Quitar esa información del feed de la víctima es totalmente inútil, y de hecho es muy probable que ni siquiera aparezca ahí desde el principio. El daño viene de que otras personas vean ese contenido o participen en la discusión, y ese daño es real
  En un sistema de moderación tradicional, un moderador puede borrar la publicación para todos o bloquear al agresor para detener ese comportamiento. En un sistema que “solo oculta contenido”, eso no es posible
  Las listas compartidas de bloqueo o las “etiquetas” tampoco funcionan. Los consumidores de ese contenido no tienen incentivo para bloquearlo; al contrario, quieren ver pornografía de venganza
  Quien quiere bloquearlo es la víctima, pero la víctima no tiene poder para obligar a todos a usar cierta lista de bloqueo. Porque la esencia de este sistema es que nadie puede imponerle a otros una lista de bloqueo

  • Habrá más por venir en esta área. Este texto se enfocó en los casos normales y no trató los casos malos
    El equipo revisó estos problemas e incluso “consultó con expertos”, pero como sigue siendo un trabajo en curso, no siento que me corresponda hablar del tema todavía
    La parte de que “las etiquetas no funcionan porque la gente quiere verlo en vez de bloquearlo” está incluida explícitamente dentro del espacio de problemas que el equipo reconoció
    Como referencia adicional, aquí está esto: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei