Simplified Verification API

Il serait plus propre de tout faire avec un seul endpoint et de fixer une convention décrivant les différents paths et modes associés :slight_smile:

Oui il vaut mieux faire un seul endpoint, si je reprends mon exemple, une chose comme :

GVA monserveur.test 80 /graphql /graphql/subscriptions
1 Like

J’ai défini un format générique pour les endpoint qui ne permet de déclarer qu’un seul path optionnel, ce qui est préférable pour simplifier aussi la configuration coté utilisateur.
Il me semble donc plus efficient de déclarer un seul path dans l’endpoint GVA et de considérer par convention que les subscriptions se font sur le “sous-chemin” : path/subscriptions :slight_smile:

2 Likes

On peut faire ce qu’on veut, oui. De là à parler d’efficience, je dirais que c’est beaucoup d’agitation pour pas grand-chose.

Finalement j’ai opté pour un endpoint explicite, plutôt que implicite avec un truc en dur planqué dans le code. Plus clair et plus de liberté sur les pathes pour l’utilisateur :

GVA|GVAS [DNS | IPv4 | IPv6] [PORT] [PATH] [SUBSCRIPTIONS_PATH]
1 Like

@vit, le problème c’est que j’ai proposé dans la RFC WS2Pv2 un format générique pour tout les endpoints des APIs qui doivent être connues par le cœur (et c’est le cas de GVA), et j’ai commencé à l’implémenter dans durs. Donc il faut que tu te conforme au nouveau format générique, ou que tu me demande de modifier ma RFC (mais bon je vous ai laisser du temps pour la relire et c’était justement pour éviter ce genre de problèmes :laughing: )

Le format générique appliqué a GVA donnerai ceci :
GVA 1 HOST PORT PATH

Et avec TLS :
GVA 1 1 TLS HOST PORT PATH

Avec IPs :
GVA 1 3 TLS IP4 IP6 84.16.72.210 2001:41d0:8:c5aa::1 PORT PATH

Ça permet de ne pas avoir a coder dans le cœur un parser différent pour chaque API qu’il doit gérer. Et aussi de réduire considérablement la taille des fiches de peer qui transitent sur le réseau : or en terme de scalabilité c’est significatif car les fiches de peer c’est le document le plus partagé sur le réseau !

Les spec sont ici, si tu veut qu’on les modifient c’est maintenant car j’ai déjà commencé a l’implémenter : https://git.duniter.org/nodes/common/doc/blob/ws2p_v2/rfc/0006_ws2p_v2.md#endpoint-utf8-format

Ok, je suis ton implémentation.

[Edit] Pardon, tes spécifications. Soyons précis… :wink:

1 Like

Y aurais-t’il un noeud exposant le GVA (même de façon incomplete) ?

Non, pas à ma connaissance.

GVA verra sûrement le jour sur Durs (l’implémentation des noeuds en Rust par @elois) avant d’être sur Duniter, car aucun développeur Typescript n’est sur le coup côté serveur.

Je rédige le schéma GraphQL de la RFC uniquement parce que je vais m’occuper de la librairie cliente en Python (Duniterpy).

1 Like

Un peu de lecture : GraphQL: Et pour quoi faire ?

2 Likes

Je penses que je vais débuter l’implémentation sur Duniter (TS) d’ici la fin de l’année, en parrallèle de la refonte de Cesium 2. J’suis bien motivé. Et puis je penses qu’il faut maintenir Duniter, encore de longue année, car il fait bien son boulot :slight_smile:

Ma seule question est de savoir ce qu’en penses @cgeek, vis à vis de ces travaux sur la 1.7.
Est-elle mature pour débuter GVA dessus ?

Dans Cesium 2, je vais commencer par la consultation de la la WoT : annuaire (pending, members, lookup), puis consultation de l’identité, des certifications
Je m’attaquerai ensuite à “Mon compte” : transfert, action de certification, etc.

1 Like

Si tu commence l’implémentation dans Duniter, tu pourrais dans le même temps mettre à jour la RFC (le schéma GraphQL proposé principalement). Ce qui me permettrait d’implémenter parallèlement dans Duniterpy pour Sakia.

Je pense qu’on peut commencer par dupliquer les fonctions qui sont rapides de BMA vers GVA.
Puis d’ajouter des fonctions d’historiques qui nécessiteront de créer une nouvelle database dédiée pour GVA côté serveur pour optimiser les requêtes.

1 Like

Tu peux travailler directement sur cette version, du moment que tu passes par l’objet server.dal et ses sous objets d’accès aux données. Tu auras accès à tout ce que tu as besoin.

Actuellement la v1.7 est assez stable mais je ne suis pas satisfait de Loki. J’étudie en ce moment d’autres solutions en profitant de l’abstraction en Dao opérée avec la migration vers Loki. Mais à la limite ce n’est pas ton problème, toi tu travailles avec les objets proposés.

Bien évidemment si tu as des besoins supplémentaires il est possible de rajouter des méthodes.

1 Like

du moment que tu passe paR
je suppose ?

2 Likes

Maintenant, oui. Je ferai une présentation là-dessus pendant ma conf aux RML12.

2 Likes

Salut, 1 an plus tard est-ce qu’il existe des nœuds qui expose GVA même de manière incomplet. Le but étant de pouvoir commencer à faire des prototypes d’application client (G1liens) ?

1 Like

Non, pas encore.

@cgeek a présenté un début de développement pour Duniter aux RML14.
@elois et son équipe prépare un module pour Dunitrust.

C’est donc en cours (heavy development comme disent les anglais)…

1 Like