Je voudrais utiliser une meilleure façon de surveiller un portefeuille pour y détecter un nouveau virement que par requête régulière sur son contenu. Il doit être possible de surveiller les nouveaux blocks de la chaine.
Connaissez-vous un code simple pour y repérer une expression et déclencher un trigger?
C’est pour pouvoir contrôler l’impression de G1billets à partir des sommes reçues sur un compte…
SAlut @Frederic_Renault 
Tu peut utiliser le websocket des blocs fourni par BMA : doc/HTTP_API.md · dev · nodes / typescript / duniter · GitLab
Mais ça t’oblige a extraite toi même du bloc brut l’info qui t’intéresse.
Ce que tu demande sera possible nativement dans GVA (nouvelle API client qui devrait arriver d’ici 6 mois environ) grâce aux souscriptions Graphql.
Dans les 2 cas ça passe par du websocket (ws://)
salut @elois
Je cherche surtout à trouver des bouts de code pour pas rendre un brouillon trop crado sur le stratagème ONE ❤ Ḡ1 Jukebox Café
Des exemples de code utilisant des websockets coté clients tu en a tout plein sur internet et dans tout les langages 
@elois, à partir de la liste Jean-Yves / simple-node-watcher · GitLab je voudrai invoquer le sortilège système avec les bons ingrédients Mais il me faut le bon port BMA pas forcément le même partout?
ws ws://g1.duniter.org:10901/ws/block me renvoi une sacré soupe… Avec un regexp sur la clef publique surveillée, je peux surement y détecter une TX, mais il faut que je ne rate pas un bloc! Ce qui augmente ma fréquence de requête…
Hélas oui chaque propriétaire de nœud est bien libre d’exposer l’api bma sur le port de son choix, j’avais proposé que par convention ce soit le port 10900 pour g1-test et 10901 pour la g1 mais très peu de nœuds respectent cette convention.
Sinon a partir d’un seul nœud connu “en dur” tu peut découvrir le réseau en requétant l’url bma : /network/peers doc/HTTP_API.md · dev · nodes / typescript / duniter · GitLab.
Tu peut alors parser l’endpoint BMA des nouvelles fiches de peer ainsi obtenus
Non au contraire, ça diminue ta fréquence de requête puisque tu ouvre le websocket une seule fois par nœud auquel tu te connect et tu reçoit les nouveaux bloc en continu sans avoir a refaire de requête, c’est le but des websocket !
Faut que je rende compatible le trigger websocket avec mon bus d’échange d’événements (fichier fifo en fs ou ramfs, ma DB à moi)
Y’a un ordre intrinsèque à cette liste? curl https://g1.cgeek.fr/network/peers
Non aucun
@elois, Tu veux dire ça sort au pif, en fonction du noeud et de sa découverte?
Fonctionnellement ce n’est pas une liste ordonnée, donc il n’y a pas d’ordre, donc il ne faut pas se baser dessus, c’est tout. Forcément les éléments s’affichent dans un certain ordre mais le pourquoi on s’en fou ça dépend de comment c’est implémenté donc ça changera d’une implémentation a l’autre.
Si elle était ordonnée par noeud le plus « dispo », ça pourrait donner un point commun aux clients pour savoir où envoyer leurs requêtes au réseau et aider au load balancing.
Pour ça il faudrait déjà une définition de “nœud le plus “dispo””, cette notion n’existe tout simplement pas dans BMA.
est ce que nous avons de mieux… Il faut juste lui donner un nodes.txt rafraîchi à la liste courante…
Je en vois pas le rapport avce simple-node-watcher, ça permet de voir quel nœud est sur quel branche de fork, aucun rapport avec toute notion de disponibilité donc
L’appel BMA ne m’indique pas si il y a un fork? Ca ne sert à rien d’envoyer sa TX à un noeud en fork…
En passant les données de l’un dans l’autre, je voudrais récupèrer une liste des noeuds « synchronisés » aptes à encaisser des TX.
Au fait, quelle est la taille de la piscine par défaut avant débordement?
curl https://g1.cgeek.fr/network/peers | jq '.peers[] | .endpoints'
@jytou ?
Je crois qu’il te manque des bases fondamentales sur la notion de fork, BMA est l’API client d’un nœud, elle te fournie les informations du point de vue du nœud requété. Or, par définition un nœud est toujours sur la “bonne” branche de son propre point de vue, il ne peut donc pas te dire s’il est sur un fork ou non, s’il considérait être sur un fork alors il aurait switché sur la branche qu’il considère être la bonne.
C’est comme si tu demandais a quelqu’un de sur de lui (les noeuds sont sûr d’eux) si sont point de vue sur tel sujet est le bon, s’il a tel point de vue c’est qu’il pense que c’est le bon, dés l’instant ou il penserai que tel autre autre point de vue est plus correct, il l’adopterai alors, de tel sorte qu’il répondrais toujours “oui” a ta question.
Tu liste ici 2 propriétés tout a fait différentes, un nœud peut être “synchronisé” mais pas apte a recevoir des tx, et vice versa. La seconde propriété étant trop coûteuse a mesurée, il est beaucoup plus efficient d’envoyer des tx à p noeuds parmi n (le tout étant de choisir une valeur de p suffisamment élevée pour avoir une forte garantie d’aboutissement de tes tx et suffisamment faible pour ne pas trop surcharger le réseau, je pense que p=3 est une bonne valeur ).