Don Tomás #1
La Edad de la Federación: un Viaje a través de ActivityPub
Orígenes y evolución de ActivityPub, el protocolo que ha cambiado el panorama de la web. Desde sus predecesores hasta su adopción generalizada.
00:00
/36:35
Nos adentramos en el apasionante mundo de los protocolos descentralizados, con un viaje a través del tiempo, explorando los orígenes y la evolución de ActivityPub, el protocolo de federación que ha cambiado el panorama de la web.
Desde sus inicios modestos hasta su adopción generalizada, explicamos los desafíos superados, los logros alcanzados y cómo este protocolo ha impactado la forma en que nos comunicamos e interactuamos en la era digital. Una fascinante inmersión en la historia de Internet, la era de la federación y el papel crucial que ActivityPub ha jugado en este viaje.
Nuestros perfiles en Mastodon:
Enlaces que comentamos en el episodio:
- Evan Prodromou - Wikipedia
- Open Micro Blogging
- OpenMicroBlogging
- StatusNet - Crunchbase Company Profile & Funding
- shashi/StatusNet: StatusNet, the Free Software micro-blogging platform.
- GNU Social - Wikipedia, la enciclopedia libre
- OStatus - Wikipedia, la enciclopedia libre
- friendica – A Decentralized Social Network
- Diaspora* - Wikipedia, la enciclopedia libre
- eschnou/activitypump: Social server with an ActivityStreams API
- ActivityPub
- pump.io
- Pump.io - Wikipedia
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
Transcripción
Bienvenidos al primer episodio de Don Tomás. Mi nombre es Alex Barredo, me conoceréis de Mixio, el podcast diario de tecnología, y conmigo está Ramón Medrano. ¿Qué tal estás, Ramón? Hola, buenas. Pues estoy bastante bien. Esperando, no, deseando más bien grabar el primer episodio.
A ver qué tal lo sale. ¿Cómo está el tiempo por ahí, por Suiza? ¿Estáis pasando calor ya? ¡Qué va! Está lloviendo. Ha sido el peor invierno porque no ha nevado, entonces no hemos podido ir a la montaña. Y la peor primavera porque no ha parado de llover, entonces tampoco hemos podido hacer nada, así que estamos aquí mirando por la ventana. Lo que se suele conocer como el infierno suizo de toda la vida.
En fin, bueno, el primer episodio de Don Tomás, de este podcast con este nombre tan particular, que teníamos tanta ilusión por comenzar, creo que tenía que ir de mastodón y creo que es lo que está catapultando ahora la conversación en general sobre la descentralización, sobre este tipo de cambio o posible tendencia, no sabemos lo que va a durar o si va a ser algo permanente, a nivel de internet en general, ¿verdad? Sí, a ver, lo hemos visto con mastodón como
la primera, digamos, gran éxodo de una plataforma centralizada a una... Yo no quiero decir que mastodón es una plataforma porque al fin y al cabo es como una implementación de un protocolo, no? Es la más... efectivamente hay un sesgo grande a que la grandísima mayoría de los clientes han sido mastodón, pero creo que se va a ver más también porque siempre cuando se habla de transformación digital y demás, ahora que está mucho en los medios y tal, muchas veces se añade
a la colectividad esta de la soberanía digital, ¿no? Y una de las formas de conseguirlo es utilizando protocolos que sean distribuidos de por sí, entonces no tienes al final un árbitro central, ¿no? En este caso es nuestro amigo Elon para Twitter, diciendo lo que se puede hacer o cómo se puede moderar o qué algoritmos hay que utilizar, ¿no? Eso es, y claro, todos sabemos que a día de hoy mastodón está basado en este palabra que a algunos os suena, a otros no, que
es ActivityPub, y vamos a comentar, pues eso, precisamente dónde están las fronteras, dónde empieza ActivityPub, dónde es mastodón como software, como servidor, todos estos conceptos que creo que siguen sin estar nada claros para muchísimas personas, porque claro, nos hemos tirado los últimos 15-20 años en plataformas completamente centralizadas, como cuál es tu cuenta de Instagram, esta es Poon, ¿no? A pesar de que, pues yo creo que tanto Ramón, tú como yo, como muchísimos de
nuestros oyentes, hemos crecido en la plataforma descentralizada por Autonomasia, que es el correo electrónico, y yo creo que mastodón tiene mucho más de correo electrónico, cuando hablas de ActivityPub y todas estas tecnologías, que de Twitter, a pesar de que la apariencia inicial es un poco, es un poco lo de Twitter, y esto es lo curioso, porque mastodón no siempre estuvo utilizando ActivityPub, ¿verdad? No, no, sí, o sea, el histórico de mastodón, hasta que llegamos a
mastodón que hay hoy en día, tiene más de una década de historia, o sea, son plataformas de microblogging, que eran, cómo decir, algunos open source, algunos no, tenían protocolos, vamos a decir, homegrown, de esto que cada una tiene una versión diferente de lo mismo, porque al final es similar, pero creo que lo que dices de correo electrónico es muy acertado, porque cuando el protocolo lo estandariza, el W3C, que es el Web Consortium, introduce conceptos como un inbox,
si es verdad que el concepto al paralelismo con el correo electrónico es claro, y lo demás está la identidad de los usuarios dentro de la red, es muy parecida del correo electrónico, porque tú tienes un nombre de usuario en un servidor. Exacto. No es una identidad global como pueden ser tus nombres de usuarios dentro de Instagram.
Exacto. Yo creo que esa es un poco la gran diferencia, y hablamos de que no siempre todo ha sido código abierto, y a mí esto me fascina porque yo creo que hay muchas personas que piensan que esto es una cosa de hippies y cosas así, y no necesariamente, ¿vale? Si es cierto que son elementos que han sido catapultados y que ha habido mucho interés tanto en Europa como en Estados Unidos, principalmente, ¿vale? Pero yo creo que son fenómenos completamente globales.
En concreto, origen, origen, origen de todo, yo creo que podíamos hablar de un montón de cosas de historia, porque ya tenemos, como decías tú, pues más de una década, yo te diría, de este tipo de una persona, se le ocurre un concepto, y luego vamos a ver si lo podemos estandarizar, y luego se aburre, y luego deja de no sé qué, y luego tiene éxito, o no tiene éxito, o queda todo abandonado.
Hay un montón de conceptos que hablabas tú antes, como lo del inbox, este buzón de entrada de datos que propone y que ofrece, y sobre el que funciona ActivityPub, que yo creo que deberíamos de explicarlos al principio, ¿no? Entonces, cuéntame un poco. A ver, el protocolo, al final lo que tienes son los objetos, tienes actores y actividades, ¿no? Al final esto siempre se puede hacer un paralelismo con el email, para que sea más fácil de entender.
Los objetos son los elementos que se transportan. Serían los emails, pues en este caso lo que pasa es que hay varios tipos de objetos, porque el ActivityPub, nosotros lo vemos mucho en Mastodon, que es una red de texto, pero podría ser una red de fotografías, por ejemplo. De hecho, hay aplicaciones que serían como una mímica de Instagram en la que tú...
Sí, PixelFed, y está consiguiendo bastante tráfico. Tenemos encima de ActivityPub PeerTube, que es algo relativamente similar, o que intenta conseguir algunos de los conceptos capitaneados por YouTube, etcétera. Pero sí, yo creo que va mucho más allá del texto, como dices tú. PeerTube, por ejemplo, tiene cosas de vídeo y tal. Entonces, bueno, todos esos serían las cosas que se pueden transmitir.
Los actores son lo que en email sería el destinatario y el receptor, sería quién es el autor de las cosas. Y luego las actividades, como si le añadieras un API al correo electrónico para realizar acciones con diferentes semánticas. No solo el transportar objetos de un destinatario a otro, sino que tú puedes actualizar un mensaje, por ejemplo, que en correo electrónico lo único que se hace sería enviar uno nuevo.
Y puedes borrar, puedes bloquear, puedes seguir. Y no solo sobre los objetos, pero también sobre los actores. Tú, un actor, como puede ser otro usuario en otro servidor, lo puedes bloquear. Eso está muy chulo, porque hay elementos del ActivityPub que nos recuerdan al correo electrónico y hay otros que me parecen como el RSS.
Pero en un único sentido, es decir, tú recibes información, tú también emites información. Es decir, todas tus acciones, como comentabas tú, tus actividades de ti como actor, sobre los objetos que se van publicando y que están presentes en tu servidor o federados, etcétera, todo tu flujo de acciones que haces tú localmente las emites para que todas las personas que te siguen o que están suscritos a ti las vayan recibiendo.
Con lo cual, si tú le das me gusta a un objeto, que puede ser un artículo o lo que sea, la otra persona tiene que recibir en algún momento esa notificación y su servidor decirle, oye, Pepito le ha dado me gusta a este objeto. Y una cosa buena es que las actividades las puedes expandir. Cada uno puede crear y puede personalizar y puede decidir qué es lo que significa y qué es lo que hace e incluso añadir un poco las suyas propias.
En esto me recuerda un poco también al RSS y a los namespaces del XML, ¿verdad? Sí, sí, es un protocolo extendible. Está bien definido porque el estándar que publicó el W3C serían los fundamentos básicos y luego la gente puede establecer sus extensiones dentro del estándar sin tener que sacar versiones posteriores. Podrías ver, por ejemplo, un servidor de Mastodon o de Gear2, por ejemplo, que se quiera financiar con anuncio, posiblemente podrías añadir extensiones a las actividades que sería este.
Este es un mensaje especial, por ejemplo, entonces no es algo que provenga de algún usuario, sino un servidor. O podrías ver, por ejemplo, debería ser posible hacer con ActivityPub un sistema como el de Spaces que tiene Twitter para el audio, transmitiendo, por ejemplo, fragmentos de audio del Space que se esté transmitiendo, añadiendo, por ejemplo, campos de prioridad.
Eso como es algo en tiempo real, si estás haciendo un podcast o lo que sea, pues quieres que vaya en la sitbox que coja la prioridad y entre a la arriba de la cola, por ejemplo, es decir, extensiones. Por ejemplo, PeerTube, cuando alojas un vídeo, consume muchísimo y no todo el mundo puede pretender que su instancia realmente...
porque aquí cuando hablamos de instancia técnicamente nos referimos al servidor, es decir, una cosa que esté en algún sitio haciendo esa transferencia de datos, enviando y recibiendo. Igual que para un correo electrónico necesitas el cliente y el servidor que lo gestione, pues aquí tenemos eso. No sé muy bien por qué comenzamos a hablar de instancias hace años, pero yo creo que ya es un término completamente aceptado.
Y te decía lo de PeerTube, porque PeerTube, además de que te puedas transmitir el vídeo por HTTP normal, también puedes utilizar y ofrecen WebTorrent, por ejemplo, para simplemente que el vídeo entre dentro de este enjambre, dentro del protocolo BitTorrent, uno de los mayores casos de éxito de la descentralización de la historia de internet, sin ninguna duda, y que la instancia que lo aloja simplemente actúe como uno más de las semillas de ese contenido, con lo cual se ahorra muchísimo tráfico y muchísimo
ancho de banda. Sí, sí, sí, eso está ahí. Luego, otra de las cosas que hay que decir es que en el paralelismo que estamos teniendo con el email, los problemas que tiene el email históricamente también los mantiene ActivityPath. Si miramos cosas como la identidad, es una identidad en la que tú dependes del servidor en el que tú estés.
Eso es. Yo, por ejemplo, utilizo Gmail y mi identidad en lo que sería mi cuenta de correo es en gmail.com. Si uno utiliza su propio dominio, pues su identidad es el centro de su dominio. Es decir, no hay notificadores globales, lo cual tiene las ventajas porque maximiza la descentralización, pero para la gestión de la identidad es más complejo.
ActivityPath tiene un sistema, yo lo he probado un par de veces, que me parece que está bastante bien ejecutado para cambiar de identidad. Es decir, no puedes transferirla cuando cambias de un servidor a otro o de una instancia a otra, pero al menos sí que puedes transferir tu estado, que sería la gente que te sigue. Creo que no transmite los estados que tú has escrito, es decir, empiezas desde cero.
Cuando yo lo he hecho, no me ha movido el contenido que yo cree. Es lo que dices tú, te mueve los suscriptores, por decirlo así. Es como una notificación de ahora soy otro alter ego. Pero bueno, es bastante mejor que, por ejemplo, la migración de datos existente entre Facebook y Twitter, por ejemplo, que es imposible. Exacto, que es inexistente.
Esa portabilidad del grafo social o del gráfico social. Nunca he sabido muy bien cómo traducirlo al español. Parecía todo muy bonito en las primeras épocas de la web 2.0 y al final todo el mundo se cerró y todo el mundo se quería quedar con lo con lo suyo. Sí, bueno, lo ves en cosas como, por ejemplo, varias veces en Twitter hemos visto desde octubre hasta ahora el acapanamiento del tráfico, digamos, en el sentido de que el incentivo de la red centralizada es que tú estés en su plataforma y no salgas a otra.
Entonces lo hemos visto con el caso de Chubstack, los enlaces a otras redes sociales, como el propio Mastodon, me parece que ocurrió que lo marcaba como un enlace dañino. Estos incentivos, claro, al ser una red distribuida, no existen. Existen otros incentivos diferentes. Eso es, eso es decir, no todo es bonito, no todo es precioso, porque uno de los graves problemas que tienen estos protocolos o estos sistemas abiertos en el que cada uno puede conectarse, etcétera, por ejemplo, como hemos
visto en el correo electrónico, es el spam. No hemos visto grandes casos de, madre mía, por qué estamos todos en este servidor, en esta instancia, recibiendo estas notificaciones, pero es básicamente porque yo tengo un buzón de entrada y cualquiera me puede enviar las cosas, al igual que en un correo electrónico, ¿no? Sí, el spam es el gran problema que ha tenido el correo electrónico y es el gran problema que va a tener ActivityPub como red cuando escale.
Sinceramente. En el correo electrónico, pues hemos visto que hay muchos sistemas de firmas digitales, de Mark, tenemos cosas como una cosa que ha salido ahora que se llama Bimi para proteger las marcas, etcétera, etcétera. Es todo firmas digitales y autenticación del origen del contenido, ¿no? Más todo en eso todavía no existe.
Creo que quien le está dando una buena pensada a esto es la gente de BlueSky con el protocolo Adds. Por ejemplo, ellos lo que hacen es, hay una diferencia de concepto en el sentido de que en ActivityPub, cuando un servidor te deja algo en tu inbox, tan pronto como provenga de ese servidor, pues está autentificado. Si es spam o lo que sea, pues ya está, ¿no? Tú puedes crear una instancia de Mastodon, por ejemplo, que se debe enviar spam a todos los inboxes y el pritito, como viene de una instancia de tag,
entonces la única opción que tienes ahí de moderación es decir, bueno, pues, defederamos esta instancia, ¿no? Entonces se añade una lista negra, digamos, y cualquier mensaje que venga de esa instancia, pues consideramos que es abusivo, spam o lo que fuera.
Ha pasado con servidores japoneses, por ejemplo, que tienen otra idiosincrasia. Y en el caso de Adds, lo que se hace es, se autentifica cada objeto que se transmite, mientras haya sido creado por el actor que dice ser el creador. Eso se firma digitalmente. Entonces tú ya sabes que eso ha sido creado por una persona, un bot que está diciendo quién dice ser, ¿no? Pero al menos no es una instancia, por ejemplo, que está generando mensajes. Ahora que estamos aprendiendo más sobre este protocolo AT o el protocolo ADD que
está utilizando BlueSky, tienen conceptos muy diferentes con respecto a ActivityPath. Se pueden construir puentes para unir un protocolo con otro, pero me parecen súper interesantes las diferencias y los conceptos detrás. Los conceptos, digamos, que han llegado a otras conclusiones muy diferentes a las que construyeron la arquitectura de ActivityPath. Y eso lo tenemos que tratar en algún episodio.
Yo no sé si tú ya tienes tu cuentita de BlueSky. Estoy en el waiting list. Ahora a ver si te puedo dar una invitación porque está goloso, me está gustando mucho. Pero ahora mismo, mi niña bonita es Mastodon. Entonces, yo creo que han quedado claros los conceptos, el por qué es diferente, el por qué es tan ilusionante, el por qué creo que puede tener un buen tirón, no con todo el mundo, eso sí es cierto.
Hemos visto pros y contras, pero vamos a hablar del origen, vamos a hablar de los datos históricos, vamos a hablar de todo esto porque vamos a decir un montón de palabras y un montón de nombres que a muchos de los que hayan, no solo los lectores de Mixio, sino la gente que haya estado dentro del mundillo, programadores, etcétera, gente que simplemente no haya vivido debajo de una roca durante los últimos 20 años, va a decir, ¡hostia, es verdad! ¿Qué pasó con esta gente? Y una de esas primeras palabras es la cónica.
¿Tú te acuerdas? ¿Tú te apuntaste a la cónica? Sí, sí. Yo no me acuerdo si me apunté o no, pero nada más que lo he estado revisando las notas y he visto la cónica y he tenido esa misma sensación de, ¡hostia, es verdad! Pero si eso, yo me acuerdo de darme de alta en Gemayl con las invitaciones, aquellas que había en su época, y tener aquel tema por entonces, sí, sí.
Y lo que pasa es que aquello era, creo que era open source, pero el protocolo era propio, o sea, era una cosa completamente ad hoc. Era, vamos a ver, es que esto lo creo Evan Prodomou o algo así, no me acuerdo de cómo se pronuncia, no me lo preguntéis. Estaba en San Francisco este señor que es bastante veterano, bueno yo creo que ya era veterano entonces, en 2007-2008 cuando empezó con esto, y estaba construyendo por una parte la plataforma, es decir, el software, lo que tú instalas y te
sirve para comunicarse, y por otra parte estaba construyendo Open Microblogging, inspirado también en Twitter, a la vez. Es decir, mira, y luego coge, bueno, esta librería es la plataforma, esta librería es el protocolo, y quedó un poco, yo no diría chapuza, pero era lo que era, ¿vale? Orgánico, se dice.
Sobre todo es que era muy simple, era muy sencillito, solo quería imitar lo que era Twitter en aquel momento, que era básicamente él, estoy en la cafetería comiéndome un donut. Bueno, pero Twitter era así al principio, hay que recordar que Twitter cuando nació, todo el concepto de retuits y todas estas cosas no existían, fueron las aplicaciones quienes inventaron toda esta nomenclatura, los hashtags, por ejemplo, era un diseñador que apareció por
ahí, lo inventó y tal. En 2008, Twitter era una lista de cadenas de texto, o sea, no había más. Y muchos lo utilizaban en el móvil a través de SMS. Es que era una locura, es que era una locura, todos los que entraron en Twitter en una gran oleada esta de 2012, 2003, etcétera, conocieron otro Twitter muy diferente. Bueno, hay que contextualizar, el iPhone no se había lanzado cuando aparece la cónica y cuando
aparece Twitter por primera vez. Tú estabas con tu Nokia N73, como tenía yo, mandando SMS a un endpoint de Twitter, que te cobraba 1,50€ por cada mensaje para publicar tú, que pues no sé, que ibas a tomar algo. Y ya está, y no tenía mucho más, eran tiempos más sencillos, ¿verdad amigo? Mucho más elegante todo. Entonces, una vez que tenía la cónica, digamos que lo que se creó fue la instancia en la que
yo creo que más éxito tuvo, que era Stoica, que era estoi.ca. Era como muy griego todo esto, no muy griego clásico. Y luego eso lo cambiaron el nombre, porque decían esto Stoica tal. Yo creo que como Stoica, no sé si duró días o semanas. Y luego ya, y esta es la palabra que a muchos os va a sonar, que es Identica. Sí, esa es la que yo recuerdo haber usado yo creo. Y esa era una instancia, es decir, un servidor en el que cada uno, digamos,
podía crearse y tener su propio Twitter, o podías descargártelo y montártelo por tu cuenta, ¿no? Y federarte a través de este Open Microblogging, que era, pues eso, como dices tú, muy orgánico. Luego Evan siguió acelerando por ahí, ya sabéis estas cosas. Como el chiste de XKCD, el mítico cómic de, hay trece estándares, necesitamos una cosa para solucionarlo. Resultado, ahora hay catorce estándares.
Esto es la historia que os vamos a contar. Sí, pero eso es todo, eh, o sea, es una máxima de la naturaleza y de la tecnología, es increíble. Bueno, Evan creó una empresa para mantener todo esto, que era Control Yourself. La empresa pasó a llamarse StatusNet, otro nombre que seguro que está en vuestros neocortex, y cambió el nombre, que era el software, es decir, la cónica, pasó a llamarse StatusNet, y creó Status.net, que era la instancia donde la gente podía tener sus microblogs.
Entonces, durante un tiempo, existía Identity.k, Status.net, era un poco un jaleo. Luego la gente se preguntaba, ¿por qué esto no ha funcionado, no sé qué? Macho, Evan, que por la mañana decías una cosa, y por la tarde decías otra cosa. Bueno, mira, el mismo paisano haciendo todas las historias. Sí, ya había bastantes más personas.
No tengo los nombres y no los recuerdo, pero sí que Evan, que está en el tema de la ActivityPub, es decir, que ahí sigue, está presente ahí, todas estas personas. Igual que cuando se decide los estándares HTML y todas estas... y las estandarizaciones RFC y todas estas cosas, son gente, no diría en la sombra, porque todo lo puedes ver públicamente, etcétera, pero gente relativamente anónima, gente que sabe mucho, que está trabajando, en principio, en hacer un futuro mejor.
Es cierto, pues que no lo clavaron a la primera, sin ninguna duda. Es que es muy complicado, porque a la vez que estamos viendo esto, Twitter está evolucionando, añadiendo muchos fichos, muchas cosas, y luego el Product Market Fit, este que le gusta mucho llamar a la gente, iba cambiando, porque hay cosas que en Twitter funcionaban muy bien, lo de Vine, por ejemplo, para los vídeos y tal, y otras que no.
Entonces, claro, a la vez que la gente iba descubriendo lo que era el social media y todas estas cosas, y buscando que funcionara, ellos estaban desarrollando una plataforma, que los requisitos de lo que la gente iba utilizando estaban variando cada seis meses. Y lo mismo le pasaba a Twitter. ¿Queremos subir imágenes a Twitter? No se puede.
El Tweet Image que había por entonces. El Tweet Pic, el no sé cuándo, un montón de cosas. ¿Queremos poder programar contenido para que se publique en Twitter? No se puede. Bueno, voy a montármelo por mi cuenta. Y todas estas cosas, Twitter las ha ido añadiendo. Entonces, cuando tienes un equipo de ingenieros, pues poco a poco lo vas a poder hacer, y lo vas a ir pudiendo hacer.
Sí es cierto que Twitter, tradicionalmente, ha sido una empresa que ha ejecutado muy lento, ¿verdad? Más que ejecutado, es una empresa que ha reaccionado muy lento. Ha empezado a hacer cosas muy lentas. En ejecución luego, cuando saben lo que quieren hacer, pues bueno, más o menos lo hacen. Pero sí es verdad que otra, una propiedad bonita de Twitter que tuvo durante esos años, es que era descentralizado de una forma.
Es que ellos tenían como el backbone de la red. Nosotros vamos a controlar la identidad, tú eras el que tenía la cuenta de Twitter, y vamos a controlar el feed de las cosas. Pero luego, muchas de las cosas que tú publicabas, pasaban en servicios externos.
Publicabas en Tweet Pic, publicabas en los mapas, en otra historia donde estabas, en el Swarm, que ahora se llama Swarm, se llamaba el Foursquare, te daban los check-ins. Luego tenías cosas como los vídeos en Vine o los predecesores, los memes venían de otro lado. Twitter, Instagram nació mucho gracias a Twitter también, porque muchas de las imágenes se publicaban directamente en Twitter, y la podías ver, la imagen subía, no tenías que ir a Instagram.
No era descentralizado en el mismo sentido de lo que era ActivityPad, pero sí que tenía como otra dimensión de que muchos de los componentes que había estaban ejecutados por otras empresas u otros usuarios fuera de la red. Y sobre todo por otras interfaces, es decir, tú podías entrar a Twitter desde donde quisieras. Hubo mucha experimentación con interfaces de usuario.
Esto de historias de abuelo cebolleta lo tenemos que tomar a fondo en otro episodio, porque sí es cierto que lo que echamos mucho de menos es ese origen. Mira, vamos a hacer esta cosa mínima, tampoco nos vamos a convertir en un gigante tecnológico, pero va a ser muy importante. Al final decidieron eso que no, y quedó para un universo paralelo. Entonces, OpenMicroBlogging y nuestro amigo Evan volvieron a mutar como los X-Men y se convirtieron en O-Status.
De O-Status también te acordarás tú. Sí, sí, O-Status es la primera vez que se intenta buscar un consenso. Es la primera vez que el W3C se ve como involucrado, en el sentido de decir, esto parece que puede ser útil, parece que estaría bien que haya una federación. Pero claro, para que haya una federación tiene que haber un lenguazo, un protocolo, que podamos comunicarlo. Y yo sí recuerdo que lo anunciaron con una cosa de, bueno, hemos hecho el protocolo definitivo, tal, no sé qué, y no tuvo tracción ninguna.
No, pero es un poco siempre lo del ciclo este, de la pescadilla que se mueve la cola. No hay usuarios porque la plataforma y el protocolo tampoco permiten hacer mucho, con lo cual la gente no se conecta. Y es justo, yo creo, lo que no solo inicia este programa, sino que inicia toda la gran adopción de Mastodon, que es un hecho que ha forzado esa parte de la migración.
Y los efectos de red han empezado a funcionar, que no había ocurrido con StatusNet, no había ocurrido con Identica, no había ocurrido con OStatus, ni con todas estas tanto plataformas como protocolos. Aquí entran ya Webfinger, por ejemplo, que es básicamente una especie de llamada para decir, oye, este arroba, Pepito, arroba servidor.com, ¿quién es? Es decir, dame información de esta persona, lo puedo hacer a través de HTTP y listo.
Un sistema muy simple y muy rápido. Por ejemplo, Webfinger, cuando estás en Mastodon y estás intentando escribir el nick de una persona y empiezas arroba a Lele, eso es lo que funciona. Está intentando buscar ahí en los Webfingers y en estas cositas. También entró ActivityStream, muy similar a ActivityPath, no solo en el nombre, sino también en el concepto.
Pero bueno, como decías tú, entró la W3C, se quedó en nada, y estábamos ya como en 2010. Entonces, nuestro amigo Evan, que yo no sé si este va a ser el episodio, lo vamos a titular nuestro amigo Evan y sus historias, volvió a crear otro software. Es decir, el tercero, la cuarta versión, y se llamaba Pump.io. De nuevo, ronda de titulares, ronda del futuro y no sé qué, etc.
Entonces, Pump.io era más ligero que StatusNet porque era un software para trabajar sobre un protocolo que era ligeramente diferente, que era ActivityPump, no Puff. Sí, que tampoco tuvo mucho, pero era una especie de oStatus que él decía, oye mira, voy a aplicar un poquito más de cosas sobre oStatus, lo voy a llamar ActivityPump porque hace estas dos cosas de enviar y recibir, pero sobre todo era mucho, mucho, mucho más ligero a nivel de consumo.
Es decir, que no era una cosa que tragaba y memoria y RAM y ancho de banda en los servidores. Esa yo creo que era la gran ventaja. Poco después, una vez que, de nuevo, estas cosas estaban ocurriendo en paralelo. Es decir, Pump.io estaba, oStatusNet seguía, etc. Idéntica, que no había muerto, ahí quedaba con unas focas, cambió. Dejó de utilizar el software de oStatusNet, es decir, lo que movía y manejaba y enviaba los mensajes y el contenido, lo cambió por el Pump.io y luego cambió el oStatus por el de ActivityPump.
Es decir, que se actualizó a los nuevos inventos que había diseñado el propio Evan. Aquí luego ya entraron los amigos de la GNU, que como ya sabes, pues eso es increíble. Siempre cuando ocurre, yo les quiero mucho a la gente de la GNU. El GNU Social este que sacaron, yo creo que lo veo más como una anécdota. Creo que intentaron entrar...
A ver, el tema de más todo en ActivityPump y todo lo que estamos comentando, sí que les pega, porque los principios de software libre, de que eres el soberano de tu información, sí que les pega. El problema es que yo el GNU Social no recuerdo o nunca entendí si era más como una red social que tú podrías utilizar, federada y tal, o como un agregador de otras redes sociales. Era un poco raro.
Yo lo que recuerdo en esas épocas era que digamos que se volvieron a repetir un montón de conversaciones que ya estaban asentadas. Es decir, llegó gente nueva a volver a replantearse cosas y eso sinceramente pues no ayudaba a nadie. Es como cuando llega el nuevo jefe a una empresa, o un nuevo comité, y empieza a hacer todo desde cero. No, mire señores, llegamos ya a cinco versiones diferentes y cinco años.
Vamos a seguir. Entonces StatusNet pasó a llamárselo del GNU Social, el GNU Social, y entonces ya aquí la W3C vuelve a intentarlo por segunda ocasión y aquí ya tenemos la semilla de ActivityPump que utiliza ActivityPump como origen, pero lo limpia y lo deja bien escrito y lo deja certificado. Yo creo que esto es ya lo bueno y estamos hablando ya de 2018 o algo así.
Sí, en paralelo hay que darse cuenta que el Eugen Rochko, que es el autor de Mastodon, está escribiendo Mastodon. Es decir, a veces se disocia el estándar de la implementación, entonces ahí es cuando te fallan las cosas. Porque si tú quieres hacer un estándar en el vacío, pues puedes hacer el estándar número 16 en la lista que hablábamos.
Pero cuando tienes una implementación que puede tener más o menos éxito, sabes qué es lo que está funcionando y lo que no. Es decir, sabes qué mecanismos o qué funcionalidades pueden escalar bien, cómo tienes que tirar el sistema y demás.
Y además, cuando publicas el estándar, es tangible. No puedes decir, ah, voy a probarlo. Entonces te instalas un Mastodon, un Pleroma, lo que quieras en el momento, y pues bien, funciona, no funciona, puedes contribuir, puedes evolucionarlo. Entonces creo que una de las claves del éxito, además de lo que le pasó a Twitter en octubre, ha sido el poder tener una herramienta que lo implementase justo en el desarrollo del estándar.
Exacto, porque son tantas partes. Primero, el protocolo. Los que definen el protocolo tienen que no solo decir eso es lo que se puede hacer, sino definir las cosas que se sugieren. Que esto es muy claro, y entran las interpretaciones, y son complicadas. Luego hay unos equipos que tienen que hacer el software o lo que va en el servidor.
Y luego otras personas que tienen que decidir, olé, vamos a poner la puerta a los humanos, la interfaz. Todo muy complicado. Definir el protocolo puede significar que el software consume 200.000 gigas de RAM, y es difícil, ¿vale? Entonces, son un montón de engranajes, y es normal, visto en retrospectiva, que no hayan funcionado ni a la primera, ni a la segunda, ni a la tercera, ¿verdad? Pero bueno.
Incluso con Mastodon, yo he visto instancias grandes, y he visto cómo funcionan detrás. Por ejemplo, la de Hacker.io, que tiene mucho estilo, han publicado como lo han instalado y tal, y no es... Primero, el Activity Path es un protocolo muy explícito, es súper chatty. Te está todo el día intercambiando mensajes, ¿vale? Entonces, si tienes muchos seguidores, tienes seguidores en muchas otras instancias y demás, es muy, muy verboso.
Entonces, a escalarlo bien y tal, tiene su complicación. Creo que el software está bastante bien diseñado, porque tienes, por un lado, en Mastodon el Sidekick, que sería el inbox y todas estas cosas que gestionan, la cola de eventos que ocurren. Y luego tienes toda la parte de la web para el API y demás, lo que llaman el Puma, y tiene un diseño inteligente como sistema distribuido.
Pero lo que no quiero decir es que, claro, el protocolo en sí, al final, te implica muchas... Tiene muchas implicaciones en la escalabilidad de lo que estás haciendo y lo fiable que va a ser después. Exacto. Absolutamente. Y si le dices, bueno, voy a que consuma menos ancho de banda o que envíe los mensajes en bloques, eso conlleva unos cambios en cómo se utiliza o en qué cosas se pueden hacer y qué cosas no se pueden hacer, en la federación...
Y hay un montón de elementos que creo que iremos explorando en los próximos episodios. Uno de los grandes conceptos que la gente se queda un poco despistada es en plan, si yo he borrado este mensaje, ¿por qué te sigue apareciendo a ti? Ay, amigo, es porque mi servidor o no ha recibido o no ha interpretado aún la petición de borrado. Ojito, es complicado todo. Y luego tiene efectos externos.
Por ejemplo, tú cuando pones un enlace, te genera la vista previa, esta con la imagen que intenta... Te genera la vista previa en tu instancia. Si tú tienes muchos servidores y muchas distintas instancias, lo que va a pasar es que tú publicas tu mensaje, ese mensaje va a los inbox de las 18.000 otras instancias que tienes porque tú tienes mucho éxito y cada una de ellas va a generar un preview independientemente para generarlo.
Entonces, hay servidores web que se quejan de por qué tanto más todo. Además, en un periodo pequeño de tiempo, porque si la red funciona bien, cuando tú publicas un mensaje va a estar en los inboxes de los otros servidores en unos pocos segundos.
Entonces, un protocolo de estos es normal que lleve muchas iteraciones porque cambios pequeños en la interacción que tú tienes que hacer para enviar o procesar un mensaje tienen implicaciones incluso fuera de la red. Absolutamente, absolutamente. Por ejemplo, en Telegram, que no es para nada descentralizada, en los grandes grupos siempre la gente se pregunta, oye, cuando tú envías un enlace y crea la previa, la estamos haciendo las 200.000 personas que estamos en este grupo porque imagínate, literal, el D2 que se crea desde un
grupo grande. Y esto lo hace Telegram a nivel centralizado. Entonces, ahí ya es cuando hubo toda esta migración de Mastodon, que pasó de OE-Status a ActivityPath, hubo un montón de problemas. Luego Samsung le dio una beca. No sé cuánto dinero fue, pero Samsung dio dinero a Mastodon en 2019.
De ahí, de aquellos barros, estos lodos, como se suele decir. Y bueno, nos han quedado un montón de temas por explicar. Tenemos que ahondar muchísimo en las diferencias, principalmente. Yo creo que sigue habiendo muchas concepciones erróneas de esto es una alternativa a Twitter, esto es un no sé qué. Yo creo que si se explica bien, la gente lo va a explicar, lo va a entender bien y entonces no va a haber tantas confusiones como algunas personas cuentan que tienen con todo lo que es la descentralización.
En fin, don Ramón. Don Alex. Dejamos para el siguiente episodio todas estas cositas. Yo creo que ha sido un muy buen episodio de Don Tomás. Yo creo que podéis adivinar de dónde viene el nombre y si os queda alguna duda, pues os suscribís y ya en el siguiente episodio os lo contaremos porque tengo la sensación de que va a ser un programa fantástico.
Yo estoy muy feliz de poder grabar contigo. Desde que viniste a Kernel y nos conocimos a través del audio, me diste muy buenas sensaciones. Es una de las pocas personas en el mundo que tienen la capacidad técnica y la capacidad explicativa para yo creo que esa combinación no es muy abundante. Bueno, bueno, bueno. Así que muchísimas gracias.
Ramón, ¿dónde te pueden leer? Yo suelo escribir en el Mastodon y en el Twitter porque me gusta escribir textos así rápido. Tengo un blog pero no tiene ninguna sola entrada, o sea que no vayáis a ir a buscarlo. Y pondremos el enlace yo creo en las notas del episodio porque el de Mastodon, yo soy R en Muvlog.tech, así que casi mejor escrito que él.
Eso es. Todas las cosas que hemos contado van a estar en las notas del episodio y un día hablaremos de esta complicación de lo de contar cuál es tu nick en estas plataformas y por qué es tan difícil, qué tipo de soluciones hay y de implementaciones se han ido discurriendo a lo largo de los años.
Nos despedimos. Muchísimas gracias. Dejadnos un comentario en vuestra plataforma de podcast, una estrella, un pulgar o lo que se utilice donde nos estés escuchando y nos vemos en el siguiente episodio de Don Tomás. Adiós.
A ver qué tal lo sale. ¿Cómo está el tiempo por ahí, por Suiza? ¿Estáis pasando calor ya? ¡Qué va! Está lloviendo. Ha sido el peor invierno porque no ha nevado, entonces no hemos podido ir a la montaña. Y la peor primavera porque no ha parado de llover, entonces tampoco hemos podido hacer nada, así que estamos aquí mirando por la ventana. Lo que se suele conocer como el infierno suizo de toda la vida.
En fin, bueno, el primer episodio de Don Tomás, de este podcast con este nombre tan particular, que teníamos tanta ilusión por comenzar, creo que tenía que ir de mastodón y creo que es lo que está catapultando ahora la conversación en general sobre la descentralización, sobre este tipo de cambio o posible tendencia, no sabemos lo que va a durar o si va a ser algo permanente, a nivel de internet en general, ¿verdad? Sí, a ver, lo hemos visto con mastodón como
la primera, digamos, gran éxodo de una plataforma centralizada a una... Yo no quiero decir que mastodón es una plataforma porque al fin y al cabo es como una implementación de un protocolo, no? Es la más... efectivamente hay un sesgo grande a que la grandísima mayoría de los clientes han sido mastodón, pero creo que se va a ver más también porque siempre cuando se habla de transformación digital y demás, ahora que está mucho en los medios y tal, muchas veces se añade
a la colectividad esta de la soberanía digital, ¿no? Y una de las formas de conseguirlo es utilizando protocolos que sean distribuidos de por sí, entonces no tienes al final un árbitro central, ¿no? En este caso es nuestro amigo Elon para Twitter, diciendo lo que se puede hacer o cómo se puede moderar o qué algoritmos hay que utilizar, ¿no? Eso es, y claro, todos sabemos que a día de hoy mastodón está basado en este palabra que a algunos os suena, a otros no, que
es ActivityPub, y vamos a comentar, pues eso, precisamente dónde están las fronteras, dónde empieza ActivityPub, dónde es mastodón como software, como servidor, todos estos conceptos que creo que siguen sin estar nada claros para muchísimas personas, porque claro, nos hemos tirado los últimos 15-20 años en plataformas completamente centralizadas, como cuál es tu cuenta de Instagram, esta es Poon, ¿no? A pesar de que, pues yo creo que tanto Ramón, tú como yo, como muchísimos de
nuestros oyentes, hemos crecido en la plataforma descentralizada por Autonomasia, que es el correo electrónico, y yo creo que mastodón tiene mucho más de correo electrónico, cuando hablas de ActivityPub y todas estas tecnologías, que de Twitter, a pesar de que la apariencia inicial es un poco, es un poco lo de Twitter, y esto es lo curioso, porque mastodón no siempre estuvo utilizando ActivityPub, ¿verdad? No, no, sí, o sea, el histórico de mastodón, hasta que llegamos a
mastodón que hay hoy en día, tiene más de una década de historia, o sea, son plataformas de microblogging, que eran, cómo decir, algunos open source, algunos no, tenían protocolos, vamos a decir, homegrown, de esto que cada una tiene una versión diferente de lo mismo, porque al final es similar, pero creo que lo que dices de correo electrónico es muy acertado, porque cuando el protocolo lo estandariza, el W3C, que es el Web Consortium, introduce conceptos como un inbox,
si es verdad que el concepto al paralelismo con el correo electrónico es claro, y lo demás está la identidad de los usuarios dentro de la red, es muy parecida del correo electrónico, porque tú tienes un nombre de usuario en un servidor. Exacto. No es una identidad global como pueden ser tus nombres de usuarios dentro de Instagram.
Exacto. Yo creo que esa es un poco la gran diferencia, y hablamos de que no siempre todo ha sido código abierto, y a mí esto me fascina porque yo creo que hay muchas personas que piensan que esto es una cosa de hippies y cosas así, y no necesariamente, ¿vale? Si es cierto que son elementos que han sido catapultados y que ha habido mucho interés tanto en Europa como en Estados Unidos, principalmente, ¿vale? Pero yo creo que son fenómenos completamente globales.
En concreto, origen, origen, origen de todo, yo creo que podíamos hablar de un montón de cosas de historia, porque ya tenemos, como decías tú, pues más de una década, yo te diría, de este tipo de una persona, se le ocurre un concepto, y luego vamos a ver si lo podemos estandarizar, y luego se aburre, y luego deja de no sé qué, y luego tiene éxito, o no tiene éxito, o queda todo abandonado.
Hay un montón de conceptos que hablabas tú antes, como lo del inbox, este buzón de entrada de datos que propone y que ofrece, y sobre el que funciona ActivityPub, que yo creo que deberíamos de explicarlos al principio, ¿no? Entonces, cuéntame un poco. A ver, el protocolo, al final lo que tienes son los objetos, tienes actores y actividades, ¿no? Al final esto siempre se puede hacer un paralelismo con el email, para que sea más fácil de entender.
Los objetos son los elementos que se transportan. Serían los emails, pues en este caso lo que pasa es que hay varios tipos de objetos, porque el ActivityPub, nosotros lo vemos mucho en Mastodon, que es una red de texto, pero podría ser una red de fotografías, por ejemplo. De hecho, hay aplicaciones que serían como una mímica de Instagram en la que tú...
Sí, PixelFed, y está consiguiendo bastante tráfico. Tenemos encima de ActivityPub PeerTube, que es algo relativamente similar, o que intenta conseguir algunos de los conceptos capitaneados por YouTube, etcétera. Pero sí, yo creo que va mucho más allá del texto, como dices tú. PeerTube, por ejemplo, tiene cosas de vídeo y tal. Entonces, bueno, todos esos serían las cosas que se pueden transmitir.
Los actores son lo que en email sería el destinatario y el receptor, sería quién es el autor de las cosas. Y luego las actividades, como si le añadieras un API al correo electrónico para realizar acciones con diferentes semánticas. No solo el transportar objetos de un destinatario a otro, sino que tú puedes actualizar un mensaje, por ejemplo, que en correo electrónico lo único que se hace sería enviar uno nuevo.
Y puedes borrar, puedes bloquear, puedes seguir. Y no solo sobre los objetos, pero también sobre los actores. Tú, un actor, como puede ser otro usuario en otro servidor, lo puedes bloquear. Eso está muy chulo, porque hay elementos del ActivityPub que nos recuerdan al correo electrónico y hay otros que me parecen como el RSS.
Pero en un único sentido, es decir, tú recibes información, tú también emites información. Es decir, todas tus acciones, como comentabas tú, tus actividades de ti como actor, sobre los objetos que se van publicando y que están presentes en tu servidor o federados, etcétera, todo tu flujo de acciones que haces tú localmente las emites para que todas las personas que te siguen o que están suscritos a ti las vayan recibiendo.
Con lo cual, si tú le das me gusta a un objeto, que puede ser un artículo o lo que sea, la otra persona tiene que recibir en algún momento esa notificación y su servidor decirle, oye, Pepito le ha dado me gusta a este objeto. Y una cosa buena es que las actividades las puedes expandir. Cada uno puede crear y puede personalizar y puede decidir qué es lo que significa y qué es lo que hace e incluso añadir un poco las suyas propias.
En esto me recuerda un poco también al RSS y a los namespaces del XML, ¿verdad? Sí, sí, es un protocolo extendible. Está bien definido porque el estándar que publicó el W3C serían los fundamentos básicos y luego la gente puede establecer sus extensiones dentro del estándar sin tener que sacar versiones posteriores. Podrías ver, por ejemplo, un servidor de Mastodon o de Gear2, por ejemplo, que se quiera financiar con anuncio, posiblemente podrías añadir extensiones a las actividades que sería este.
Este es un mensaje especial, por ejemplo, entonces no es algo que provenga de algún usuario, sino un servidor. O podrías ver, por ejemplo, debería ser posible hacer con ActivityPub un sistema como el de Spaces que tiene Twitter para el audio, transmitiendo, por ejemplo, fragmentos de audio del Space que se esté transmitiendo, añadiendo, por ejemplo, campos de prioridad.
Eso como es algo en tiempo real, si estás haciendo un podcast o lo que sea, pues quieres que vaya en la sitbox que coja la prioridad y entre a la arriba de la cola, por ejemplo, es decir, extensiones. Por ejemplo, PeerTube, cuando alojas un vídeo, consume muchísimo y no todo el mundo puede pretender que su instancia realmente...
porque aquí cuando hablamos de instancia técnicamente nos referimos al servidor, es decir, una cosa que esté en algún sitio haciendo esa transferencia de datos, enviando y recibiendo. Igual que para un correo electrónico necesitas el cliente y el servidor que lo gestione, pues aquí tenemos eso. No sé muy bien por qué comenzamos a hablar de instancias hace años, pero yo creo que ya es un término completamente aceptado.
Y te decía lo de PeerTube, porque PeerTube, además de que te puedas transmitir el vídeo por HTTP normal, también puedes utilizar y ofrecen WebTorrent, por ejemplo, para simplemente que el vídeo entre dentro de este enjambre, dentro del protocolo BitTorrent, uno de los mayores casos de éxito de la descentralización de la historia de internet, sin ninguna duda, y que la instancia que lo aloja simplemente actúe como uno más de las semillas de ese contenido, con lo cual se ahorra muchísimo tráfico y muchísimo
ancho de banda. Sí, sí, sí, eso está ahí. Luego, otra de las cosas que hay que decir es que en el paralelismo que estamos teniendo con el email, los problemas que tiene el email históricamente también los mantiene ActivityPath. Si miramos cosas como la identidad, es una identidad en la que tú dependes del servidor en el que tú estés.
Eso es. Yo, por ejemplo, utilizo Gmail y mi identidad en lo que sería mi cuenta de correo es en gmail.com. Si uno utiliza su propio dominio, pues su identidad es el centro de su dominio. Es decir, no hay notificadores globales, lo cual tiene las ventajas porque maximiza la descentralización, pero para la gestión de la identidad es más complejo.
ActivityPath tiene un sistema, yo lo he probado un par de veces, que me parece que está bastante bien ejecutado para cambiar de identidad. Es decir, no puedes transferirla cuando cambias de un servidor a otro o de una instancia a otra, pero al menos sí que puedes transferir tu estado, que sería la gente que te sigue. Creo que no transmite los estados que tú has escrito, es decir, empiezas desde cero.
Cuando yo lo he hecho, no me ha movido el contenido que yo cree. Es lo que dices tú, te mueve los suscriptores, por decirlo así. Es como una notificación de ahora soy otro alter ego. Pero bueno, es bastante mejor que, por ejemplo, la migración de datos existente entre Facebook y Twitter, por ejemplo, que es imposible. Exacto, que es inexistente.
Esa portabilidad del grafo social o del gráfico social. Nunca he sabido muy bien cómo traducirlo al español. Parecía todo muy bonito en las primeras épocas de la web 2.0 y al final todo el mundo se cerró y todo el mundo se quería quedar con lo con lo suyo. Sí, bueno, lo ves en cosas como, por ejemplo, varias veces en Twitter hemos visto desde octubre hasta ahora el acapanamiento del tráfico, digamos, en el sentido de que el incentivo de la red centralizada es que tú estés en su plataforma y no salgas a otra.
Entonces lo hemos visto con el caso de Chubstack, los enlaces a otras redes sociales, como el propio Mastodon, me parece que ocurrió que lo marcaba como un enlace dañino. Estos incentivos, claro, al ser una red distribuida, no existen. Existen otros incentivos diferentes. Eso es, eso es decir, no todo es bonito, no todo es precioso, porque uno de los graves problemas que tienen estos protocolos o estos sistemas abiertos en el que cada uno puede conectarse, etcétera, por ejemplo, como hemos
visto en el correo electrónico, es el spam. No hemos visto grandes casos de, madre mía, por qué estamos todos en este servidor, en esta instancia, recibiendo estas notificaciones, pero es básicamente porque yo tengo un buzón de entrada y cualquiera me puede enviar las cosas, al igual que en un correo electrónico, ¿no? Sí, el spam es el gran problema que ha tenido el correo electrónico y es el gran problema que va a tener ActivityPub como red cuando escale.
Sinceramente. En el correo electrónico, pues hemos visto que hay muchos sistemas de firmas digitales, de Mark, tenemos cosas como una cosa que ha salido ahora que se llama Bimi para proteger las marcas, etcétera, etcétera. Es todo firmas digitales y autenticación del origen del contenido, ¿no? Más todo en eso todavía no existe.
Creo que quien le está dando una buena pensada a esto es la gente de BlueSky con el protocolo Adds. Por ejemplo, ellos lo que hacen es, hay una diferencia de concepto en el sentido de que en ActivityPub, cuando un servidor te deja algo en tu inbox, tan pronto como provenga de ese servidor, pues está autentificado. Si es spam o lo que sea, pues ya está, ¿no? Tú puedes crear una instancia de Mastodon, por ejemplo, que se debe enviar spam a todos los inboxes y el pritito, como viene de una instancia de tag,
entonces la única opción que tienes ahí de moderación es decir, bueno, pues, defederamos esta instancia, ¿no? Entonces se añade una lista negra, digamos, y cualquier mensaje que venga de esa instancia, pues consideramos que es abusivo, spam o lo que fuera.
Ha pasado con servidores japoneses, por ejemplo, que tienen otra idiosincrasia. Y en el caso de Adds, lo que se hace es, se autentifica cada objeto que se transmite, mientras haya sido creado por el actor que dice ser el creador. Eso se firma digitalmente. Entonces tú ya sabes que eso ha sido creado por una persona, un bot que está diciendo quién dice ser, ¿no? Pero al menos no es una instancia, por ejemplo, que está generando mensajes. Ahora que estamos aprendiendo más sobre este protocolo AT o el protocolo ADD que
está utilizando BlueSky, tienen conceptos muy diferentes con respecto a ActivityPath. Se pueden construir puentes para unir un protocolo con otro, pero me parecen súper interesantes las diferencias y los conceptos detrás. Los conceptos, digamos, que han llegado a otras conclusiones muy diferentes a las que construyeron la arquitectura de ActivityPath. Y eso lo tenemos que tratar en algún episodio.
Yo no sé si tú ya tienes tu cuentita de BlueSky. Estoy en el waiting list. Ahora a ver si te puedo dar una invitación porque está goloso, me está gustando mucho. Pero ahora mismo, mi niña bonita es Mastodon. Entonces, yo creo que han quedado claros los conceptos, el por qué es diferente, el por qué es tan ilusionante, el por qué creo que puede tener un buen tirón, no con todo el mundo, eso sí es cierto.
Hemos visto pros y contras, pero vamos a hablar del origen, vamos a hablar de los datos históricos, vamos a hablar de todo esto porque vamos a decir un montón de palabras y un montón de nombres que a muchos de los que hayan, no solo los lectores de Mixio, sino la gente que haya estado dentro del mundillo, programadores, etcétera, gente que simplemente no haya vivido debajo de una roca durante los últimos 20 años, va a decir, ¡hostia, es verdad! ¿Qué pasó con esta gente? Y una de esas primeras palabras es la cónica.
¿Tú te acuerdas? ¿Tú te apuntaste a la cónica? Sí, sí. Yo no me acuerdo si me apunté o no, pero nada más que lo he estado revisando las notas y he visto la cónica y he tenido esa misma sensación de, ¡hostia, es verdad! Pero si eso, yo me acuerdo de darme de alta en Gemayl con las invitaciones, aquellas que había en su época, y tener aquel tema por entonces, sí, sí.
Y lo que pasa es que aquello era, creo que era open source, pero el protocolo era propio, o sea, era una cosa completamente ad hoc. Era, vamos a ver, es que esto lo creo Evan Prodomou o algo así, no me acuerdo de cómo se pronuncia, no me lo preguntéis. Estaba en San Francisco este señor que es bastante veterano, bueno yo creo que ya era veterano entonces, en 2007-2008 cuando empezó con esto, y estaba construyendo por una parte la plataforma, es decir, el software, lo que tú instalas y te
sirve para comunicarse, y por otra parte estaba construyendo Open Microblogging, inspirado también en Twitter, a la vez. Es decir, mira, y luego coge, bueno, esta librería es la plataforma, esta librería es el protocolo, y quedó un poco, yo no diría chapuza, pero era lo que era, ¿vale? Orgánico, se dice.
Sobre todo es que era muy simple, era muy sencillito, solo quería imitar lo que era Twitter en aquel momento, que era básicamente él, estoy en la cafetería comiéndome un donut. Bueno, pero Twitter era así al principio, hay que recordar que Twitter cuando nació, todo el concepto de retuits y todas estas cosas no existían, fueron las aplicaciones quienes inventaron toda esta nomenclatura, los hashtags, por ejemplo, era un diseñador que apareció por
ahí, lo inventó y tal. En 2008, Twitter era una lista de cadenas de texto, o sea, no había más. Y muchos lo utilizaban en el móvil a través de SMS. Es que era una locura, es que era una locura, todos los que entraron en Twitter en una gran oleada esta de 2012, 2003, etcétera, conocieron otro Twitter muy diferente. Bueno, hay que contextualizar, el iPhone no se había lanzado cuando aparece la cónica y cuando
aparece Twitter por primera vez. Tú estabas con tu Nokia N73, como tenía yo, mandando SMS a un endpoint de Twitter, que te cobraba 1,50€ por cada mensaje para publicar tú, que pues no sé, que ibas a tomar algo. Y ya está, y no tenía mucho más, eran tiempos más sencillos, ¿verdad amigo? Mucho más elegante todo. Entonces, una vez que tenía la cónica, digamos que lo que se creó fue la instancia en la que
yo creo que más éxito tuvo, que era Stoica, que era estoi.ca. Era como muy griego todo esto, no muy griego clásico. Y luego eso lo cambiaron el nombre, porque decían esto Stoica tal. Yo creo que como Stoica, no sé si duró días o semanas. Y luego ya, y esta es la palabra que a muchos os va a sonar, que es Identica. Sí, esa es la que yo recuerdo haber usado yo creo. Y esa era una instancia, es decir, un servidor en el que cada uno, digamos,
podía crearse y tener su propio Twitter, o podías descargártelo y montártelo por tu cuenta, ¿no? Y federarte a través de este Open Microblogging, que era, pues eso, como dices tú, muy orgánico. Luego Evan siguió acelerando por ahí, ya sabéis estas cosas. Como el chiste de XKCD, el mítico cómic de, hay trece estándares, necesitamos una cosa para solucionarlo. Resultado, ahora hay catorce estándares.
Esto es la historia que os vamos a contar. Sí, pero eso es todo, eh, o sea, es una máxima de la naturaleza y de la tecnología, es increíble. Bueno, Evan creó una empresa para mantener todo esto, que era Control Yourself. La empresa pasó a llamarse StatusNet, otro nombre que seguro que está en vuestros neocortex, y cambió el nombre, que era el software, es decir, la cónica, pasó a llamarse StatusNet, y creó Status.net, que era la instancia donde la gente podía tener sus microblogs.
Entonces, durante un tiempo, existía Identity.k, Status.net, era un poco un jaleo. Luego la gente se preguntaba, ¿por qué esto no ha funcionado, no sé qué? Macho, Evan, que por la mañana decías una cosa, y por la tarde decías otra cosa. Bueno, mira, el mismo paisano haciendo todas las historias. Sí, ya había bastantes más personas.
No tengo los nombres y no los recuerdo, pero sí que Evan, que está en el tema de la ActivityPub, es decir, que ahí sigue, está presente ahí, todas estas personas. Igual que cuando se decide los estándares HTML y todas estas... y las estandarizaciones RFC y todas estas cosas, son gente, no diría en la sombra, porque todo lo puedes ver públicamente, etcétera, pero gente relativamente anónima, gente que sabe mucho, que está trabajando, en principio, en hacer un futuro mejor.
Es cierto, pues que no lo clavaron a la primera, sin ninguna duda. Es que es muy complicado, porque a la vez que estamos viendo esto, Twitter está evolucionando, añadiendo muchos fichos, muchas cosas, y luego el Product Market Fit, este que le gusta mucho llamar a la gente, iba cambiando, porque hay cosas que en Twitter funcionaban muy bien, lo de Vine, por ejemplo, para los vídeos y tal, y otras que no.
Entonces, claro, a la vez que la gente iba descubriendo lo que era el social media y todas estas cosas, y buscando que funcionara, ellos estaban desarrollando una plataforma, que los requisitos de lo que la gente iba utilizando estaban variando cada seis meses. Y lo mismo le pasaba a Twitter. ¿Queremos subir imágenes a Twitter? No se puede.
El Tweet Image que había por entonces. El Tweet Pic, el no sé cuándo, un montón de cosas. ¿Queremos poder programar contenido para que se publique en Twitter? No se puede. Bueno, voy a montármelo por mi cuenta. Y todas estas cosas, Twitter las ha ido añadiendo. Entonces, cuando tienes un equipo de ingenieros, pues poco a poco lo vas a poder hacer, y lo vas a ir pudiendo hacer.
Sí es cierto que Twitter, tradicionalmente, ha sido una empresa que ha ejecutado muy lento, ¿verdad? Más que ejecutado, es una empresa que ha reaccionado muy lento. Ha empezado a hacer cosas muy lentas. En ejecución luego, cuando saben lo que quieren hacer, pues bueno, más o menos lo hacen. Pero sí es verdad que otra, una propiedad bonita de Twitter que tuvo durante esos años, es que era descentralizado de una forma.
Es que ellos tenían como el backbone de la red. Nosotros vamos a controlar la identidad, tú eras el que tenía la cuenta de Twitter, y vamos a controlar el feed de las cosas. Pero luego, muchas de las cosas que tú publicabas, pasaban en servicios externos.
Publicabas en Tweet Pic, publicabas en los mapas, en otra historia donde estabas, en el Swarm, que ahora se llama Swarm, se llamaba el Foursquare, te daban los check-ins. Luego tenías cosas como los vídeos en Vine o los predecesores, los memes venían de otro lado. Twitter, Instagram nació mucho gracias a Twitter también, porque muchas de las imágenes se publicaban directamente en Twitter, y la podías ver, la imagen subía, no tenías que ir a Instagram.
No era descentralizado en el mismo sentido de lo que era ActivityPad, pero sí que tenía como otra dimensión de que muchos de los componentes que había estaban ejecutados por otras empresas u otros usuarios fuera de la red. Y sobre todo por otras interfaces, es decir, tú podías entrar a Twitter desde donde quisieras. Hubo mucha experimentación con interfaces de usuario.
Esto de historias de abuelo cebolleta lo tenemos que tomar a fondo en otro episodio, porque sí es cierto que lo que echamos mucho de menos es ese origen. Mira, vamos a hacer esta cosa mínima, tampoco nos vamos a convertir en un gigante tecnológico, pero va a ser muy importante. Al final decidieron eso que no, y quedó para un universo paralelo. Entonces, OpenMicroBlogging y nuestro amigo Evan volvieron a mutar como los X-Men y se convirtieron en O-Status.
De O-Status también te acordarás tú. Sí, sí, O-Status es la primera vez que se intenta buscar un consenso. Es la primera vez que el W3C se ve como involucrado, en el sentido de decir, esto parece que puede ser útil, parece que estaría bien que haya una federación. Pero claro, para que haya una federación tiene que haber un lenguazo, un protocolo, que podamos comunicarlo. Y yo sí recuerdo que lo anunciaron con una cosa de, bueno, hemos hecho el protocolo definitivo, tal, no sé qué, y no tuvo tracción ninguna.
No, pero es un poco siempre lo del ciclo este, de la pescadilla que se mueve la cola. No hay usuarios porque la plataforma y el protocolo tampoco permiten hacer mucho, con lo cual la gente no se conecta. Y es justo, yo creo, lo que no solo inicia este programa, sino que inicia toda la gran adopción de Mastodon, que es un hecho que ha forzado esa parte de la migración.
Y los efectos de red han empezado a funcionar, que no había ocurrido con StatusNet, no había ocurrido con Identica, no había ocurrido con OStatus, ni con todas estas tanto plataformas como protocolos. Aquí entran ya Webfinger, por ejemplo, que es básicamente una especie de llamada para decir, oye, este arroba, Pepito, arroba servidor.com, ¿quién es? Es decir, dame información de esta persona, lo puedo hacer a través de HTTP y listo.
Un sistema muy simple y muy rápido. Por ejemplo, Webfinger, cuando estás en Mastodon y estás intentando escribir el nick de una persona y empiezas arroba a Lele, eso es lo que funciona. Está intentando buscar ahí en los Webfingers y en estas cositas. También entró ActivityStream, muy similar a ActivityPath, no solo en el nombre, sino también en el concepto.
Pero bueno, como decías tú, entró la W3C, se quedó en nada, y estábamos ya como en 2010. Entonces, nuestro amigo Evan, que yo no sé si este va a ser el episodio, lo vamos a titular nuestro amigo Evan y sus historias, volvió a crear otro software. Es decir, el tercero, la cuarta versión, y se llamaba Pump.io. De nuevo, ronda de titulares, ronda del futuro y no sé qué, etc.
Entonces, Pump.io era más ligero que StatusNet porque era un software para trabajar sobre un protocolo que era ligeramente diferente, que era ActivityPump, no Puff. Sí, que tampoco tuvo mucho, pero era una especie de oStatus que él decía, oye mira, voy a aplicar un poquito más de cosas sobre oStatus, lo voy a llamar ActivityPump porque hace estas dos cosas de enviar y recibir, pero sobre todo era mucho, mucho, mucho más ligero a nivel de consumo.
Es decir, que no era una cosa que tragaba y memoria y RAM y ancho de banda en los servidores. Esa yo creo que era la gran ventaja. Poco después, una vez que, de nuevo, estas cosas estaban ocurriendo en paralelo. Es decir, Pump.io estaba, oStatusNet seguía, etc. Idéntica, que no había muerto, ahí quedaba con unas focas, cambió. Dejó de utilizar el software de oStatusNet, es decir, lo que movía y manejaba y enviaba los mensajes y el contenido, lo cambió por el Pump.io y luego cambió el oStatus por el de ActivityPump.
Es decir, que se actualizó a los nuevos inventos que había diseñado el propio Evan. Aquí luego ya entraron los amigos de la GNU, que como ya sabes, pues eso es increíble. Siempre cuando ocurre, yo les quiero mucho a la gente de la GNU. El GNU Social este que sacaron, yo creo que lo veo más como una anécdota. Creo que intentaron entrar...
A ver, el tema de más todo en ActivityPump y todo lo que estamos comentando, sí que les pega, porque los principios de software libre, de que eres el soberano de tu información, sí que les pega. El problema es que yo el GNU Social no recuerdo o nunca entendí si era más como una red social que tú podrías utilizar, federada y tal, o como un agregador de otras redes sociales. Era un poco raro.
Yo lo que recuerdo en esas épocas era que digamos que se volvieron a repetir un montón de conversaciones que ya estaban asentadas. Es decir, llegó gente nueva a volver a replantearse cosas y eso sinceramente pues no ayudaba a nadie. Es como cuando llega el nuevo jefe a una empresa, o un nuevo comité, y empieza a hacer todo desde cero. No, mire señores, llegamos ya a cinco versiones diferentes y cinco años.
Vamos a seguir. Entonces StatusNet pasó a llamárselo del GNU Social, el GNU Social, y entonces ya aquí la W3C vuelve a intentarlo por segunda ocasión y aquí ya tenemos la semilla de ActivityPump que utiliza ActivityPump como origen, pero lo limpia y lo deja bien escrito y lo deja certificado. Yo creo que esto es ya lo bueno y estamos hablando ya de 2018 o algo así.
Sí, en paralelo hay que darse cuenta que el Eugen Rochko, que es el autor de Mastodon, está escribiendo Mastodon. Es decir, a veces se disocia el estándar de la implementación, entonces ahí es cuando te fallan las cosas. Porque si tú quieres hacer un estándar en el vacío, pues puedes hacer el estándar número 16 en la lista que hablábamos.
Pero cuando tienes una implementación que puede tener más o menos éxito, sabes qué es lo que está funcionando y lo que no. Es decir, sabes qué mecanismos o qué funcionalidades pueden escalar bien, cómo tienes que tirar el sistema y demás.
Y además, cuando publicas el estándar, es tangible. No puedes decir, ah, voy a probarlo. Entonces te instalas un Mastodon, un Pleroma, lo que quieras en el momento, y pues bien, funciona, no funciona, puedes contribuir, puedes evolucionarlo. Entonces creo que una de las claves del éxito, además de lo que le pasó a Twitter en octubre, ha sido el poder tener una herramienta que lo implementase justo en el desarrollo del estándar.
Exacto, porque son tantas partes. Primero, el protocolo. Los que definen el protocolo tienen que no solo decir eso es lo que se puede hacer, sino definir las cosas que se sugieren. Que esto es muy claro, y entran las interpretaciones, y son complicadas. Luego hay unos equipos que tienen que hacer el software o lo que va en el servidor.
Y luego otras personas que tienen que decidir, olé, vamos a poner la puerta a los humanos, la interfaz. Todo muy complicado. Definir el protocolo puede significar que el software consume 200.000 gigas de RAM, y es difícil, ¿vale? Entonces, son un montón de engranajes, y es normal, visto en retrospectiva, que no hayan funcionado ni a la primera, ni a la segunda, ni a la tercera, ¿verdad? Pero bueno.
Incluso con Mastodon, yo he visto instancias grandes, y he visto cómo funcionan detrás. Por ejemplo, la de Hacker.io, que tiene mucho estilo, han publicado como lo han instalado y tal, y no es... Primero, el Activity Path es un protocolo muy explícito, es súper chatty. Te está todo el día intercambiando mensajes, ¿vale? Entonces, si tienes muchos seguidores, tienes seguidores en muchas otras instancias y demás, es muy, muy verboso.
Entonces, a escalarlo bien y tal, tiene su complicación. Creo que el software está bastante bien diseñado, porque tienes, por un lado, en Mastodon el Sidekick, que sería el inbox y todas estas cosas que gestionan, la cola de eventos que ocurren. Y luego tienes toda la parte de la web para el API y demás, lo que llaman el Puma, y tiene un diseño inteligente como sistema distribuido.
Pero lo que no quiero decir es que, claro, el protocolo en sí, al final, te implica muchas... Tiene muchas implicaciones en la escalabilidad de lo que estás haciendo y lo fiable que va a ser después. Exacto. Absolutamente. Y si le dices, bueno, voy a que consuma menos ancho de banda o que envíe los mensajes en bloques, eso conlleva unos cambios en cómo se utiliza o en qué cosas se pueden hacer y qué cosas no se pueden hacer, en la federación...
Y hay un montón de elementos que creo que iremos explorando en los próximos episodios. Uno de los grandes conceptos que la gente se queda un poco despistada es en plan, si yo he borrado este mensaje, ¿por qué te sigue apareciendo a ti? Ay, amigo, es porque mi servidor o no ha recibido o no ha interpretado aún la petición de borrado. Ojito, es complicado todo. Y luego tiene efectos externos.
Por ejemplo, tú cuando pones un enlace, te genera la vista previa, esta con la imagen que intenta... Te genera la vista previa en tu instancia. Si tú tienes muchos servidores y muchas distintas instancias, lo que va a pasar es que tú publicas tu mensaje, ese mensaje va a los inbox de las 18.000 otras instancias que tienes porque tú tienes mucho éxito y cada una de ellas va a generar un preview independientemente para generarlo.
Entonces, hay servidores web que se quejan de por qué tanto más todo. Además, en un periodo pequeño de tiempo, porque si la red funciona bien, cuando tú publicas un mensaje va a estar en los inboxes de los otros servidores en unos pocos segundos.
Entonces, un protocolo de estos es normal que lleve muchas iteraciones porque cambios pequeños en la interacción que tú tienes que hacer para enviar o procesar un mensaje tienen implicaciones incluso fuera de la red. Absolutamente, absolutamente. Por ejemplo, en Telegram, que no es para nada descentralizada, en los grandes grupos siempre la gente se pregunta, oye, cuando tú envías un enlace y crea la previa, la estamos haciendo las 200.000 personas que estamos en este grupo porque imagínate, literal, el D2 que se crea desde un
grupo grande. Y esto lo hace Telegram a nivel centralizado. Entonces, ahí ya es cuando hubo toda esta migración de Mastodon, que pasó de OE-Status a ActivityPath, hubo un montón de problemas. Luego Samsung le dio una beca. No sé cuánto dinero fue, pero Samsung dio dinero a Mastodon en 2019.
De ahí, de aquellos barros, estos lodos, como se suele decir. Y bueno, nos han quedado un montón de temas por explicar. Tenemos que ahondar muchísimo en las diferencias, principalmente. Yo creo que sigue habiendo muchas concepciones erróneas de esto es una alternativa a Twitter, esto es un no sé qué. Yo creo que si se explica bien, la gente lo va a explicar, lo va a entender bien y entonces no va a haber tantas confusiones como algunas personas cuentan que tienen con todo lo que es la descentralización.
En fin, don Ramón. Don Alex. Dejamos para el siguiente episodio todas estas cositas. Yo creo que ha sido un muy buen episodio de Don Tomás. Yo creo que podéis adivinar de dónde viene el nombre y si os queda alguna duda, pues os suscribís y ya en el siguiente episodio os lo contaremos porque tengo la sensación de que va a ser un programa fantástico.
Yo estoy muy feliz de poder grabar contigo. Desde que viniste a Kernel y nos conocimos a través del audio, me diste muy buenas sensaciones. Es una de las pocas personas en el mundo que tienen la capacidad técnica y la capacidad explicativa para yo creo que esa combinación no es muy abundante. Bueno, bueno, bueno. Así que muchísimas gracias.
Ramón, ¿dónde te pueden leer? Yo suelo escribir en el Mastodon y en el Twitter porque me gusta escribir textos así rápido. Tengo un blog pero no tiene ninguna sola entrada, o sea que no vayáis a ir a buscarlo. Y pondremos el enlace yo creo en las notas del episodio porque el de Mastodon, yo soy R en Muvlog.tech, así que casi mejor escrito que él.
Eso es. Todas las cosas que hemos contado van a estar en las notas del episodio y un día hablaremos de esta complicación de lo de contar cuál es tu nick en estas plataformas y por qué es tan difícil, qué tipo de soluciones hay y de implementaciones se han ido discurriendo a lo largo de los años.
Nos despedimos. Muchísimas gracias. Dejadnos un comentario en vuestra plataforma de podcast, una estrella, un pulgar o lo que se utilice donde nos estés escuchando y nos vemos en el siguiente episodio de Don Tomás. Adiós.
