Federación, filosofía y futuro en Bluesky

Repasamos a fondo AT Proto, los cimientos bajo Bluesky, y las grandes diferencias que pueden existir entre diversos sistemas federados.

Hay muy buenas ideas en AT Proto que deberían ser consideradas por otras plataformas, y también graves problemas que forman parte de la filosofía original de su creación.

• Entrevista a los criptospammers que inundaron Mastodon
• Los problemas del spam en Mastodon
• Decentralized Identifiers (DIDs) v1.0
• ATProto Feed Generator Starter Kit
• Bluesky lanza feeds con algoritmos personalizados
• Discusión en Hacker News
• First impressions of Bluesky's AT Protocol
• FAQ de AT Protocol
• Bluesky vs. Nostr

Don Tomás es un programa está presentado por Ramón Medrano (SRE de Google en Zurich) y Álex Barredo (creador de mixx.io)

En cada episodio explican con detalle los protocolos, estándares, plataformas y programas que hacen funcionar al mundo.

Para suscribirte y escuchar más episodios, visita https://cuonda.com/don-tomas

---

Síguenos en https://ublog.tech/@r y https://mastodon.social/@barredo 

Puedes contactar por correo en alex@barredo.es o m3drano@gmail.com 

Bienvenidos a un nuevo episodio de Don Tomás, el podcast en el que nos adentramos en este mundillo de la descentralización y de esta nueva oleada de interés por este tipo de tecnologías. Mi nombre es Alex Barredo, aquí me podréis llamar Don Alex y conmigo está Ramón Medrano alias Don Ramón.

¿Qué tal estás? Bien, bien. Aquí ya preparados para la siguiente oleada de comentarios. Hablando de oleadas, creo que en el anterior episodio dejamos comentado el spam de Mastodon, que algunas personas se sorprendieron por este flujo masivo de mensajes directos. Recordemos, los mensajes directos dentro del sistema de ActivityPub y de Mastodon no son mensajes privados, porque en algunas aplicaciones más comunes de estas últimas décadas suelen ser sinónimos, pero aquí no.

Y lo bueno es que tenemos un post-mortem de Brian Krebs, nuestro amigo. Sí, sí, sí. Eran dos... Bueno, la estafa, vamos, lo que ellos ganaban era una estafa de criptomonedas, que bueno, es típica últimamente. Muy burda. Utilizaron el... Bueno, las protecciones contra spam de ActivityPub son todavía bastante, vamos a decir, primigéneas.

Al final requieren la moderación de los propios administradores de las instancias, que bueno, fue lo que se hizo. Pues esas instancias las fueron quitando. Y lo que hacían era mandar un montón de mensajes privados con enlaces a... Bueno, pues para comprar criptomonedas o lo que fuera, y ganaron con esta campaña como algo menos de dos mil dólares.

Que bueno. Sí, esa cifra me dio mucha curiosidad, porque me hace mucha gracia lo que consigue Brian Krebs cuando hace estas investigaciones de intentar dar con los orígenes y tal. Porque obviamente es un poco como el espíritu de muchos de sus artículos, al menos de los más interesantes. Y que la gente le contesta y le habla sin mayores problemas, de una forma relativamente abierta.

Y me hace mucha gracia eso. Como empezó a intentar detectar a través de las IPs desde las que recibieron los ataques, que se las pasó el equipo de Mastodon. Bueno, de Mastodon punto social, porque recordemos en principio es el origen de los registros y de los ataques, etcétera. Y al final pues eso. Encontró a dos ciudadanos rusos.

Uno que vivía en Rusia y otro que vivía en Austria, si no recuerdo mal. Y ahí están. Dos mil dolarcitos que dicen que es poco. Es poco porque también tiene un coste tuyo de hacerlo y su infraestructura también. Hombre, habrán ganado dinero. Ellos dicen, Brian Krebs dice que se gana bastante más en otras redes como Twitter. Quizá sea también por la cantidad de usuarios que hay.

¿Tú crees? Cuando hablamos de que ActivityPath, Mastodon en particular, tiene unas protecciones anti spam o hijacking primigenias. Twitter lleva muchos años funcionando y operando. Sin embargo, todavía es posible realizar ataques de este tipo o campañas de este tipo. ¿Cómo prevenir esto? Pues hay que mirar otra vez al email. En el caso de ActivityPath, ¿qué se ha hecho? El protocolo es un protocolo permissionless.

Es decir, tú puedes poner una instancia, se federa y puedes empezar a enviar mensajes, participar del protocolo escuchando o enviando o siguiendo. En algún punto hay que poner como un filtro que permita detectar spam, contenido malicioso y demás. ¿Cuál es el filtro? Yo creo que por la arquitectura que tiene el protocolo va a estar en la definición del inbox, que es exactamente igual que cómo se hace con el con el email.

Por ejemplo, cuando tú tienes una instancia y te llegan elementos de personas que están publicando mensajes o seguimientos o publicaciones de lo que sea, ahí es cuando se puede filtrar. Y técnicas, pues las muy similares a las del email, se pueden utilizar listas de reputación, por ejemplo, tanto de direcciones IP como de nombres de dominio. Se puede utilizar, algo que se usa menos en el email, pero se podría utilizar señales de bloqueo de los usuarios.

En Mastodon, igual que en Twitter y en otras redes sociales, tú puedes bloquear a un usuario. Eso es una señal bastante potente de que el contenido que esa persona o que esa cuenta está produciendo tiene características negativas. Claro, el porcentaje, una especie de relación o de cálculo entre el número de bloqueos, el porcentaje de bloqueos con respecto a los seguidos, esas mediciones con respecto a la fecha de nacimiento de la cuenta, todo lo que se varíe con demasiada

envergadura de lo que son las medias de usuario normal, todo eso son grandes variables para ir sumando e ir detectando cosas así. Sin embargo, sigue siendo un problema sin solucionar en el correo electrónico. Y no lo va a ser solucionado. Lo que podemos hacer es tener mejores sistemas y tener una mejor señal ruido, un ratio de señal ruido mejor.

Pero en la producción de contenido no deseado, ya no malicioso, simplemente contenido no deseado como mala publicidad, spam y demás. Eso no va a ser un problema que se pueda solucionar, salvo que incorpores permisos para acceder al protocolo. En el sentido de que, por ejemplo, cuando quieres crear una instancia, pues tienes que pasar una serie de validaciones o el resto de instancias te tienen que aprobar.

Creo que eso no es deseable tampoco. No, francamente yo creo que los contras de ese tipo de técnicas son mucho mayores que las ventajas que pudiera llegar a tener. El tema de las IPs a mí me da como un poco más de interés porque además cuentan que estaban utilizando los típicos relays, los típicos proxys en ordenadores de todo el mundo domésticos, ordenadores hackeados por algún tipo de malware y eran esos ordenadores los que enviaban los mensajes, con lo cual bloquear

por IPs pues hubiera sido difícil en este caso. Sí, usan las típicas redes de, o sea, tú infectas con un troyano un computador, son redes de bots, ¿no? Entonces, televisores inteligentes, programas de IOT, dispositivos que están por ahí sin mayor problema, servidores web que puedes detectar con vulnerabilidades muy fácil, con Shodan o cosas de estas.

Entonces, una vez tienes un control de una red de bots importante, por ejemplo, hubo una muy famosa que se llamaba Mirai, lo que puedes utilizar es todas esas computadoras que tienes gratuitamente para ejecutar cosas. En este caso puede ser, por ejemplo, generar mensajes de Mastodon. Podrías hacer algo mucho más sofisticado, que es convertir a cada uno de esos en una instancia y que distribuidamente, por ejemplo, pueda distribuir mensajes.

No hemos visto todavía un ataque de denegación de servicio a la red de Mastodon y estará por venir. Sí, bueno, creo que en este caso decían que en el momento que les estaban jugando este juego el ratón, la gente de Mastodon Social, que bueno, ahora ya por suerte tienen más empleados, tanto para el desarrollo de lo que es las aplicaciones como de los protocolos, como de la arquitectura, etcétera, y de la modelación del propio servidor, que esos al final son el mismo equipo, en cierto sentido, que diseña las aplicaciones oficiales, que a mí no me

gusta la palabra oficial, vamos a decir, no lo sé muy bien cuál sería un adjetivo mucho más correcto, y se encarga de esos dos grandes servidores. Entonces, decían que seguro iban tapando los nuevos registros o el enviar contenido por parte de esas IPs, que iban cambiando a recibir ataques de denegación de servicio.

Yo no sé si es por cómo estaba diseñado el bot de lo que los enviaba, que a lo mejor no entendía bien que estaba siendo bloqueado, y hacía una acumulación de mensajes, o que directamente fuera otro proyecto como agresivo. Ah, me bloqueas, pues no te preocupes, aquí van un par de gigabits por segundo. Sí, es que además el protocolo ActivityPub tiene problemas que los mensajes, tú al recibirlos en tu inbox, puedes tirarlos allí.

El tema es que cada uno de los mensajes tiene un cierto grosor, no pueden haber mensajes pequeños, que puedes decir, por ejemplo, como cuando abres una conexión TCP, ya solo con el SIM, ya puedes tirarla abajo y se bloquea mucho mejor un ataque de denegación de servicio. En un protocolo de aplicación como es ActivityPub, vas a tener que recibir todos los mensajes, evaluarlos y tirarlos abajo, los que sean maliciosos en este caso.

El caso es que el coste por mensaje es bastante elevado, entonces si tienes un servidor como Mastodon Online, por ejemplo, o Social, que son de los más grandes, pero bueno, así todo, parece que son dos o tres máquinas, no es una cosa enorme, es relativamente sencillo echarlos abajo, si uno quiere. Sí, a ver, yo creo que, porque hay un montón de partes que están hechas en Ruby, o Ruby on Rails, no recuerdo, creo que es Ruby simplemente sin Rails, o no me acuerdo como estaba lo que es el Mastodon, Mastodon, y las

partes de los servidores, todo esto del sistema de Sidekiq, yo creo que se puede implementar una capa intermedia, una capa original, una especie, un híbrido, un IPTables maravilloso, federado, yo que sé, la verdad. En fin, me ha resultado muy curioso todo este postmortem, todo lo que han estado contando, y sin embargo, lo que más salseo ha tenido, un poco por decirlo así, ha sido un enganchón en redes sociales, bueno, en Hacker News y en diferentes posts,

tanto en Mastodon como en el propio BlueSky, entre desarrolladores de uno y desarrolladores de otro, una especie de patio de colegio, pero con argumentos técnicos interesantes, ¿verdad? Sí, es un, comparación del, bueno, lo que comparan, hay que decirlo precisamente, es el protocolo ActivityPub con el protocolo AT, que sería el que está detrás de BlueSky, y en el caso de ActivityPub, la implementación más prominente es Mastodon, ¿no? Entonces,

este es un, Sam Wright, es un desarrollador, me parece, de ActivityPub o de Mastodon, entonces, bueno, hace la comparación, claro, con su propio sesgo de haber sido, digamos, una parte en el proceso, pero tiene unos comentarios interesantes, que podemos ver las diferencias de filosofía entre un protocolo y otro.

Lo primero que hay que decir es lo que comentábamos antes, ambos son protocolos que se supone descentralizados, pero realmente, de BlueSky, solo hay una instancia a día de hoy, ¿no? O sea, eso es una verdad. Eso es. Donde cambian mucho, y creo que eso es una cosa del origen de la filosofía entre los dos protocolos, es en el manejo de la identidad.

En el ActivityPub, la identidad tiene un paralelismo uno a uno con el email, otra vez. Tú tienes un nombre de usuario en una instancia. Si quieres tener otro nombre de usuario en otra instancia, eso es una identidad separada. Puedes mover datos de una a otra, es decir, una cierta portabilidad, pero son técnicamente dos identidades separadas.

Es decir, la identidad en Mastodon no es una identidad distribuida, es una distribución de identidades. En AT, es distinto. Es distinto porque lo que existe es un identificador distribuido, un DID, que se llama, que eso es, una vez estás en lo que sería la supuesta federación que va a haber de instancias de AT, cuando tú te registras una de estas, vas a tener un identificador único, que por diseño sería transferible de una instancia a otra.

Es decir, tú puedes moverte de una instancia a BlueSky, ahora la que hay, cuando aparezcan instancias, por ejemplo, una en Europa, otra que sea de videojuegos o lo que sea, te puedes mover y tu identificador único se porta. Es decir, tu identidad no varía. Creo que eso está bien porque es uno de los problemas que tiene otros tipos de servicios en los que, por ejemplo, si tú quieres cambiar de Mastodon a Twitter, no hay manera de portar tu identidad.

O sea, fuera de ese concepto es imposible. No es una portabilidad universal, es decir, sería un identificador único en AT y ya está. Pero bueno, así todo está bien. ¿Qué pasa con la segunda capa de identidad? En AT hay dos niveles de identidad. Tu identificador, tu DID, es único, es inmutable y nadie lo va a ver porque lo que tienes es un handle asociado al identificador.

Ese handle tiene dos versiones. El handle puede ser muy a lo Mastodon. Si tú te registras en BlueSky ahora mismo, tienes un nombre de usuario a punto BlueSky punto algo, ¿no? O puedes utilizar tu propio dominio. Es decir, puedes tener un dominio que tú tengas, añades un registro TXC con una firma digital en concreto para que se verifique que tú eres el propietario de ese dominio o que tienes acceso a ese dominio como, por ejemplo, en punto Amazon punto lo

que sea. Alguien lo hizo el primero y se lo quedó. Si tienes acceso a poder establecer registros puedes asociar tu DID a un dominio también. Eso está bastante bien y tengo que decir que estuve intentando probarlo y al final lo conseguí.

Pude poner mi propio dominio barredo punto es como mi identificador, pero tengo que decir que mi proveedor de dominios punto es, que es la gente de Arsis, cuando le das a cambiar los DNS tienes los CNAME, los de MX, de correos y tienes los de TXT. Los de TXT son, si no me equivoco, como relativamente genéricos. Es decir, como para poner lo que entre comillas quieras, ¿no? Y el problema es que debe haber algún fallo en Arsis que cuando seleccionas uno de tipo TXT, al contrario que un A, un CNAME, etcétera, le asignas

esos valores, pero ellos lo asignan como CNAME, con lo cual nunca llegaba a ser verificado porque era de tipo CNAME. Me moví la gestión de los nameservers y los DNS a un proveedor de estos gratuitos de por ahí y en cuanto lo puse al minuto ya estaba propagado y me identificaron, pero me tiré así dos semanas y al final resulta que es un bug, un fallo del panel de administración de Arsis.

Pero bueno, aviso para los sysadmins de Arsis si quieren solucionarlo y luego con los otros dominios sin ningún problema. La verdad, con Mixio, por ejemplo, fue también cuestión de segundos en cierto sentido. Funciona guay. Lo que no he probado de momento y hasta que no pongan nuevos servidores es eso, la portabilidad completa.

Es decir, qué es lo que me voy a llevar porque sé que me puedo llevar mi identificador, pero lo que sigue sin quedarme claro es el contenido. No está definido. En el caso de Mastodon está definido como no se va a mover, solo se va a mover tus seguidores. Es decir, hay un mensaje especial dentro del protocolo para hacer una transferencia.

Entonces todos los seguidores que tú tengas van a recibir en todas las instancias un cambio. En el caso de AT está indefinido y es una pena porque en el caso de tener un identificador único y en el caso de, por ejemplo, ofrecer a la gente tu propio dominio, eso tu cuenta cuando lo tienes configurado así es completamente independiente de la instancia en la que está corriendo.

Es decir, tú podrías moverte a otra instancia y los otros usuarios no darse cuenta en absoluto porque tu identificador único no cambia y si tienes un dominio ni siquiera el dominio cambia. Entonces yo espero que sí que muevan el contenido porque creo que sería una mejora en respecto al ActivityPath en este caso de lo que es la portabilidad.

Entiendo que en ActivityPath no se puede hacer porque tú cambiar cambias de identificador. Entonces simplemente estás diciendo que ahora tienes un alter ego nuevo, no que tus datos se han movido de una instancia a otra. Es lo que está pasando. Francamente creo que sí debería de poder hacerse.

Sobre todo porque ahora estamos viendo que tras el aluvión de octubre noviembre del año pasado de venga la desfederalización, o sea la federalización, nos vamos todos a montar nuestros servidores, etc. Está habiendo servidores medianos, vamos a decir así, que han dicho sus administradores. O sea, esto es demasiado trabajo, esto es demasiado jaleo, la gente grita mucho, banea este, banea tal cual, y recibían palos de todas partes.

En algunas instancias, nunca mejor dicho. Y claro, si tú has decidido echar ahí en esos meses o en ese año diez mil mensajitos y ese servidor va a morir, pues es contenido que se va a perder. Entonces yo creo que sí se podría extender ActivityPath, enmendarlo, una especie de mensaje que sustituya el original por una redirección, que dure lo que pueda durar, de que ese mensaje está en el nuevo sitio y que en el nuevo sitio ya tenga una copia,

incluso a lo mejor con un parámetro de que es una copia original, de una mudanza, no es que alguien haya copiado el mensaje y lo haya puesto, y que eso permita en un momento dado enviar contenido con fecha antigua. Que eso, claro, no se puede hacer para no cambiar el pasado, salvo en ese caso de las de las mudanzas que yo creo que se podría enmendar para que fuera así.

Es que si no, es muy peligroso esto. Sí, no, si no hay un problema más de archival, o sea, de todos los mensajes antiguos, tal, eso sería bien que se pudiera hacer. Se puede hacer sin ningún problema, lo único que las mudanzas de usuarios son picos de movimiento de tráfico importante. En el caso de Mastodona además, los mensajes no están autentificados unos detrás del otro.

La autentificación que tienen los mensajes es el origen del propio mensaje que venga de la instancia que dice sí, por DNS y ya está. Es decir, toda esta autentificación está, o toda esta más que autentificación, toda esta certificación está delegada al DNS. Vamos a decirlo así porque es el nombre de la instancia y demás.

En el caso de AT, y esto es una diferencia ya que lo mencionas, todos los mensajes están firmados digitalmente. Bien, ¿qué problema genera esto? Dos cosas. En primer lugar, el protocolo tiene primitivas de criptografía por todos los lados. Todos los servidores tienen, si tú quieres implementar una alternativa, tienes que tener una implementación muy coherente con la implementación principal que es la de Blue Sky.

¿Por qué? Si tú mandas un mensaje que tenga la firma digital calculada de otra forma o tenga uno de los campos del propio mensaje que se incluyen o no se incluyen, pero además no se incluyen todos, los servidores que reciban tus mensajes van a decir que su mensaje está mal formado y por lo tanto lo tiran. Esto para la mudanza de los usuarios es una cosa complicada en el caso de AT.

En lo que tú estabas diciendo para mudar el contenido de una instancia a otra de Mastodon, es fácil y lo puedes resolver de dos formas, o copiándolos los mensajes y cambiándole los identificadores allí donde estén, o simplemente tener un mensaje especial que es una referencia, es decir, todo este contenido es de otra instancia.

Simplemente lo tenemos como un retweet, vamos a decir así. Sí, yo creo que eso sería una de las opciones válidas, pero a mí lo que me preocupa es eso, la gente que según vayan pasando los años, vamos a ver gente que decide que su contenido, como son unas cosas que ya existen, se borre cada X tiempo, perfecto. Pero va a haber gente que sí va a querer mantenerlo, sobre todo porque ActivityPath es mucho más allá del microblogging, la gente va a querer todo lo que haya escrito hace 20 años que

siga visible y que siga por lo menos accesible de alguna forma, ¿no? Y yo creo que si te vas de un servidor a otro porque decides cerrarlo, porque te has quedado sin el dominio, o porque te has enfadado, o porque te han baneado, que ese contenido no desaparezca, ¿sabes? Sí, ese es un gran problema, pero en general la percepción de que el contenido es permanente no es tal en Internet.

Muchos, y lo puedes ver en archive.org, entras y hay miles y miles y miles de cosas que ya no están disponibles ni siquiera. Pero esto es mucho más difícil en AT, ¿por qué? Porque si tú quieres mover el contenido de una cuenta a otra, vas a tener que reafirmar todos y cada uno de los mensajes, porque van a estar en esta docena nueva. Pero no solo la tuya, sino en la federación todas las instancias que vayan a tener referencias a un mensaje tuyo, por ejemplo, van a tener que ser actualizadas.

Y hay otra diferencia sustancial más que lo hace más complicado. Por eso creo que el análisis que hacía este chico Sam Wright del AT tiene sentido por esto primero, porque creo que abusan de la criptografía donde no a lo mejor es necesario, por eso son mensajes públicos a fin de cuentas, no es.

Y luego es que el modelo de federación de Mastodon, por ejemplo, es un modelo pull, es decir, yo escribo en mi instancia algo y las instancias que lo tengan que visualizar, porque tienen seguidores y demás, van a recibir un mensaje de mi instancia con el cambio. Si mi instancia está caída durante ese momento, bueno, pues no se van a generar nuevos mensajes, ¿vale? Pero eso es push, ¿no? O pull.

Push, perdón, sí, correcto, sí, sí. Es que depende de dónde mires. Sí, es push, sí, sí. Cuando mi instancia vuelva, lo que va a ocurrir es que los mensajes que estén pendientes se van a enviar y las instancias que querían mandarme mensajes a mí van a descubrir que ahora ya está otra vez y los van a poder enviar y se va a poder todo eventualmente volver consistente.

En el caso del AT es al revés. Las instancias que reciben son las que tienen que estar preguntando a las originarias todo el rato. Les tienen que hacer pull. Es decir, si tú estás en Mastodon Social y yo estoy en mi instancia, para yo ver tus mensajes voy a tener que estar preguntando a tu instancia, oye, Alex ha escrito algo.

Alex ha escrito algo así todo el rato. ¿Cuál es el problema? Si tu instancia se cae abajo durante un momento, yo voy a preguntar, vale, no hay instancia, Alex ya no existe, venga, salud. No, ya lo has borrado, ya no hay nada que hacer, ¿no? Y cuando vuelva otra vez vas a tener que refederarte, yo voy a tener que descargarme de tu instancia todos los cambios que ha habido y voy a tener que reindexarlos todos otra vez para construir otra vez el mismo estado que tenía toda la federación

en ese momento. Claro, comprenderás que para una federación que tiene cuatro instancias, bueno, pues está bien. Eso es. Para una federación que tiene, ¿cuántos servidores de Mastodon debe haber? Miles ya, ¿no? Sí, sí, sí, decenas de miles. Es imposible de federar a ese nivel, efectivamente.

En mi opinión. Hay que ver hasta dónde llega, pero yo creo que con un modelo así va a ser muy complicado tener un mecanismo que tenga este sistema distribuido una consistencia total. Aquí yo creo que es donde se ve no solo las diferencias de filosofía, sino las diferencias del origen del proyecto. Blue Sky comienza por un equipo de gente dedicadas a las criptomonedas y a las cadenas de bloques y van con ese sistema, van con esa mentalidad a, es decir, replicamos las interacciones de esa cadena de bloques,

pero con mensajes. Esos mensajes, pues con sus imágenes, sus seguimientos, etcétera. En vez de carteras hay perfiles y lo que sea, ¿vale? Perfecto. Te voy a decir muy Ethereum, pero creo que ni siquiera es muy Ethereum, ¿vale? Es otra cosa. Y ActivityPath es que lo hemos visto, es que correo, o sea, correo, correo, correo, es lo más, más, más que tenemos una especie de RSS de doble sentido.

Y para grandes escalas yo creo que tiene completamente mucho más sentido la vía de ActivityPath. Esto no significa que, como dices tú, haya un montón de ideas que los de BlueSky creo que han pillado bien a la primera que se deberían de adaptar, no solo la transferencia de contenido, sino las identificadores, es decir, para poder moverte de servidor.

Es decir, si yo me muevo ya en el dominio, por ejemplo, si yo cambio las máquinas en las que está una instancia de Mastodon, nadie se entera porque está el dominio actuando como puerta. Es ese dominio el que va apuntando a la nueva IP. Ya, pero por ejemplo, Mastodon también tienes que cerrar el círculo porque, por ejemplo, como los filtros de spam son tan básicos, si tú mueves las máquinas, por ejemplo, dices voy a correr mi servidor en Amazon porque estoy en Oscala, lo que sea y tal, muchas veces hay rangos

de IP de proveedores de cloud grandes que se han utilizado a lo mejor para spam o lo que sea, te caes en una IP de esa y dices ¿por qué no funciona? Y es porque realmente no es tan transparente como parece la abstracción, es decir, tu instancia, tus usuarios, tu dirección IP y demás, eso al final tiene un leak a toda la federación.

Va a ser muy complicado eliminarlo, no creo que en AT puedan eliminar eso. Lo que no sé, o sea, yo la conclusión en la que llego es que hay una filosofía detrás de AT que es fundamentalmente diferente a la de Activity Path, que es la consistencia. En Activity Path tú tienes consistencia eventual y en AT lo que tienes es una consistencia fuerte, es decir, todas las máquinas, todas las instancias están siempre más o menos a la misma versión de la red.

No hay cadena de bloques de criptomonedas, es que es literalmente lo que estamos viendo, todo el mundo tiene que tener las mismas hojas de contabilidad para que sepamos realmente qué pagos son los que se han ejecutado. Sí, pero esto no es un sistema de pagos, yo en un sistema de pagos lo entiendo, en un sistema de pagos tú tienes que poder decir dame el balance del banco ahora mismo, ¿no? Bien, entiendo que eso es un requisito de

ese sistema que tiene que ser compliant, como sea. Para una red social ese requisito realmente no existe. Entonces la pregunta es ¿por qué han diseñado el protocolo en base a una consistencia fuerte? Porque al final cuando tú vas a hacer un sistema distribuido que tiene que garantizar una consistencia fuerte, lo que está haciendo un sistema distribuido que es muchísimo, es dos órdenes de magnitud más complejo que uno eventualmente distribuido, consistente.

Entonces eso tiene un coste, hay casos en los que es necesario, ¿vale? Pero claro, son casos en los que tú dices, bueno, es necesario que tenga una consistencia muy fuerte y por lo tanto voy a pagar el coste que tiene en recursos, en diseño, en complejidad, en criptografía que tiene que tener.

Si tú miras la implementación de Mastodon y de ActivityPath, a ver, es una chorrada, es una cola de mensajes. No, no, literal. Y en Aten no puede ser porque si vas a tener una federación que va a tener, si son exitosos, tendrá cientos o miles de servidores. Sí, yo sabes cómo veo Blue Sky, es decir, yo creo que desde el momento en el que lo diseñaron, o sea, la concepción original yo creo que nunca pensaron en lo que decías tú, cientos de miles de servidores.

Yo creo que pensaban algo en blanc docenas de servidores. Algo como más descentralizado, sin ninguna duda, pero es como si solo existieran Gmail, Yahoo, Outlook.com y Tutanota. Es decir, y entre estos cuatro se intercambian y deciden todo y lo que sea. Y podemos hacer las cosas un poco más entre nosotros.

Ciertamente, sus pros y sus ventajas. Por cierto, comentabas que no habían publicado, obviamente, de momento el código fuente de lo que sería la infraestructura del servidor, porque obviamente no hay más servidores, pero se han publicado los códigos fuentes de las aplicaciones y de la versión web. No sé si las has podido echar un ojo. No las he podido ver, pero bueno, está bien que empiecen a publicar porque así, al final para un protocolo de este tipo que no viene de un cuerpo de estándares, necesitas tener

una implementación de referencia para entender cómo. Exacto, porque lo comentamos en anteriores episodios, se están construyendo a la vez ambas cosas y bueno. React Native, yo creo que tendrás opiniones. Creo que muchos de nuestros oyentes tendrán sus opiniones sobre React y React Native y cómo queréis pronunciarlo, etcétera.

Yo las aplicaciones tengo la de iPhone, tengo la de Android y la versión web. No son espectaculares. No quiero decir que sean malas. Son algo lentitas. No sé si esto es por React Native o por la destreza de ellos como desarrolladores de frontend o algo inherente al protocolo. Pero yo creo que el hecho de que tarde 5 segundos en abrir la aplicación o lo que sea en un iPhone 14 o en un Galaxy S23, hay algo ahí que no está funcionando bien de todas formas.

Bueno, son aplicaciones que también están beta y tampoco las irán mejorando. Por eso no quería, pero aquí sí vemos que yo creo que obviamente la edad de Mastodon hemos visto clientes muchísimo más pulidos. Nosotros ahora hemos visto por ejemplo los de Ivory para Mac, que incluso Apple lo ha destacado.

Bueno, pues es una delicia de aplicación. Estamos viendo un renacimiento en este sentido de un montón de diseñadores que ya sabes además los programadores lo que les gusta. Aprenden un nuevo framework, aprenden un no sé qué. Bueno, pues voy a hacer mi aplicación de notas o voy a hacer mi aplicación de lo que sea, de calendario.

Y ahora con Mastodon más que con ActivityPub, están diciendo pues venga, pues me animo, me animo a esto y lo hago. Y estamos viendo clientes muy buenos para Windows, para Linux, para móviles, para todo. Pero especialmente el de Ivory en Mac con su suscripción, etcétera. Delicioso, delicioso, muy recomendado. Y claro, al igual que cuando llegó al iPhone y al iPad, pues trae más usuarios, trae más usuarios porque es literalmente la misma interfaz que tenían y que habían estado acostumbrados durante

10 o 12 años en TweetBot. Así que espero que les vaya muy bien. Sí, ojo con los desarrolladores que quieran hacer aplicaciones de IoT por una diferencia. El API de Mastodon, incluso el API de Twitter eran API REST que se llaman Representational Stage Transfer, es decir, utilizan los verbos de HTTP para hacer cosas y la dirección sería el mensaje, el argumento, o sea, sería la entidad sobre la que tú quieres hacer algo.

La gente de AT ha implementado su propio protocolo de llamadas a procedimientos remotos que no es exactamente REST. Supongo que por debajo tendrán algo como OpenAPI o gRPC o lo que sea para lo que es implementar el transporte. Pero claro, la librería, la API, es una cosa que es un protocolo no propietario pero específico de ellos.

Si quieres hacer una aplicación, porque yo tengo una aplicación que está basada en Python para hacer cosas con Mastodon y con Twitter, borrar mensajes antiguos, historias de esas. Un cronjob que yo tengo ahí que hace cosas. Con REST es muy fácil. Tú le pones una especificación, incluso hay generadores, vas al chat GPT y le dices, mira, tengo este API, dame un programa en Python que me lo implemente con funciones, una clase, lo que tú quieras.

Bueno, ellos han ido por el camino de implementar algo nuevo y entonces, claro, tienen una mezcla. Si tú vas a desarrollar una aplicación con esto, tiene una mezcla de que tienes que utilizar su API para lo que es acceder a la federación y luego toda la parte de autentificación, por ejemplo, está como separada. Es como una amalgamación de cosas que creo que le van a tener, antes de abrir la federación a instancias externas, le van a tener que dar una vuelta a pulir un poco la experiencia

del desarrollador para acceder al feed de la federación. Sí, yo creo que esa es la parte un poco más difícil, porque como dices, la gente que ha desarrollado aplicaciones para Twitter, pasar a hacer ActivityPub no es instantáneo, pero a nivel cognitivo es sencillo entender las diferencias.

Pero aquí, yo lo estaba mirando y escribir algo que, por ejemplo, envíe contenido a tu cuenta en un servidor que ya exista, eso es fácil. El resto ya no es tan fácil, por decirlo así, yo creo. Obviamente, todo esto que estamos comentando lo vamos a dejar en las notas del episodio. No os preocupéis si hay alguna palabra que no hayáis entendido o queráis indagar vosotros más los oyentes una vez que dejéis el episodio.

Bueno, de esta pelea, por cierto, de colegio ¿nos quedó algo por contar? No, yo la conclusión que tengo es que hay unas diferencias fundamentales de filosofía en cómo correr una federación. No son necesariamente una mejor que la otra. Tienen distintas propiedades y dependiendo del problema yo aplicaría una a la otra.

Personalmente, creo que para una red social hacer un sistema Push como es Mastodon me parece que va a escalar un poco mejor. Incluso el protocolo de ActivityPub es muy derboso, muy tal, no tiene mucha gracia. En ese sentido, filosóficamente parece que es mejor. Y creo que donde sí que está mejor pensado es con los identificadores distribuidos de AT.

Creo que es una idea que está bien para esto. Sí, a mí no me extrañaría mucho que eso fuera poco a poco trasladándose a ActivityPub de alguna manera o de alguna otra cosa. Porque además creo que se están moviendo un par de grupos nuevos en el V3C al respecto de identidades. No sé si esto se va a dirigir para aquí o no.

Pero bueno, el tema de las identidades está cambiando mucho en Internet. Un día tenemos que hablar un episodio de las DNS y todo esto. Porque ahora con todos los nuevos dominios o los nuevos terminaciones de dominio, los dominios de top level, etcétera, más allá de las polémicas, que a mí me parecen un poco absurdas, de los.zip, etcétera, como dominio, etcétera.

Pues sí, es cierto que lo que es la identidad, que no deja de ser los dominios un sistema de identidades el más tradicional para todos, pues yo creo que es algo que tenemos mucha experiencia y que no es difícil de hacer. ¿Quieres que para acabar comentemos lo de los algoritmos personalizados de BlueSky? Porque creo que ha sido una de las cosas más interesantes de estos últimos días. Bueno, esto está guay, ¿eh? Esto está bien, sí, está bien.

Yo he estado usando el BlueSky, no he escrito ningún mensaje en BlueSky, pero tengo ya como 40 seguidores y me he dado cuenta que tienen como una cosa en la aplicación que es como una antena en la que puedes generar diferentes feeds. Es decir, puedes escoger feeds que tú no haces manualmente sino que digamos que instalas como un algoritmo que te cura tu feed y te proporciona diferentes priorizaciones para tus mensajes.

Hay unos por defecto que es lo de las personas que sigues, de las personas que no están, lo que sea. El caso es que se supone que esto está abierto y tú puedes crear algoritmos con diferentes propiedades. Yo qué sé, podrías crear un algoritmo que sea yo solo quiero ver tweets de coches, ¿no? Y con algún tipo de inteligencia a lo mejor lo filtra o lo que sea.

No sé exactamente cómo se escribe uno de estos algoritmos. Pues te lo cuento. Dale. Te lo cuento porque la verdad que me ha fascinado esto. Es decir, esto que yo creo que es una idea ganadora y una idea que hay algunas cosas que quizás yo desde mi ignorancia no las hubiera implementado así, pero que está completamente abierto y tiene múltiples futuros muy diferentes y que sería algo increíble para que a lo mejor lo implementaran, cómo te diría yo, las plataformas digitales tradicionales.

Es decir, un YouTube, imagínate, un YouTube, déjame a mí distribuir diferentes tipos como de filtros. Aquí hablan de algoritmos personalizados, pero cuando decimos feeds, es decir, técnicamente es lo mismo. Es decir, un método, unas programaciones simples, una única función que entre un churro y te lo ordene de una forma o de otra, ¿no? Entonces, ahora os explicaré qué tipos hay, pero básicamente el qué son, pues tenemos

servicios que se están ejecutando en la nube. Hablabas tú antes de los cronjobs, es decir, esto es una máquina que constantemente está autenticada y está recibiendo ese contenido, todo el contenido que va por el AT Proto, ¿vale? ¿Qué tipo de contenido? Lo puedes especificar, digamos, ¿cuál es lo que va a pedir? Pues todo el contenido o el contenido de específicos identificadores de determinados usuarios o búsquedas, que en cierto sentido

que es como una reducción, etcétera. Pero sí son independientes de cada servidor y cada instancia, ¿vale? Pone que para publicarlos, es decir, para decirle al servidor que existe y que se lo pueda ofrecer a los servidores, ahí es donde no me queda claro muy bien cuál es el proceso, porque aunque está todo técnicamente especificado, hablan de repositorios para que todos entiendan que sea código abierto de alguna forma, es decir, que hay alguna

forma de revisarlos, ¿vale? Pero para el usuario es lo que decías tú, hay una sección en la que tú puedes elegir por defecto, cuando tú te registras tienes los dos algoritmos añadidos, es decir, dame todo el contenido de forma cronológica de la gente a la que te digo, ¡pum! No hay más.

El segundo, una especie de lo mejor de las últimas horas, similar a los algoritmos de explorar de Instagram, al For You de TikTok y todas estas historias, ¿vale? Aquí, claro, pues en esta lista puedes elegir un montón, los que tú quieras, puedes incluso eliminar los que vienen de serie, puedes reordenarlos para que uno sea el principal, que cuando abras la aplicación, etcétera, y van mucho más allá de lo que son las listas de Twitter, es decir, tu Twitter tendrías tus listitas, aquí va más allá.

¿Por qué digo que más allá? Por ejemplo, porque como no es algo que haga tu aplicación, ¿vale? Ni, bueno, técnicamente, las listas las gestiona el servidor de Twitter, ¿no? Porque... Las listas las gestiona el servidor de Twitter, las membresías, pero luego lo que es la curación del...

o sea, el mostrar el stream de la lista lo hace el cliente. Aquí necesitas ese servidor que te haga ese filtrado, es decir, que te pase las patatas con su arena según están recogidas y te de las patatas ya fritas, listas para comer, en cierto sentido, para que las pueda ver el usuario. O todos los usuarios que estén usando ese algoritmo, con lo cual es muy complicado y ojito a todos estos desarrolladores, ¿cómo van? Eso lo llaman hidratar el feed. Me ha gustado mucho ese verbo o esa metáfora, ¿no? De la hidratación.

Tipos de algoritmos. Algoritmos de popularidad, por ejemplo, es decir, memes graciosos o cosas que tengan más de X retweets o un ratio entre retweets y likes o lo que sea. Muy parecido al 4U, muy parecido a las múltiples mediciones que puede hacer TikTok para evaluar si un contenido puede ser popular.

Luego, personas específicas, como podemos decir, yo a lo mejor quiero seguir a Ramón, quiero seguir la cuenta de Google, la cuenta de Pepito y la de Juanita. Literalmente, ese es mi algoritmo personalizado. No tiene ningún misterio. Y luego tienes lo que ellos llaman temáticos. Luego todo esto se puede combinar, pero los temáticos es cojo el chorro, lo que le llaman la gran manguera de datos o algún tipo de búsquedas y sobre esos resultados crudos que me devuelven, implemento yo mis propios filtros, mis propios algoritmos, lo

que sea. Por ejemplo, un contenido en el que no haya fútbol. Pues tú imagínate. Es complicado. No solo es. Bueno, si aparece la palabra fútbol, balón, gol, portería, delantero, portero, ese tweet no llega o ese mensaje no llega, sino que tienes que evitarte otro tipo de contenidos.

Pues las fotografías, los horarios, esa persona que ha estado comentando los últimos ratos para evitar spoilers de series. Podría ser algo interesante todo este sistema, pero yo creo que aquí hay mucha, mucha, mucha posibilidad no solo para los usuarios, sino para que los desarrolladores ganen dinero. Me explico. No hay nada aquí que no diga que esto en el futuro no pueda estar monetizado por parte del desarrollador.

Al final, el desarrollador no tiene que mantener ese proceso ejecutándose constantemente, que depende de los servidores. Es decir, es como un intermediario que te envía y te prepara los datos para ti. En el futuro no solo podrá venir del servidor único que hay de Blue Sky a día de hoy, sino que puede venir de varios.

Quien te dice que incluso no te puedes montar un Google Discover o un sistema de noticias. Puede ser algo muy chulo, la verdad. Y tienes sobre Blue Sky, o mejor dicho, sobre el AT Proto, un Google Discover. Sí, además ese es el motivo yo creo por el que han apostado por la consistencia más fuerte para poder hacer todas estas cosas mejor.

Específicamente el tema de la monetización. Creo que la monetización, tú vas a tener que tener medidas de, por ejemplo, si quieres poner mensajes de anuncios donde tú pagues, o si quieres tener un feed de estos, por ejemplo, donde tú puedas tener una suscripción, a lo mejor, o lo que sea. Ahí sí que la consistencia eventual a lo mejor no funciona muy bien.

Exacto. Y, por ejemplo, en este tipo de desarrolladores, imagínate, tienes un algoritmo personalizado de estos muy popular. Algo que se dedique a criptomonedas. Y no hace falta tener y seguir a todas esas personas, sino que simplemente pues te da como lo más importante del día. Oye, chulo, interesante, perfecto. Pero claro, hay muchos usuarios, tienes que servir mucho, y dices, demasiado coste.

Pues no hay nada que te evite de momento, por ejemplo, que tú insertes un mensaje artificialmente que te interese a ti o que alguien te pague por insertar. Es decir, es una función, es un if dentro de ese algoritmo. Y eso me parece muy curioso, porque ahí hay un montón de cosas.

Esto es uno de los grandes elementos que ahora mismo me gustaría ver sobre Activity Path. Es decir, no sé si a nivel de instancia, yo creo que mejor sería a nivel de usuario. Es decir, lo que me llegue, orgánizamelo de esta forma. Creo que el concepto de que sean portables como son los de aquí en el AT sería interesante. Sería interesante porque además si puedes revisar el código, mucha gente no lo hará, pero quien quiera pues lo puede tener disponible.

Además serían, yo lo veo como plug-ins, que tú puedes instalar en tu instancia a lo mejor. Y podrían ser no solo feeds, porque esto es un, cómo decirlo, un filtro para la información que recibes, pero podría ser también para generar información. Por ejemplo, dame resúmenes de prensa por las mañanas. Dame el Me Journey. Puedes ponerlo en el Activity Path.

Te mandas un mensaje privado y te devuelve una imagen. Cosas así. Claro. Sí, sí, sí. O sea, si lo generalizas, puedes tener una plataforma de bots bastante interesante. Eso es. Yo creo que en todas estas partes de automatizaciones, yo creo que es donde hay muchísimo futuro para todo esto. Las personas que estéis más acostumbradas a los clientes de correo, estos todopoderosos que tienen no solo el calendario, sino las agendas y todo esto súper implementado.

Esto lo vais a ver como algo increíblemente necesario. Pero algunas personas simplemente quieren la lista de los últimos correos y ya está. Pero bueno, muchísimas gracias a todos por estar con nosotros. Otra semana más en Don Tomás. Yo creo que hemos explicado muchísimas cosas.

Sí, la verdad es que todavía queda mucha tela que cortar aquí. Es que esto en general hay que seguir como evoluciona. Luego habría que ver también cosas como protocolos más básicos que dependen mucho de esto. Pero sí, sí, la verdad es que está muy bien todos estos todos estos comentarios y próxima semana más.

Eso es. Comentaremos elementos de Noster, que creo que es uno de los temas que se nos va quedando en el tintero. Lo de las DNS. Cambios que está habiendo en Reddit, que podría venir por ahí otro nuevo tirón hacia Activity Pad principalmente. Y diferentes ideas para servidores que están surgiendo, sobre todo para, como decía Ramón, reducir el impacto, reducir el consumo tanto de CPU como de energía de esos servidores.

Con esto nos despedimos. Muchísimas gracias y hasta el próximo episodio de Don Tomás. Adiós, Don Alex.