Suite à la proposition de @Galuel de créer une barre de progression intégrable pour les financements participatifs, je crée ce topic pour centraliser les contributions et les débats autour du sujet. Pour ma part, j’ai commencé à me pencher dessus, bien que je ne sois pas le seul.
Après avoir réalisé une maquette en HTML/CSS/JS, je commence maintenant la partie programmation (en PHP). J’aimerais donc récupérer, sur une pubkey, la liste des transactions entrantes entre deux dates pour compter le nombre de contributeurs distincts et faire la somme des contributions.
Or, il paraît que les nœuds ES ne sont pas tjrs synchronisés. Y’a-t-il un moyen plus efficace ? (sans forcément interroger un nœud Duniter local, bien qu’à mon avis, cela soit peut-être le plus fiable). Peut-être via l’API BMA ?
Dans tous les cas, quelqu’un pourrait me donner un exemple pour extraire les données qui m’intéressent ?
J’aimerais aussi savoir si il existe un moyen de vérifier qu’un champ STRING correspond bien à une pubkey (la longueur de chaîne par exemple).
Pour l’instant, je proposerai un iframe à intégrer du type :
Oui tant que GVA n’est pas encore disponible il faut utiliser BMA, je vois que tu a trouvé tout seul la requete a effectuer, en effet c’est tx/history/[pubkey]/times/[from]/[to]
Voici la regex utilisée par Duniter : (dans app/lib/common-libs/constants.ts)
Les transactions n’ont pas de montant, il te faut les extraires toi-même de la transaction : oui BMA c’est pas la joie pour les clients (GVA intègrera une notion de movements proposée par Benoit, ce qui permettra de récupérer directement le montant d’un “mouvement” de monnaie).
La il te faut sommer les outputs ayant pour condition SIG(A) ou A est la pubkey qui t’intéresse.
Je me suis dit « les virements sur cette clef sont super étranges » avant de comprendre que c’est un tripot.
Assez blablaté, je casse tout
Quand j’indique une end_date passée, le champs « jours restants » m’indique, en valeur absolue, la différence avec la date actuelle. Je voyage dans le temps ! Voir :
Quand la end_date est avant la start_date, l’affichage est simplement à zéro. Une fonctionnalité sympa pourrait être de mettre un warning, certain.e.s pourraient faire l’erreur. Une telle erreur ruine le lancement d’un financement participatif.
OUAH ! Il prend en compte le début du financement ! Donc on peut avoir le (montant sur la clef) != (montant du financement), et régler une période d’observation ! C’est génial !
ne prend pas en compte les montants à virgule (c’est une feature inutile mais j’ai voulu essayer)
Quand je prends une large période (depuis le début de la Ğ1), le montant du financement indiqué est différent du montant sur la clef, mais également différent du montant total des recettes. -> qu’indique donc le montant du financement ?
@Paidge l’explication la plus probable est que tu à sync sans l’option --store-txspuis que tu a activé cette même option après (sans resync totale entre temps), ce qui fait que tu n’historise que les tx récentes. Si c’est ça une seule solution: reset data && sync (avec l’option --store-txs dés la sync).
J’ai corrigé le code de l’iframe pour gérer les erreurs de saisies que tu as soulevées et j’ai resynchronisé mon nœud comme indiqué par @elois .Voici le résultat depuis le début de la june sur le même compte de tripot ^^ J’obtiens 4927.75Ğ1 entrants.
Or, lorsque j’analyse le compte avec Cesium et que je fais la somme des recettes à partir du camembert ou de l’histogramme, j’obtiens 4757.85Ğ1 entrants…
J’ai donc un delta de 169.9Ğ1. Je vais essayer de voir d’où ça vient cet a-m mais si qqun a une idée, ça m’intéresse
Surement le backchange (le retour à l’envoyeur lorsque tu coupes une source trop grande en deux) dans le document de transaction que tu ne prends pas en compte.
Je souhaite faire un virement d’un montant m vers un compte U.
Mon client va faire :
a+b+c = M tel que M >= m
m est envoyé à U.
f = (M-m) est le « backchange » qui par défaut dans les clients existants, est renvoyé sur le compte d’envoi T. Le compte a donc pour nouvelles sources :
d,e,f
Donc si vous prenez uniquement en compte les inputs et que vous oubliez le Backchange, vous devez tomber sur un montant, euh… inférieur au montant du compte (là mon cerveau me joue des tours, je ne suis pas bien sûr).
Je ne sais pas si c’est ça, mais j’espère avoir explicité ce qu’est le backchange.
Franchement super boulot !
J’aime beaucoup ce que tu as fait, avec la date de début, de fin et la somme à atteindre paramétrable dans l’URL.
C’est quoi une iframe pour faire rapide ?
Tu nous fais une barre de financement pour financer la libération du code de ta barre de financement ? Eat your own dog food.
Pas tant que ça : sur gannonce.duniter.org il me semble que pas mal de personnes utilisent leur compte membre.
Tu veux dire que c’est normal de ne pas prendre en compte les DU dans le cas d’un financement participatif ? En tous cas, pour moi ça paraît normal de ne pas les prendre en considération.
Pour le cas d’un compte membre écrivain, on pourrait exclure les transactions dont le commentaire commence par REMU. Qu’en pensez-vous ?
C’est un document HTML dans un document HTML. Exemple d’intégration :
Je vais aussi paramétrer le nœud interrogé. Pour l’instant il est en dur dans le code mais on pourrait avoir un paramètre optionnel “node” qui, s’il n’est pas renseigné, irait chercher sur g1.duniter.org par exemple.
