J’ai réalisé un prototype de GVA permettant de faire un paiement !
Prototype réalisé en Rust async avec async-graphql et warp (framework web utilisé également par le projet Deno).
Pour le moment ce prototype permet de :
Consulter l’historique des transactions d’un compte
Consulter les sources de monnaie d’un compte (UTXOs uniquement)
Envoyer une transaction
Souscrire à l’événement « réception d’une transaction par le serveur »
Attention peinture fraîche, c’est une version de dev (pre-alpha), accessible ici : https://g1.librelois.fr/gva
J’ai réalisé une petite présentation vidéo dans laquelle je fais un paiement « à la main » :
Réaliser ce prototype m’a permis d’explorer techniquement beaucoup de choses qui vont être un fondement pour la suite. Cela à nécessité notamment la migration de la DB SQLite des transactions (qui contenait à la fois les transactions en mempool et l’historique des transactions).
J’ai dû créer deux nouvelles DB :
txs_mp_v2 : Une base de donnée contenant les transactions en mempool
gva_v1 : une base de donnée dédiée à GVA contenant pour le moment l’historique des transactions ainsi qu’une indexation des UTXOs optimisée pour les clients (càd par compte plutôt que par identifier).
Le code source est disponible sur la branche gva-proto.
La prochaine étape est bien sûr l’indexation des dividendes universel, c’est plus compliqué car cela demande d’indexer au préalable la liste des comptes membres. J’ai déjà conçu les collections nécessaires dans la DB, reste à les remplir.
Concernant la pagination, je propose d’utiliser les spécifications officielles de graphql, c’est ce que j’ai mis en place pour la consultation des UTXOs.
Le schéma va bien évidemment être modifié selon les retours des dev des clients, c’est juste un 1ᵉʳ jet
Wahou !! Je suis comme un petit enfants depuis le sapins de Noël !
Voila du concret pour me motiver à avancer sur Cesium2 !
Merci pour ce travail
Yes, je regarde ca aussi vite que je peux.
A ce propos un petit graphiql intégré à ton proto serait utile. Est-ce possible ?
Ca rend les tests plus accessible, je trouve.
Ton nœud donne une erreur 502, du coup j’ai essayé de compiler cette branche chez moi, mais la commande cargo xtask build ne marche pas :
Finished dev [unoptimized + debuginfo] target(s) in 0.06s
Running `target/debug/xtask build`
rustc 1.49.0-nightly (e160e5cb8 2020-10-14)
cargo 1.48.0-nightly (9d1a4863a 2020-10-05)
Check node version …
Install node v10.22.1 …
Install nvm v0.35.3 …
bash: #!/usr/bin/env bash
# ... ici il y a un long script bash qui semble devoir installer nvm ...
: Nom de fichier trop long
Je vais essayer d’intégrer GVA dans ĞMixer, les possibilités d’avoir la date d’une source et de souscrire aux transactions m’intéressent.
Bonjour à tous, je vous prie de m’excuser pour ma longue absence, un drame familial m’a demandé toute mon attention pendant plusieurs semaines, ce n’ai d’ailleurs pas fini, mais je commence enfin à pouvoir me poser un peu, pour tout vous dire il s’agit du décès de ma Maman (elle était d’ailleurs membre de la Ğ1 sous le username SylvieAude).
Depuis ce week-end j’ai retravaillé sur GVA et j’ai ajouté les sources de type Dividende Universel
Merci pour ton enthousiasme, ton soutien est important pour moi, c’est ce qui me motive à avancer
C’est déjà intégré sauf que j’utilise Graphql playground, un fork de graphiql que je trouve mieux fait, c’est accessible par le même endpoint, clique donc sur ce lien : https://g1.librelois.fr/gva
Oui c’est une version de dev donc encore instable, et comme je n’avais plus le temps de le surveiller… c’est rétabli maintenant
Ok alors tu peux faire à l’ancienne façon, installer node 10 via nvm puis compiler avec la commande npm install. Tu peux aussi m’aider à comprendre pourquoi mon script Rust ne fonctionne pas comme attendu sur ta distrib
J’ai moi aussi été touché cette année par la perte de mon père début mars. Toute mes condoléances…
Merci pour ton travail.
Je vais vérifier que ma branche client graphQL de DuniterPy fonctionne avec ton prototype et si oui on sortira une nouvelle version avec des exemples basés sur ton schema !
J’essaie d’envoyer une requête, mais j’ai erreur 400 Bad Request en réponse…
Peux-tu regarder si tu me vois me vautrer à ta porte de serveur et me dire ce qui cloche dans ma requête ?
A tu testé préalablement ta requête sur le playground puis avec curl ?
Je te vois dans les log de nginx mais pas dans les log de Duniter. Nginx bloque tes requêtes, peut être parce qu’il manque un body ? Essaye une requete (par exemple le montant du DU):
J’ai gardé les mêmes conventions que pour les autres types d’endpoint à une différence près : la couche TLS est explicitée par un S. Cela permettra à ceux qui le souhaitent de pouvoir fournir un endpoint sécurisé sur un autre port que 443 (via l’option remoteTls, voir doc).
Maintenant j’aurais besoin qu’un ou deux d’entre vous essayent de mettre en place un serveur GVA, voici comment faire :
Indexez la db de GVA, 2 méthodes possibles :
A. Avec la commande dex migrate (nécessite de compiler le binaire dex au préalable). L’indexation prend environ 2 minutes ce qui est bien plus rapide que de resynchroniser Duniter, donc même en comptant le temps de compilation de dex cette méthode devrait rester plus rapide.
B. Vous pouvez aussi resynchroniser Duniter avec l’option --gva (duniter sync --gva g1.duniter.org) mais cette méthode est plus longue forcément
Configurez GVA en modifiant directement le fichier conf.json, voici ma conf par exemple :
De mon côté je suis charette sur des fins de projet pour mon boulot. Donc pas eu le temps d’avancer sur Cesium2…
Ne t’excuses pas @elois :-).
Concernant la mauvaise nouvelle que tu annonce, je ne sais pas trop quoi te dire…
Saches en tous cas que cela me touche pour toi. La vie est vraiment quelque chose de fragile… et reste pour moi un mystère.
Du coup j’ai pu le compiler, j’ai bien accès à l’interface web GVA, mais :
dex migrate a pris environ 10 minutes après avoir affiché le dernier message « Apply chunk » sans rien dire, à écrire à 16 Mo/s dans le disque. Ça serait bien d’ajouter un message pour qu’on ne se dise pas que ça a planté. (oui j’avais oublié de le copier dans la RAM)
L’option --home PATH place le dossier de duniter à ~/.config/duniter/PATH apparemment, donc j’ai mis longtemps à comprendre pourquoi avec --home /dev/shm/duniter rien ne marchait (sauf l’interface web GVA, mais les requêtes renvoyaient des résultats vides), jusqu’à voir que tout était dans ~/.config/duniter/dev/shm/duniter…
Chez moi ça prend 1m39s en tout, et que quelques secondes après le log du dernier chunk.
Tu es le premier à tester sled sur HDD (je n’ai que des SSD depuis des années, donc je ne pouvais pas tester).
sled est optimisé pour les SSD, mais je ne pensais pas que les perfs seraient si mauvaises sur HDD, je suis en train de regarder du côté de RocksDb mais c’est aussi optimisé pour SSD donc ce sera peut-être pareil, on verra à l’expérience. En vrai je pense que quel que soit le sgdb choisi les HDD sont de toute façon beaucoup trop lent pour le type de traitement que Duniter doit faire (indexation en particulier).
Il y a déjà un message de succès à la fin. Je viens d’ajouter un message intermédiaire pour le flush.
Ça ce n’est pas normal, je viens de vérifier dans le code et l’option --home est codée pour se comporter comme un home absolu, c’est avec le binaire dex ou duniter que tu as eu ce souci ? Que j’essaye de reproduire ! EDIT: bug trouvé et corrigé
Et du coup ça y ai ton playground GVA fonctionne ? Une screen ?
Le endpoint GVA est normalement déjà ajouté à la fiche de peer relayée par WS2Pv1, d’ailleurs si tu regardes les fiches de peer sur le réseau tu vois les 3 nœuds GVA : https://g1.elo.tf/network/peers
Je l’ai déjà indiqué dans le message #14 que tu à lu puisse que tu l’a liké
