Hace dos años ya propusimos una forma de alimentar un repositorio con enlaces desde telegram , el módulo para drupal era planteado de una forma extensible: Podía ampliarse para recolectar no solo enlaces, sino cualquier "entidad" que albergue un mensaje de Telegram, en buena parte gracias a la excelente librería de php-telegram. Sin embargo, a pesar de la demanda, y de interesantes funcionalidades que añadiríamos a cualquier drupal el problema de fondo era desarrollar "encima" de telegram... El hecho de basarlo en telegram haría que el elefante estuviera siempre en la habitación, ya que Telegram no se puede considerar floss y si no lo ha sido a pesar de las dificultades que tienen en Rusia u otros países y han planteado proxies en lugar de servidores, es indicativo que difícilmente lo será.

Citando el FAQ de Telegram:

Our architecture does not support federation yet. Telegram is a unified cloud service, so creating forks where two users might end up on two different Telegram clouds is unacceptable.

Aunque con un enfoque mucho mas abierto, está Signal, pero aunque puedas tener tu servidor, la federación se hace dificil, más cuando los desarrolladores ven la distribución de servidores como algo que obstaculiza el desarrollo.

En el mismo post que hicimos ya se planteaba que sería interesante huir de servicios de mensajería cerrados, para evitar el cercamiento de algo tan elemental como es la comunicación entre pares. Puede parecer vanal, pero se debe dar la importancia y ser consciente que es crucial para garantizar la privacidad, el respeto y la soberanía completa sobre los datos, así como para evitar que se filtren los pequeños metadatos sobre los que se fundamentan modelos de negocio de gigantes. Los servicios de mensajería son servicios que utilizamos masiva y constantemente, como consecuencia hay que establecer una tendencia y un saber-cómo que se oriente al uso de servicios que mantengan coherencia con aquello que sabemos que es justo y responsable. Aún sabiendo que no va a haber un uso masivo, si que se puede dar respuestas concretas a demandas. De hecho el mercado está actuando así cuando vemos que para casos que se requiere adaptación a un contexto, se opta para mensajerías ad-hoc aisladas.

Ya en su día hablamos de XMPP, o los más recientes Signal o Matrix. Nuestro día a día y apostar por sistemas distribuidos como factor de resiliencia nos ha movido a habitar y desarrollar componentes "encima" del protocolo Matrix. Una red abierta para la comunicación distribuida segura.

Esta red no sólo se ha pensado en que sea federada desde un inicio como lo es el correo(cada uno puede tener su propio servidor), también puede enlazarse a otros servicios como telegram, whatsapp, gitter, rocket... Utilizando los bridges podemos habilitar salas de servicios híbridos, o plantear transiciones y migraciones menos traumáticas.

Comunicando con repositorios de datos o cms

El primer paso ha sido plantear un sistema análogo a lo que hace telegram con los bots y sus comandos. Esto es en lugar de confiar en un botfather que nos permita añadir comandos, es habilitar un bot que registre comandos en cada sala, el bot se llama webhooker: Lo que hace este bot es que cuando ocurre un lanzamiento de un comando se hace un envío POST con un mensaje de Matrix a una url concreta. Su seguridad se basa en una llave secreta que junto a los parámetros de URL+COMMAND+MatrizRoomID encriptan un token jwt que es el que en el otro extremo se deberá aportar para conseguir la autorización.

En el otro extremo, en el repositorio o el cms, hemos derivado el módulo que en su día creamos ( telegram_media ) para adaptarlo a la red matrix, el ćodigo está en el proyecto matrix_webhook en drupal.org .

Con esto crece la capacidad para recolectar todos los contenidos que hay y poder crear contextos para las comunidades o grupos. Y todo bajo nuestro control. Además de los bots existentes ya partimos de una plantilla para poder crear de nuevos y así desplegar servicios encima o los que mencionamos en su día: por ejemplo si tienes un grupo de cocina y quieres ir guardando las recetas, o del AMPA y quieres guardar enlaces sobre pedagogía. Cómo ejemplo de donde más ampliar: Se pueden crear pasarelas de pagos, canales de comunicados, mantener redes de intercambio de ficheros, o pensar en catálogos de contenidos.

Ahora ya tenemos al mismo nivel las funcionalidades que permitían recolectar enlaces desde los grupos que estemos, los enlaces que compartamos podrán ser recolectados sin problema.

Cómo se usaría

Cómo prerequisito crearemos el usuario del bot. Con sus credenciales lanzamos el servicio webhooker. Después invitamos el bot en el grupo que gestionamos en cuestión. Una vez invitado registramos un nuevo comando:

!webhooker command:set !comando_que_dispara_el_envio https://repositorio.net/ejnf838u23nf398-fragmento-de-dificil-obtencion-300101 {"contexto": "Nos permite añadir propiedades constantes que serán añadidas en cada envío hacia el repositorio"} Nos devolverá un token jwt.

Con esto vamos al otro extremo, nuestro drupal, ahí como requerimiento tendremos que instalar el modulo matrix_media , lo configuramos en admin/config/services/matrix_webhook/hooks:

• webhooker token: token_devuelto
• Url token : ejnf838u23nf398-fragmento-de-dificil-obtencion-300101

En admin/config/services/matrix_webhook/hooks/field_mapping podemos decidir como qué tipo se guardan los contenidos, qué campos utilizar y con que usuario.

Una vez configurado en el grupo en cuestión podemos lanzar:

/c absolute_url [description] [#tag] [#tag2]

También puede ser con una respuesta a cualquier enlace envíado, solo con:

/c [description] [#tag] [#tag1]

Un contenido nuevo será creado usando el tipo de contenido y los campos especificados.