bsky

laem

• Première démo d'une connexion oauth à bsky et d'écriture du post bsky ✅ 
• [x] je ne pige pas pourquoi le client.init() ne récupère pas la session via le indexedDB comme sur la démo officielle
  • ça semble marcher dans un nouvel onglet "pur", va savoir pourquoi

OK maintenant il faut qu'on résolve deux problèmes : faut-il définir notre propre lexicon "app.cartes.comment" ? Ça me semble nécessaire, sinon les commentaires apparaitront sur le fil des comptes bluesky, ce qui posera problème à plein de gens. Le fait qu'ils soient publics, c'est une chose, et une contrainte dure, mais les mélanger au profil qui peut être pseudonyme par exemple, ce n'est pas cool.

J'ai compris que définir un lexicon c'est définir un record (les données, exemple skylights ici) mais aussi des fonctions de récupération. Mais sont-elles obligatoires ? J'ai l'impression que skylights n'en définit pas.

Doc officielle :

Of course, they may use the already existing PDSs and Relays in the network in order to ingest all relevant user data. But to create views of the underlying records, they will need to index that data and provide views over it.

In order to facilitate open and swappable APIs, developers should create and publish lexicons that describe the API routes for their service.

Le fait de créer cette vue, c'est quoi ? C'est un simple API vercel qui va récupérer tous les records de type comment et en fait des fonctions pour récupérer les comments d'un lieu ? Faudra-t-il créer une base de données pour les mettre en cache pour éviter que ce soit trop lent ? On peut déjà sortir une v1 sans le cache avec un appel systématique si jamais il répond vite pour moins de 1000 commentaires dans la nature.

Ensuite, j'ai l'impression qu'on pourra utiliser app.bsky.embed.images pour les images. Ce serait cool. ici. Exemple.

Avant de mettre en ligne

• [x] vérifier que notre MAJ de @atproto/api n'a pas cassé les commentaires du blog
• [x] bien réfléchir à la v1 du lexicon qu'on utilisera pour la phase de test

1. laem

   OK c'est ce guide parfait qu'il me fallait. https://atproto.com/guides/applications

   Il explique comment utiliser le Firehose pour consommer le Relay officiel et donc collecter les records de notre type.

   Ce que je ne pige pas, c'est est-ce que le Firehose({filterCollections: ['app.cartes.comment']}) va rattraper le réseau, ou juste donner les nouveautés ? Si 1), alors si on perd notre BDD on perd des informations définitivement. J'ai du mal à le croire. La BDD ne devrait être qu'un index, pas la source de vérité. Ça me rassurerait.

   Je ne trouve rien à ce propos.

   Ah si ! C'est Jetstream, une version plus simple du Firehose qui semble adaptée. https://github.com/bluesky-social/jetstream. Avec son option "cursor".

   Voilà un exemple /websocat.x86_64-unknown-linux-musl wss://jetstream2.us-east.bsky.network/subscribe?wantedCollections=my.skylights.rel&cursor=1735745918000 | grep "record"

   Je ne vois pas d'autre év que identity ou account. À xplorer.

   En tout cas ça marche avec ./websocat.x86_64-unknown-linux-musl wss://jetstream2.us-east.bsky.network/subscribe?wantedCollections=app.bsky.feed.post&cursor=1735745918000 | grep "commit".

   Avec ça, ça me semble assez facile de coder l'index, seulement si ces événements d'identité ne noient pas le reste, rendant le retour en arrière trop pénible. Ça nuance un peu ma vision de l'utilité de se greffer sur Bsky/AT, mais quand on inclue le fait d'éviter aux gens de créer un nième compte, et le fait que le réseau serve de sauvegarde fiable, ainsi que la vision mes données où je veux, ça semble une super solution tout compte fait. En passant au fediverse, je pense qu'on devra tout stocker tout seuls sur notre instance.

   Ah, je vois que les événements identité et account sont quand même sensés être assez rares.

2. laem

   ⏳ j'arrête pour cette semaine, c'est déjà une belle exploration.

3. laem

   OK première implémentation avec un serveur https://codeberg.org/cartes/serveur/pulls/83.

   Ça marche !

   • tester la resynchronisation de la BDD <- pas simple, Jetstream ne revient que 3 jours en arrière. Ce qui nous laisse le temps de corriger une prod pétée. On fait une erreur si enregistrement foireux, il faudrait ajouter une notification
   • intégrer proprement l'ajout et la lecture des commentaires d'un lieu
   • ajouter la note avec un slider moderne rouge -> vert de 10 points <- dans une futur PR, pas de notes pour l'instant, juste des commentaires et des images
   • mettre en prod
     • côté bsky, tester l'authentification sur dev.cartes.app
     • côté serveur, pas très compliqué car ils ne fait pas grand chose, entrée nginx et hono sur serveur deno-update
4. etienneJr

   Je n'ai pas bien suivi : il faudra avoir un compte bluesky pour pouvoir poster des commentaires ?

5. laem

   Je n'ai pas bien suivi : il faudra avoir un compte bluesky pour pouvoir poster des commentaires ?

   Oui. Enfin ATProto, mais en pratique il n'y a aujourd'hui qu'essentiellement bluesky comme gros acteur d'identité ATProto.