Parmi les diverses initiative de microbloging à la Twitter, Bluesky a justement été fondé par le fondateur de Twitter et est un des réseaux sociaux qui a le vent en poupe par son concept et son potentiel. Le nombre d'abonnées est encore relativement modeste avec un peu moins de deux millions d'utilisateurs en octobre 2023, l'inscription se faisant uniquement sur invitation. Ces invitations sont fournies aux utilisateurs inscrits pour en faire venir d'autres mais d'abord en petites quantités et lissées sur le temps.

Ce mois-ci, je me suis décidé à ouvrir un compte pour Animint sur Bluesky, ce qui est synonyme de branchement de mon outil de publication sur les réseaux sociaux dessus. Après avoir d'abord développé et configurer les envois vers Twitter via leur API, je suis passé très simplement sur Mastodon, les définitions d'interface étant quasiment identiques. Le plus lourd avait été de monter ma propre instance Mastodon pour éviter de dépendre d'un accès tiers. Je m'en suis également sorti avec le passage de Twitter à X et du champ de ruine qu'est devenue leur API, un gloubi-boulga mélange de deux versions différentes, l'une obsolète et l'autre incomplète dans une association de fortune qui respire le travail bien bâclé comme il ne faut surtout pas faire.

 

Fort de ces expériences, je me suis lancé dans l'interfaçage avec Bluesky mais j'ai été surpris par toutes les difficultés que j'ai rencontrées pour y arriver.

 

Quand vous commencez à jouer avec les APIs, il se peut que vous fassiez des bêtises et cela peut se traduire par une suspension de compte. Sur Twitter, la multiplication de comptes de test était facile et sur Mastodon, j'étais sur ma propre instance donc libre de casser ce que je souhaitais en pratique. 

 

Sur Bluesky, la logique d'invitations refroidit tout de suite les ardeurs de brûler un compte juste à cause d'un test qui a mal tourné mais le réseau social propose une sandbox, un espace pour pouvoir tester. La condition est juste de devoir installer son propre serveur de données qui peut être ensuite branché sur ce réseau de test. Avoir une sandbox est appréciable et j'ai donc mis en place mon propre Personal Data Server (PDS).

 

L'installation à l'aide de Docker mâche une grande partie du travail mais quelques prérequis compliquent la tâche, sans qu'aucun point d'attention ou mode opératoire soit mentionné dans la documentation liée au PDS. Il a fallu non seulement définir mon domaine bluesky.animint.fr pour le serveur PDS mais aussi accepter que tous les sous-domaines *.bluesky.animint.fr pointent dessus. Au delà d'y penser, il faut aussi avoir un certificat web SSL qui acceptent de gérer ces sous-domaines génériques. Là, j'ai eu le loisir de découvrir que c'était plus lourd à déclarer qu'un domaine spécifique. J'ai consacré pas mal de temps à devoir gérer des DNS, les demandes automatiques de certificats SSL et j'ai découvert au passage les APIs de sociétés d'enregistrement de domaines. C'est bien pour ma culture informatique mais j'aurai aimé passé moins de temps sur ces hors sujets. 

 

Un des modules du PDS est un simple reverse proxy – en plus exotique quand vous n'avez vu que de l'Apache ou Nginx -, un serveur web pour simplifier. Évidemment, sur une machine de test, ce n'est pas le seul serveur web qui tourne dessus et vu que j'ai déjà un reverse proxy, j'ai voulu basculer la configuration PDS sur mon serveur existant. Sauf qu'au delà de la redirection des ports, il faut savoir que les websockets doivent aussi pouvoir passer et aucune instruction ne laissent le transparaître dans le fichier de configuration originel et je n'ai rien vu de mentionné dans la documentation. 

 

En oubliant à la fois la déclaration des sous-domaines génériques et les websockets, je me suis cependant retrouvé avec un serveur qui marchait quand même un peu au lieu de planter franchement. Le serveur répondait correctement à la commande supposée confirmer son bon fonctionnement – j'ai pu générer un code d'invitation et m'inscrire dessus - mais derrière, la page de profil ne s'affichait pas par exemple. En consultant les différents messages sur la partie tickets du Github du projet, j'ai vu d'autres utilisateurs avec le même soucis et des échanges qui avançaient l'idée que le serveur était bogué. Un des participants a ainsi pointé que la version utilisée par Bluesky en production était sur une autre branche moins facile à installer mais mise à jour récemment tandis que l'instance à destination des sandboxes était en sommeil depuis un mois. 

 

Un des concepts de Bluesky est la séparation claire et nette des clients web par rapport au serveur back office, ce qui fait qu'aucun client web était en fait fourni avec le PDS ni même mentionné. Pour tester, vous êtes en fait invités à utiliser un serveur web commun de test qui se connecte ensuite à votre PDS. Ignorant d'où provenaient mes soucis, j'ai aussi installé la dernière version du client web en local pour éliminer une cause éventuelle des problèmes. 

 

Qui dit serveur de développement dans mon esprit, dit petit serveur mais j'ai eu la mauvaise surprise de devoir réserver 6 GB de mémoire pour pouvoir compiler et installer le client web officiel tout en évitant de faire planter la machine.    

 

Finalement, en décortiquant quelques messages, j'ai pu identifier ce qui manquait dans mon environnement et je suis parvenu à avoir un PDS fonctionnel visible depuis le client web du serveur de développement Bluesky mais cela a été vraiment laborieux. J'avais rencontré quelques soucis avec l'installation en standalone du serveur Mastodon mais c'était plus tranché et généralement lié à des problèmes de versions des composants, problèmes en fait inexistants dans la distribution dockerisée.

 

J'ignore si cela va changer mais la configuration pour donner accès à une application est en revanche très simple. Il suffit de faire une nouvelle entrée et un mot de passe est généré automatiquement. Il faut penser à le noter à la création car il est inaccessible après mais c'est une règle habituelle pour les données d'accès secrètes des APIs. Le nom rempli pour l'application n'a pas l'air d'avoir d'importance car seuls le nom d'utilisateur et le mot de passe sont requis dans la phase d'authentification pour ouvrir une session.

 

Un autre aspect que j'apprécie avec Bluesky mais cette fois-ci en tant qu'utilisateur, est de pouvoir utiliser le domaine animint.com comme nom d'utilisateur, ce qui évite la course pour réserver son handle. De toute manière, animint.bysky.social était déjà pris au moment où je me suis inscrit. 

 

Je suis en revanche moins fan de l'implémentation du contrôle pour lier le nom de domaine au nom d'utilisateur. En passant par la configuration DNS, le serveur Bluesky a réussi à lire l'information pendant une journée puis il l'a perdu et en passant par le simple fichier placé sur le serveur web éponyme du nom de domaine, la vérification est perturbée par les redirections. J'ai l'habitude de rediriger les appels animint.com vers le www.animint.com mais il a fallu faire une exception pour le fichier lu par Bluesky. 

 

Une fois l'environnement et les accès en place, il restait à s'attaquer aux développement du code. Il a fallu comprendre qu'il faut naviguer dans les lexicons pour dénicher les commandes et être au courant de la syntaxe standardisée pour voir les détails des paramètres à envoyer en XRPC. Hormis faire du reverse engineering des bibliothèques pondues pour différents langages de programmation, vous vous orienterez sans doute comme moi vers des tutoriels qui présentent les bases. Heureusement mis à part la forme, la logique est relativement similaire que pour Twitter et Mastodon au niveau des publications, notamment le fait de charger d'abord les images les unes après les autres puis de les lier ensuite au texte. 

 

Cependant, l'interfaçage est aussi pénible avec l'absence de l'analyseur automatique de texte côté serveur pour isoler les liens ou les mentions de personnes par exemple. C'est au client de le faire puis d'envoyer ensuite le texte structuré au serveur, le nec le plus ultra étant que des méthodes sont définies mais pas encore implémentées, telle que l'insertion de vrais mots clefs. La logique de séparation entre front et back office justifie tout à fait cette approche mais cela complexifie mes affaires : soit je vais devoir coder l'analyse ses textes pour envoyer ensuite les bonnes données structurées à l'API Bluesky, soit je passe par une bibliothèque de code qui le fait mais qui est un million de fois trop lourde par rapport à mes maigres besoins. 

 

Pour l'instant, l'implémentation reste modeste. Je publie les textes bruts de fonderie et j'associe une ou plusieurs images, avec remplissage du champ "alt" en profitant du modèle déjà mis en place pour les images postées dans Mastodon. Je verrai pour le formattage, les réponses et les partages un peu plus tard.