Partager sur Bluesky

Cela faisait quelques mois que j'avais arrêté de toucher à mon outil maison de publication automatisée sur les réseaux sociaux mais la nième annonce de feu ex-Twitter qui a provoqué une nouvelle vague de migration vers Bluesky m'a incité à compléter mes fonctions pour exploiter un peu plus le contenu et rajouter la fonctionnalité de re-Post qui manquait.

 

J'avais codé l'outil initialement autour de l'utilisation de Twitter et pour pouvoir retweeter de manière programmée et même à l'avance des posts pas encore publiés. Quand l'API ex-Twitter est devenue payante ou du moins ultra limitée dans sa version gratuite, j'ai réussi à sauver et adapter la soumission des nouveaux posts mais le retweet avait basculé du côté payant donc je ne l'ai plus utilisé. 

 

 

Là, je viens de découvrir que le re-Post est de nouveau accessible dans l'API gratuite mais à raison d'un retweet maximum par quart d'heure. Je pourrai peut-être adapter voir juste dé-commenter mon ancien code pour réactiver les rePost mais j'avoue que j'ai un peu déserté la plateforme donc les interactions sont devenues minimalistes. 

 

Pour Mastodon, j'ai implémenté techniquement le re-Post mais la décentralisation des interfaces rend difficile la prospection des messages, même s'il y a eu du progrès via la recherche inter serveurs. Il reste aussi la limitation des affichages des toots dans un site web tiers directement par le Javascript d'un navigateur vu la variété des domaines des différents serveurs.

 

Bluesky présente une décorrélation nette entre le serveur d'interface web pour les utilisateurs et les serveurs de gestion des messages et des médias derrière. En pratique, les utilisateurs moi y compris passent par bluesky.app, ce qui permet aussi l'insertion dans les pages web des aperçus des skeets aussi facilement que cela l'est pour l'ex-Twitter, étant donné que c'est centralisé en terme d'adresse web publique.

 

Les serveurs de données sont en revanche décentralisés et tout le monde peut monter son Personal Data Server ou PDS. Il y a un an, j'en étais resté avec la possibilité d'intégré son PDS sur l'environnement de test de Bluesky avec une interface web de dédiée mise à disposition par le réseau social. Le PDS était chez soi mais le client web chez Bluesky avec la possibilité de voir les skeets de tests des autres PDS. Le principe était de pouvoir faire des tests et d'éventuelles bêtises sur son PDS pour valider son application avant de se brancher sur les serveurs de données de production de Bluesky via les APIs. 

 

Quand j'ai remonté mon PDS en guise d'environnement de test, j'ai pu constater qu'il était directement relié au réseau principal des serveurs de données Bluesky. Il est considéré comme un serveur standard avec des messages diffusés à la demande, de la même manière qu'un serveur Mastodon pour le Fédiverse.  

 

 

Cela fait quelques temps que l'inscription peut s'effectuer sans code invitation sur le site web habituel de Bluesky mais pour s'inscrire sur son PDS, il faut rebasculer sur les formulaires avec code d'invitation. 

 

Par défaut, Bluesky donne des droits d'accès suffisants à son API donc j'utilise mon PDS que pour mes tests et pas pour mes vraies publications, même si vous pourriez voir mes messages d'essai via les comptes créés sur mon PDS. Avec son propre PDS en production permettrait de sécuriser mes publications quand les serveurs de Bluesksy toussotent lorsque des milliers de nouveaux utilisateurs arrivent d'un coup mais cela représenterait un peu plus de boulot pour le maintenir, à défaut d'avoir vraiment à le gérer car les inscriptions seront fermées. 

 

Une évolution qui m'a beaucoup moins plu sur Bluesky est leur nouvelle stratégie de plutôt mettre en avant leurs bibliothèques de code qui interagit avec le produit, plutôt que d'enrichir ou même juste documenter leur API HTTP. 

 

Le re-Post est une opération toute simple sauf qu'il faut coder dans les 2 langages de programmation qui sont supportés par les équipes de développement de Bluesky. Les gens qui codent dans d'autres langages peuvent aller se brosser car même si quelqu'un souhaite se lancer dans la programmation des bibliothèque, il n'y a que les écrits rédigés au début de l'utilisation du protocole at proto et des requêtes HTTP mais pas forcément de précisions sur les nouveautés.

 

Typiquement, il n'y a nulle part en clair comment composer une requête HTTP pour faire un re-Post ni même la séquence logique.

 

En tâtonnant et en faisant plus ou moins du reverse re-engineering, voici l'approche que j'ai retenue :

 

    • D'abord, récupérer l'url du skeet à reposter

 

Par exemple : https://bsky.app/profile/animint.com/post/3l7vd7xgj4h2q

 

À partir de là, récupérer le dépôt de l'utilisateur ou repo comme repository, à savoir ici animint.com et ce qui est appelé la rkey, à savoir  le code à la fin qui est ici 3l7vd7xgj4h2q

 

Étant donné que ce message est un post et pas un repost par exemple, la collection à la sauce Bluesky est spécifiquement app.bsky.feed.post.

 

    • Ensuite, demander des informations technique au PDS

 

Il est possible de demander des informations technique du message via la commande com.atproto.repo.getRecord en passant en paramètres

 

        ◦ le repo donc animint.com

        ◦ la collection donc app.bsky.feed.post

        ◦ la rkey donc 3l7vd7xgj4h2q

 

La fonction retourne plusieurs informations dont

 

        ◦ Le cid, l'identifiant unique du messages à rallonge, du genre

 

bafyreidrhrsdijorqvfoxsjvsui5wgvhrzacbpiimip24n3ly7ezpkzbjy

          

        ◦ L'uri, où on retrouve une partie des éléments de l'url mais dans un style abscon au début

 

at://did:plc:lisufijnrz42yoqth2stevje/app.bsky.feed.post/3l7vd7xgj4h2q

 

    • Enfin, envoyer la demande de création du rePost au PDS

 

L'ancienne documentation Bluesky et les bibliothèques existantes expliquent et montrent bien comment poster un nouveau message via l'API HTTP : Il s'agit de faire appel à la fonction com.atproto.repo.createRecord via la méthode POST en mettant en paramètre la bonne structure d'arguments. La structure peut rapidement devenir complexe dès qu'on commence à rajouter des médias, des liens ou encore des mots clefs. Il y a aussi les détails pour pouvoir citer des posts et pour pouvoir poster une réponse, avec l'exercice de mettre en référence le post initial à la réponse.

 

Pour le re-Post, c'est plus simple dans l'absolu car il suffit de donner les références du message avec le cid et l'uri, et pas grand-chose d'autre, sauf que rien n'est mentionné explicitement dans la documentation sur la structure à utiliser.

 

Voici la structures des arguments à passer, que j'ai adoptée et qui fonctionne :

 

  args = [

                        'collection' => 'app.bsky.feed.repost',

                        'repo' => <repo>,

                        'record' => [

                                '$type' => 'app.bsky.feed.repost',

                                'createdAt' => <date du rePost au format ISO-8601>,

                                'subject' => [

                                        'uri' => <uri>,

                                        'cid' => <cid>

                                ]

                        ]

                ];

 

Exemple :

 

  args = [

                        'collection' => 'app.bsky.feed.repost',

                        'repo' => animint.com',

                        'record' => [

                                '$type' => 'app.bsky.feed.repost',

                                'createdAt' => '2024-11-01T17:34:42+00:00',

                                'subject' => [

                                        'cid' => 'bafyreidrhrsdijorqvfoxsjvsui5wgvhrzacbpiimip24n3ly7ezpkzbjy',

                                        'uri' => 'at://did:plc:lisufijnrz42yoqth2stevje/app.bsky.feed.post/ 3l7vd7xgj4h2q'

                                ]

                        ]

                ];

 

 

Maintenant, j'en suis arrivé au stade où je peux copier coller une url Bluesky dans le formulaire de mon outils et choisir la date et l'heure à laquelle le message sera reposté. 

 

Pour Twitter, j'avais mon plugin local pour Chromium et Firefox qui m'enrichissait l'interface pour m'insérer carrément à l'écran de mon navigateur un icône supplémentaire sur chaque message pour ouvrir directement le formulaire prérempli avec le lien du tweet quand je cliquais dessus.

 

Le code web de Blueksy est plus complexe mais ce qui m'a stoppé dans mon élan est la nouvelle norme imposée par Google sur les extensions Chrome. Le passage obligatoires des manifests en version 3  – et les restrictions qui en découlent - est un moyen détourné de tuer les extensions qui bloquent la publicité sur les sites dont notamment YouTube. Dans mon cas, le plugin sera toujours possible à mettre en place mais il faut plus le réécrire que juste l'adapter. 

 

Cela fait trop de complexité à gérer en une seule fois même si j'utilise le navigateur Brave qui annonce rester compatible avec le format version 2 mais cela ne durera certainement qu'un temps et rien ne me dis qu'il ne faudra pas tout rejeter à la poubelle avec la future version 4. Je n'ai pas envie de tout recoder à chaque fois, juste pour économiser deux ou trois clics.

 

La dernière fonctionnalité que je regarderai plus tard est de vérifier que je peux à la fois retooter et reskeeter – et même retweeter – un de mes propres posts ou du moins de mes comptes satellites que sont AggregorSama et Kelmanga. Le principe est d'avoir une entrée dans mon outils pour la programmation du post de l'un ou l'autre des comptes secondaires et une seule entrée pour programmer le re-Post par mon compte Animint sur les réseaux sociaux plusieurs heures après. En pratique, c'est plus facile à gérer que les urls externes des posts car je n'ai qu'à retrouver mes messages dans la base locale de mon outil de publication.