C’est ça ! Tu as compris ! Et résumé en 2 lignes en +
Ouf, j’avais peur d’avoir fait du bruit pour rien…
Ok, on avance. Un autre problème que je n’ai pas résolu encore, c’est la possibilité de merger 2 schémas Graphql (ou remote joins ou schema stitching). C’est une porte d’entrée vers une architecture micro-services.
L’idée est d’utiliser la pubkey comme référence pour récupérer les données de GVA et mes données en une seule requête, avec comme relationships entre ma bdd et GVA : user.pubkey = idty.pubkey et/ou user.pubkey = balance.PkOrScriptGva.
Et hop ! En une requête j’ai tout :
query fetchUser($id: uuid!) {
id
mail
gva {
idty {
username
isMember
}
balance {
amount
}
}
}
Sauf, que je n’y arrive pas Je ne peux pas merger l’api GVA avec mon api, car mon pubkey est de type String et pas de type pubkey ou PkOrScriptGva. En tout cas, avec Hasura, je n’ai pas réussi à le faire alors qu’ils sont pourtant compatibles Apollo Federation.
@elois Je ne demande rien pour l’instant ! C’est juste pour faire remonter mon expérience. Il faut que je fasse d’autres tests…
@tuxmain est-ce que tu crois que tu pourrais ajouter à la commande idty GVA l’arguement username pour rechercher une pubkey par username ? J’en ai vraiment besoin
Pour rechercher comment ? Je peux faire facilement « commençant exactement par » (ou insensible à la casse, si besoin), mais « contenant » ou en tolérant des fautes, c’est plus compliqué. (c’est faisable mais ça prendra trop de temps à répondre)
Tu veux seulement la pubkey, ou aussi les autres champs de idty, ce qui peut économiser une requête ?
Ça ne fait que le match exact, et ça renvoie exactement les mêmes données que idty(pubkey). (et j’ai ajouté un champ pubkey dans la réponse)
C’est plutôt à des services comme Cesium+ de fournir une recherche avancée, et pour les utilisateurs un tel service serait plus intéressant que GVA qui ne saurait faire que les majuscules et le « commence par », donc je ne l’ai pas fait.
Ah mais ça veut dire ajouter tout le bazar pour renvoyer une liste !
Et si la taille max est 100 ça veut dire qu’on peut renvoyer jusqu’à 2^100 résultats, donc il faut paginer.
Et il y a plusieurs manières pour la db : username(insensible) -> HashMap<username(sensible), pubkey> ou username(insensible)+username(sensible) -> pubkey
Il faudrait aussi ajouter un champ case_sensitive vrai par défaut.
Mais je me disais que si cette fonctionnalité est utilisée, c’est forcément pour la recherche par un utilisateur, or un utilisateur voudrait un truc plus sophistiqué (regex, Levenstein, soundex…). Cesium+ ne fait pas encore aussi complet mais fait déjà mieux que juste la casse. Donc je doute de l’utilité d’une telle fonctionnalité.
Ben c’est demandé par @kimamila l’insensibilité à la casse donc si c’est utile.
Pas besoin de faire aussi compliqué, keep it stupid simple: stocke la clé en uppercase et passe par un set (key: username(uppercase) ++ pubkey, value: ()).
Puis récupère les vrais usernames dans BcV2.
Le plus simple c’est de remonter une liste tout le temps puis de filtrer au niveau du resolver si on veut que ça match exact.
Je n’ai pas de champ gva dans cette conf par défaut il s’agit d’un noeud docker, dont les paramètres du noeud sont passés en variables d’environnement via le docker-compose.
Quelqu’un saurait comment éditer cette whitelist, ou bien assouplir les valeurs de l’anti-spam, ou bien carrément le désactiver ?
On ne peut pas passer une tableau en variable d’environnement:
ERROR: The Compose file './jinja-compose.yml' is invalid because:
services.duniter.environment.DUNITER_GVA_WHITELIST contains ["127.0.0.1", "::1"], which is an invalid type, it should be a string, number, or a null
Il aurait fallut attendre une suite de string séparé par des virgules, et split la chaine ainsi…
De toute manière ce qui m’intéresse, c’est surtout pour changer les valeurs de ce filtre anti-spam.
Je constate qu’il n’est pas réglé comme indiqué par elois, il suffit d’envoyer 5 requêtes successives pour se faire ban.
@poka : Peux-tu me pointer la version des sources que tu utilises ? Car comme dit plus haut, je ne trouve aucune référence à cette variable sur la branche dev.
Pour l’explorateur de TdC en 3D que j’ai commencé, j’ai besoin de construire les index à partir du dump JSON. Mais la gestion de la toile de confiance est un peu délicate à coder, et très délicate si on veut de la performance. Et j’en veux. (un des buts est de voir l’évolution de la TdC et de la monnaie en accéléré)
Du coup je vais essayer de finir ce que j’avais commencé et abandonné sur GVA, les requêtes sur les certifications et les usernames. Comme ça une grosse partie du code (j’espère) pourra servir à ce projet, ça évitera de recoder exactement la même chose.
Je suis également sur la branche dev.
Je ne sais pas si cette variable est implémenté comme indiqué dans la doc, mais ce qui est sûr c’est que même si c’est le cas, on ne pourrait pas se servir d’un array comme variable d’environnement via docker-compose.
C’est une super nouvelle si tu te remet sur GVA
Étant donnée l’abandon d’Elois, la migration substrate va prendre beaucoup plus de temps que prévu, il est donc très probable que l’on sorte Gecko d’abords sur GVA.
Ce qu’il me manque en priorité:
Rechercher par username: Répondre les clés publiques associés au username recherché, avec boolean isMembre et solde tant qu’a faire. Pour le moment Gecko utilise la requête wallets de GVA pour la recherche par username, avec réception d’un JSON contenant tous les wallet d’un coup, mis en cache. Cela fonctionne bien, mais je passe par g1-stats qui fourni un json à partir de cette requête toutes les heures (peut être réduit) (et mis en cache pour 20 minutes côté client). C’est donc évidemment une solution de contournement provisoire (mais on sait tous que le provisoire, parfois, ça dur…)
Rechercher des bouts de clés publiques: Répondre la liste des clés publiques qui matchs parmi les membres ainsi que les portefeuilles ayant un soldes non null (même liste que celle renvoyé par la requête wallets. Devrait répondre clé complète, username, isMembre et balance.
Régler ce filtre anti-spam correctement: J’ai beau regarder dans le dépôt duniter-gva/src/anti_spam.rs, je ne comprends pas le comportement observé en condition réelle comme indiqué plus haut.
Pouvoir émettre un document d’adhésion, de certification et de révocation: Je sais que c’est certainement le plus gros des points. Si GVA ne le permet pas, je devrais passer par BMA pour se faire dans Gecko.
Passer Duniter 1.9 en prod: Cela fait des mois que je le test en live et qu’il semble stable (nœud up sans reboot plusieurs mois consécutifs, aucun bug à signaler). Ceci afin qu’un maximum de mainteneur de nœuds puissent les mettre à jours et ainsi rendre GVA accessible en masse.
Ceci pourrait être fait avec simplement les 3 premiers points d’accompli, pas nécessairement avec la gestion des documents de certification.
Ça fait un peu liste au père noël, je sais. Je ne sais pas si tu trouvera le temps de faire ça @tuxmain , ou quelqu’un d’autre, mais sait-on jamais
Je ne peux pas merger l’api GVA avec mon api, car mon 
