atproto no tiene instancias
(overreacted.io)- La pregunta por una “instancia de Bluesky” aplica directamente al atproto el modelo de instancias de Mastodon, pero atproto fue diseñado separando el hosting de la agregación de apps
- Como con RSS y Google Reader, los datos no quedan encerrados dentro de una app, sino que viven en repositorios alojados, y varias apps toman esos datos y los muestran
- Una instancia de Mastodon es una estructura donde hosting, app, identidad y relación de federación vienen atados en una sola caja, así que las decisiones del administrador o una caída de la instancia afectan directamente la experiencia del usuario
- En atproto, los usuarios pueden mover su hosting o crear y probar nuevas apps, y apps como Tangled, Semble y Sidetrail funcionan por separado de Bluesky
- Para ver la descentralización de atproto, más que contar las instancias de Bluesky, hay que observar si realmente funcionan la migración a hostings alternativos y el ecosistema de nuevas apps
Un modelo más cercano a RSS y Google Reader
- En la era de RSS, los usuarios publicaban en sus propios blogs, y apps como Google Reader o Feedly agregaban publicaciones de muchos blogs
- Las publicaciones no “vivían” dentro de Google Reader, sino que permanecían en cada blog o en su lugar de hosting
- La clave es la separación entre hosting y agregación
- El hosting es donde existe realmente el contenido
- La app agregadora se parece más a una proyección de contenido de múltiples fuentes
Las redes sociales centralizadas y la respuesta de Mastodon
- Las redes sociales tradicionales operan reuniendo a todos los usuarios dentro de una sola app y un solo espacio
- Esa estructura genera centralización y fuertes efectos de red, y la discusión sobre redes sociales descentralizadas parte de cómo dividir ese problema
- El enfoque tipo Mastodon consiste en que cada comunidad opere su propio “pequeño Facebook” o “pequeño Twitter”, y esa caja es la instancia
Lo que une una instancia de Mastodon
- El usuario pasa a pertenecer “dentro” de una instancia específica
- La razón por la que el login de Mastodon tiene el formato
[email protected]es que la identidad incluye a la instancia - El usuario ya no es una “Alice” abstracta, sino “Alice de la instancia #1”
- La razón por la que el login de Mastodon tiene el formato
- Para que usuarios de distintas instancias se comuniquen, las instancias tienen que intercambiar mensajes
- Si Alice está en la instancia #1 y Bree en la instancia #2, cuando Alice sigue a Bree, las publicaciones de Bree se envían a la instancia #1
- Esa relación de intercambio es la federación
- Como hosting y app vienen unidos, el usuario termina dependiendo fuertemente de la instancia
Las limitaciones que crea ese acoplamiento por instancias
- Si surge un conflicto entre administradores de instancias, pueden cortar la federación entre ellas
- En ese caso, los usuarios pueden dejar de ver las publicaciones de sus amistades
- Si la instancia del usuario se cae, también desaparece la identidad atada a esa instancia
- Porque los seguidores seguían a “un usuario de esa instancia”
- Las flechas de conexión entre instancias crecen en O(n²)
- Puede que hoy no sea un gran problema, pero podría volverse importante si este tipo de red social gana popularidad
La diferencia clave de atproto
- atproto no parte del concepto de instancia al estilo Mastodon, sino que vuelve al modelo de RSS y Google Reader
- A nivel de red, separa hosting y agregación
- Los datos están en el hosting
- Las apps agregan datos desde el hosting de muchas personas
- Por eso, en atproto no hay instancias
- El hosting se puede cambiar
- Las apps agregan datos desde muchos hostings
- Esta estructura se siente como una forma de descentralización más rica que “operar muchas copias de una sola app”
La descentralización que los usuarios pueden hacer por sí mismos
- Los usuarios pueden cambiar de hosting
- El autor dice que movió sus datos de atproto a Eurosky y que, salvo algunos problemas de UX, el proceso fue automático
- Si alguien quiere ir más allá, también puede hacer self-hosting gratis en Cloudflare
- También se pueden probar nuevas apps o crearlas directamente
- Tangled y Semble son ejemplos de apps de atproto no relacionadas con Bluesky
- El autor creó una app llamada Sidetrail, y es open source
- atproto también tiene un tutorial de Statusphere para crear apps
Por qué contar las “instancias de Bluesky” no apunta al problema correcto
- En Mastodon, medir la descentralización por cantidad de instancias es algo natural
- Porque la forma principal de descentralización en Mastodon consiste en operar más cajas donde hosting y app van juntos, y hacer que hablen entre sí
- En atproto, todas las apps se parecen más a una proyección de toda la Atmosphere
- Es la misma estructura que cuando Feedly y Google Reader muestran toda la Blogosphere
- Es posible operar muchas copias completas del servidor de base de datos de Bluesky, pero eso no suele ser tan útil como operar muchas copias de Google Reader
- Algunas copias existen para necesidades específicas
- Blacksky es un caso orientado a requisitos concretos, como una filosofía de moderación distinta
- El cliente reddwarf.app no usa una base de datos dedicada, sino constellation, un caché gratuito operado por la comunidad
- Se dice que infraestructura de red compartida como Relay ha venido operando a bajo costo durante un año
Qué hay que mirar en atproto
- Para evaluar la descentralización de atproto, no hay que fijarse en la “cantidad de instancias de Bluesky”, sino en lo siguiente
- si la gente se está moviendo a hostings alternativos
- si la gente está creando y usando nuevas apps
- Separar hosting y apps puede corregir los incentivos rotos tanto en redes sociales cerradas como en redes federadas
- El núcleo de atproto es que los datos del usuario queden fuera de la app, y que las apps agreguen sobre esos datos
1 comentarios
Comentarios de Hacker News
Parece que malinterpreta a propósito la pregunta “¿dónde está la instancia de Bluesky?” para elogiar ATProto y menospreciar ActivityPub
Al hacerlo, omite o distorsiona hechos técnicos interesantes, como los relays de ATProto y sus ventajas y desventajas, o la migración de cuentas en ActivityPub y sus pros y contras, y crea un conflicto innecesario entre dos plataformas que resuelven problemas parecidos
También habrá gente que use “instancia” en su sentido general, como servidor, software en ejecución, máquina virtual o contenedor, así que no entiendo por qué insistir en interpretarlo solo con el concepto al estilo Mastodon
El diagrama y la explicación estaban bien, pero las pullas sutiles hacia ActivityPub dieron la impresión de venir más de la hostilidad que del deseo de informar, y eso fue una pena
Compararlo con “¿dónde está la instancia de Google Reader?” me pareció una buena forma de mostrar lo rara que suena esa pregunta, y también creo que los dos diagramas del final explican bastante bien algo que solía pasarse por alto en las primeras discusiones sobre atproto/ActivityPub
Expliqué aquí por qué no incluí los relays: https://news.ycombinator.com/item?id=48600963
Los relays se parecen más a una optimización de rendimiento que a una parte central del modelo, así que en el artículo quise concentrarme en el modelo en sí
A medida que la palabra empezó a asociarse con un concepto y una estructura específicos, mucha gente piensa en un modelo federado al estilo ActivityPub cuando ve “red social descentralizada”, y al ver ATProto termina preguntando “¿por qué solo hay una instancia de Bluesky donde la gente se registra?”
Aunque no sea una perspectiva totalmente nueva, parece un artículo útil para volver a enlazar más adelante a personas que ya tienen esa asociación previa muy fijada en la cabeza
En vez del decreto “filioque”, lo que va y viene son posts de blog donde cada lado habla de algo distinto al definir qué significa “federación”
El modelo del Fediverse es fácil de entender desde la perspectiva de las redes sociales existentes, pero ATProto es una idea nueva que busca dar al usuario soberanía sobre sus datos sin perder la escalabilidad de una red social centralizada
Creo que la analogía aquí no funciona
RSS no dependía en absoluto de Google Reader, y ni siquiera en su apogeo dependía tanto de este como hoy el correo electrónico depende de Gmail
En ATProto, para que AppView sea útil depende bastante de los relays, y operar un relay también cuesta bastante
Además, el círculo amarillo en el diagrama de RSS representa un blog, mientras que el círculo que representa una publicación de Facebook es de otra naturaleza. Un blog es independiente por sí mismo
No quiero decir que ATProto sea malo, pero este artículo da la impresión de aumentar la confusión en vez de aclararla
Antes eran un poco más caros porque almacenaban todo el tráfico, pero esa parte se eliminó en sync 1.1 y ahora se pueden ejecutar con bastante facilidad incluso en una máquina virtual de 20 dólares al mes
Lo realmente caro y difícil, sea centralizado o descentralizado, sigue siendo la moderación
El autor de este artículo abordó hace 9 meses un malentendido común sobre los relays: https://news.ycombinator.com/item?id=45077291#45078223
Yo veo el relay como el pegamento que hace que ATProto funcione bien en términos de rendimiento
Parece encargarse de transportar datos sin importar el contenido y de reducir la cantidad de servicios que cada AppView necesita conocer
Como dice el artículo, una gran mejora frente a Mastodon es que relay, AppView y PDS son servicios separados con necesidades de escalado distintas, y es una solución bastante elegante para un problema de diseño de sistemas
[1] https://atproto.com/guides/glossary
Pero es una optimización invisible y existen otras estrategias, por eso en el artículo se omitió en gran parte
Por ejemplo, hoy muchas apps pequeñas no crean su propio índice de base de datos y dependen de Constellation(https://constellation.microcosm.blue/), así que no usan relays en absoluto
Dicen que solo eliminan contenido que sería ilegal alojar, pero no sé qué tan cierto sea eso y siempre existe el riesgo de que cambie en el futuro
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
Estuvo bien que explicara la diferencia entre ambos enfoques
Pero fue frustrante que no respondiera a la pregunta de “¿cómo resuelve ATProto los problemas que resuelven las instancias?”
Por ejemplo, si se reduce la defederación a una especie de razón desconocida por la que puede que no veas las publicaciones de tus amigos, entonces no se puede responder a “entonces, ¿cómo resuelve atproto los problemas que resuelve la defederación?”
En ese marco, la respuesta básica que surge naturalmente es “no los resuelve”
A nivel de hosting, el proveedor puede bloquear una cuenta por algo claramente ilegal, igual que blogspot.com o Cloudflare bloquean en ciertos casos
A nivel de aplicación, los administradores de la app y los moderadores lo gestionan como cualquier otro servicio web que maneja contenido generado por usuarios
Es una decisión del desarrollador de la app: puede ofrecer elementos básicos de moderación por espacios de usuarios como Reddit, o conectar un servicio de moderación aparte como Bluesky
Como no existe nada equivalente a “instancias comunitarias” que puedan pelear entre sí, tampoco hay defederación. Solo hay hosting, app y moderación a nivel de app según las decisiones del desarrollador de la app
Esto es esencialmente parecido a lo que hace Microsoft con el correo electrónico. Salvo con los proveedores más grandes, descarta mensajes, y en la práctica la federación termina haciendo que, para que tus usuarios puedan entregar mensajes, tengas que usar Microsoft u otro gran actor establecido
Entonces una instancia nueva no puede entregar mensajes ni conseguir usuarios. Los grandes actores establecidos adquieren un incentivo perverso para no federarse con instancias nuevas
Este tipo de decisión arquitectónica tiene el efecto, a largo plazo, de consolidar un oligopolio
Se dice que es necesario para combatir el spam, pero hay proveedores que no hacen eso si configuras bien DKIM, reverse DNS, etc., y aun así normalmente puedes entregar a Gmail, y tampoco sufren más problemas de spam
La alternativa obvia es filtrar del lado del cliente. Si los filtros los proporciona un proveedor de listas al estilo de uBlock, en vez de un operador como Microsoft, no existe el incentivo de empujar a todos hacia su propia instancia porque no están operando una instancia específica
A menos que haya muchísimos AppView capaces de consumir todo el firehose, entre los que se pueda elegir libremente, y un universo alternativo que uno mismo pueda operar de forma directa y barata
ATProto se parece más a un RSS de un mundo donde solo puedes leer RSS con Google Reader o con un servicio clonado de escala similar, y no con un lector RSS de escritorio o móvil
Si grazna como pato, es un pato
Las cuentas tienen un solo PDS, y el DID apunta al PDS que es el feed oficial de datos del usuario y el destino de escritura
Los datos pueden replicarse, pero el PDS se trata como la fuente autoritativa
Esto se parece mucho más a una arquitectura cliente/servidor que a una arquitectura distribuida
No hay base de datos P2P, ni se escribe en una DHT o en peers. Se escribe en el PDS, y esa escritura se refleja opcionalmente
El descubrimiento también se hace por DNS, así que tampoco se les pregunta a los peers por los datos
Uno se conecta al relay no como peer, sino como cliente que solicita una copia de los datos alojados de forma autoritativa en el PDS
No me parece forzado llamar instancia al PDS, y espejo al relay
Solo que no es lo mismo que normalmente quieren decir quienes hablan de “instancias” en Mastodon
En Mastodon, una instancia es un paquete inseparable que combina hosting de datos, app, comunidad y moderación
Entiendo que ATproto sacrifica la descentralización real para lograr consistencia, mientras que Mastodon y ActivityPub sacrifican la consistencia real para ofrecer una descentralización más accesible
porque operar un nodo de ActivityPub es mucho más accesible para un usuario común de self-hosting que operar un relay de contenido de AT
Al final, lo único que puedes “descentralizar” en AT son tus propios datos, y se parece más a la propiedad de tus propios datos que a poseer colectivamente una parte de la red
También es algo que ya se ha repetido muchas veces en HN
En ActivityPub, operar una instancia significa encargarse de los datos, la aplicación y también de los problemas de escalabilidad posteriores, así que tienes que elegir entre asumir tú mismo la responsabilidad operativa o quedar atado a la instancia de otra persona
Incluso si no te gusta la instancia que elegiste y quieres mudarte, si eso todavía no ha cambiado, en la práctica casi tienes que empezar de cero
En AtProto, es fácil moverte a otra plataforma de aplicaciones manteniendo la misma identidad, y también es posible exportar tus datos desde la plataforma y alojarlos tú mismo, aunque la experiencia de usuario sea difícil
Por ejemplo, hace poco probé Tangled por primera vez y pude iniciar sesión con mi dominio existente basado en bsky (h14h.com). No necesité crear una cuenta nueva ni un nombre de usuario nuevo; fue como si ya estuviera ahí
Configurar el self-hosting de un repositorio git en un VPS tomó, como mucho, media tarde, y funciona como un servicio de backend que casi no requiere atención
En el peor de los casos, aparece un banner en tangled.org diciendo algo como “tu repositorio está desactualizado y podría no ser compatible con la versión más reciente de Tangled”, y se resuelve reconstruyendo y desplegando la imagen de Docker con la versión más reciente
Arquitectónicamente, AtProto sin duda es más difícil de entender, pero me parece mucho más simple llevarlo al punto en que usuarios reales lo usen
En mi cabeza, más que un solo deslizador, se parece a un buffet de trade-offs
Como referencia, incluso en el mundo de AP hay personas y equipos pequeños operando relays, mirrors, caches y AppViews. Eso sí, es cierto que puede volverse más caro a medida que escala
AT no solo ofrece consistencia, sino también un modelo de datos compartido para todo el ecosistema de apps
Por eso las apps pueden referenciar y renderizar contenido de otras apps. Es como una especie de web de JSON tipado, y las distintas apps son lentes para ver la misma red
Cualquiera puede construir una experiencia nueva sobre los datos existentes, y en AP casi no hay equivalente a eso
AP acopla los datos a la app, mientras que AT se parece más a que todas las apps consulten una única base de datos global con los datos de todo el mundo
No entiendo por qué la discusión siempre se atasca en los relays. Hoy en día, si quieres, puedes operar un relay por unos 30 dólares al mes, y también puedes usar gratis el relay de Bluesky o relays comunitarios
Muchas apps ni siquiera usan relays y dependen de índices comunitarios como Constellation(https://constellation.microcosm.blue/). Incluso hay apps que no operan su propio servidor ni su propia base de datos
Pero más bien al contrario, yo querría argumentar que ATproto está más descentralizado, o al menos intenta estarlo
En el mundo de ActivityPub, la identidad, la aplicación y el hosting están conectados de forma esencial
Para usar Lemmy, tienes que crear una segunda cuenta permanente y separada de ActivityPub en esa instancia de Lemmy, o usar Lemmy solo en la medida en que tu instancia de Mastodon sepa enviar mensajes que Lemmy entienda
Cada nueva app de ActivityPub crea nuevos problemas de interoperabilidad, porque cada app posee su propia identidad y su propio hosting
No hay forma de que mi instancia de Mastodon autoalojada proporcione mi identidad a un servidor de Lemmy y que ese servidor de Lemmy luego le diga a mi instancia que aloje contenido en mi nombre
Para estar al nivel de lo que promete ATProto, al menos se necesitaría algo así. Aunque no sé hasta qué punto eso aplica al ATProto que existe realmente, y el ActivityPub que existe realmente tampoco es tan interoperable como dicen sus defensores
Este blog explica bien la arquitectura
Pero en la práctica yo pensaba que el “problema” era que la empresa Bluesky opera la app principal y aloja la mayor parte de los datos de los usuarios
A nivel de protocolo está descentralizado, pero el sistema real sigue siendo muy centralizado desde la perspectiva de quién tiene el control
No digo que necesariamente sea culpa de Bluesky, pero parece que hasta ahora así es como se han dado las cosas
Este problema no es algo particular de Bluesky ni de ATProto; ya sea una organización con fines de lucro, una sin fines de lucro o un grupo de voluntarios, la gente siempre encuentra algo que cuestionar
No soy inversionista ni tengo conflicto de interés con Bluesky más allá de haber sido usuario temprano. Dentro de mis límites, también entiendo el protocolo, la empresa y el sitio web
El sitio y la app funcionan bien. La gente está demasiado enfocada en encontrar problemas, en vez de construir soluciones más grandes y mejores
La gran mayoría no quiere soluciones P2P improvisadas como Lemmy o Mastodon. Quiere que el contenido esté en un solo lugar y poder exigirle responsabilidades a esa entidad
Por eso creo que las redes sociales P2P nunca se van a masificar. Ha habido más drama alrededor de Lemmy y Mastodon que en Twitter, Reddit y Facebook juntos
Es mi opinión, y parece que mi pareja y mis amigos piensan lo mismo
Está descentralizado tanto en teoría como en la práctica
Dicho eso, como Bluesky opera la parte más grande, sí se puede decir que no está descentralizado a nivel de comunidad o de mindshare, aunque eso también está cambiando
Solo dice que “no hay instancias”, pero no explica cómo esa arquitectura evita problemas como autenticación, sincronización y descubrimiento
Elegir Google Reader como analogía se siente de mal agüero
RSS sobrevivió incluso después del cierre de Google Reader, pero no sobrevivieron todas las comunidades que usaban RSS, y muchas de ellas ni siquiera saben hoy qué es RSS
Decir que algo es descentralizado mientras se sigue señalando la enorme centralización social del ecosistema descentralizado como si fuera un buen ejemplo se siente casi freudiano
Sobre todo porque ya conocemos ese desenlace
Google Reader reunió muchas casas de RSS en una sola, y añadió valor como el grafo social y los comentarios, pero se vino abajo por un capricho de los ejecutivos de Google, casi mató a RSS y destruyó un impresionante grafo social
Esa analogía no inspira mucha confianza en ATProto
la app solo lo indexa
así que, en esta analogía, cualquiera podría revivir Google Reader o competir con él usando el mismo grafo
si te da curiosidad, ahora mismo http://leaflet.pub funciona de hecho de esa manera
imagina que no pudieras usar lectores RSS de escritorio o móviles, y que solo pudieras leer RSS mediante Google Reader o un servicio clonado de escala similar
hace poco alguien incluso mencionó NetNewsWire
La diferencia importante es que los blogs tienen su propio sitio web, y no es obligatorio poner el texto completo en el feed RSS
Bluesky normalmente no funciona así. Todo lo que está en el PDS se replica
Además, se incentiva poner entradas completas del blog en el PDS para facilitar la replicación
Entonces cualquiera que quiera indexarlo puede llevarse una copia, y no hay control sobre lo que haga con ella
No tiene que ser así necesariamente. También puedes publicar tu blog en tu propio sitio web y poner solo enlaces en Bluesky
montar un frontend HTTP sobre una cuenta de atproto es una forma recomendada de hacerlo, y de hecho mucha gente lo hace
yo mismo lo hago en pfrazee.com, y las entradas de mi blog leaflet cuyo original está en atproto también se renderizan en mi blog
La comparación con RSS lleva a confusión
Las apps de Atproto no son como lectores RSS que corren en la computadora del usuario y se conectan directamente al origen del contenido
Las apps de Atproto son servidores que controlan, filtran y dan forma al contenido que se le entrega al lector
Las apps de Atproto pueden censurar, hacer shadowban, mostrar anuncios y convertir el feed en uno algorítmico como quieran
El usuario queda indefenso, y el creador se vuelve una víctima que no puede hacer más que quejarse
El hecho de que cualquiera pueda alojar los datos en cualquier parte no significa absolutamente nada si no hay una forma de distribuir esos datos
para empezar, puedes usar otro AppView que no haga esas cosas
los feeds pueden volverse algorítmicos de la forma que el usuario quiera, y si hay varias apps, no quedas atado al algoritmo que quiera imponer un productor central