Demandes récurrentes sur Cesium => évolution de Duniter ?

@inso, @elois je ne dis pas que c’est la solution “la plus parfaite”.
Je demande juste que soit étudier ici un compromis, qui au moins pendant quelques années, pourraient simplifier la vie de ceux qui (comme moi) indexent et exploitent les blocs de manière simple (sans maintenir une balance bloc à bloc) pour ajouter des fonctionnalités aux logiciels clients.

Noubliez pas aussi que les noeuds de traitements et d’indexation (comme les pod Cs+) ont aussi besoin de faire des rollback (en cas résolution de fork). S’il faut maintenant gérer le solde de chaque compte, cela signifierait un revert bloc à bloc… cela complexifiera vraiment la gestion des rollback…

1 Like

L’une ou l’autre des solutions me convient. reste à voir ce que @cgeek en pense… et surtout ce qu’il a le temps de faire.

Oui, ce serait bien mieux.

Moi je n’y vois aucun problème.

L’indexation des données

Comme vous le savez, le nœud est le cœur du réseau. S’il bug, c’est tout le reste qui s’effondre. Or il est un fait établi désormais que plus un programme comporte de lignes de code et plus statistiquement celui-ci comporte des bugs. Donc, évitons de lui faire porter la responsabilité de répondre à des besoins qui ne sont pas les siens.

D’ailleurs vous comprenez bien que les besoins d’un client ne sont pas forcément ceux d’un autre, par exemple Cesium touche un peu à toutes les données (WoT, transactions) tandis que WotWizard se fiche des transactions. Et donc si l’on commence à assouvir les besoins de ces clients, où allons-nous nous arrêter ? Faudra-t-il demain créer un index très spécial pour pouvoir remonter les transactions insérées un jour de pleine lune pour le fameux service “Transactions Haute Marée” ?

Par conséquent vous comprenez ma position : le nœud doit avoir le moins de responsabilités possible et se concentrer sur son unique rôle : assurer le respect du protocole. C’était le sens de WS2P, qui permet à la fois aux nœuds de se protéger d’attaques DoS et de limiter le trafic réseau à l’exécution du protocole, donc d’éviter le trafic lié aux clients.

J’ai bien conscience aussi que sans clients, on a beau avoir un protocole hyper secure et un code sans bugs, ce même code ne sert alors à rien !

Mais c’est justement là qu’entrent en jeu les indexeurs, programmes tiers capables d’extraire l’état d’un nœud, de le transformer afin de rendre ces données exploitables dans un but précis. Ainsi un indexeur dont le rôle est de fournir des infos pour un WotWizard n’organise pas ses données de la même façon qu’une place de change qui elle ne s’intéresse qu’aux transactions, ou que ne le fait le Pod Cesium+ qui s’intéresse aux données de façon plus large mais toujours orientée vers l’utilisateur lambda, ou encore que ne le ferait l’indexeur Haute Marée.

Existe-t-il déjà un indexeur qui serait capable de fournir rapidement les informations demandées par @kimamila ? La réponse est oui ! Le nœud Duniter peut fonctionner en mode miroir, son rôle n’est alors pas tant de faire respecter le protocole que d’en conserver une image, pour des besoins d’exploitation qui regardent son hébergeur. Celui-ci pourrait par exemple y installer le module GVA API afin de répondre à un besoin d’extraction de données plus performant et adapté que BMA aux besoins basiques de clients Duniter.

Et la suppression de sources ?

Un module Duniter peut tout à fait stocker ses propres données, et par exemple mémoriser les sources supprimées ainsi que les oublier en cas de revert. C’est très simple à réaliser.

Je résume donc ma pensée :

  • le code du cœur doit se concentrer uniquement sur le protocole, et ce code est pensé exclusivement pour les membres calculants
  • pour les besoins externes, créer des services tiers qui indexent eux-mêmes les données des blocs. Il existe déjà un indexeur facile à réutiliser : le nœud Duniter en mode miroir, auquel il faut simplement rajouter une API. Si le mode de stockage du nœud n’est pas adapté aux besoins, privilégier le service externe au module Duniter.

Pas sûr que ma réponse vous satisfasse !

7 Likes

Tiens, dans la même veine : le cœur doit-il, en plus de tenir la charge protocolaire pour des milliers d’utilisateurs, être capable de haute disponibilité pour toutes les requêtes clients ?

On voit bien que ça ne tient pas. En tout cas moi, ça me saute aux yeux.

yen a meme deux, dont un en java qui se grefferais très bien sur Cesium, pas besoin d’un noeud, pas besoin de changer le protocole…

1 Like

S’appuyer sur des noeuds Duniter en mode mirroir me va très bien. C’est ce que je fais pour le pod Cesium+ du Sou (https://g1.data.le-sou.org -> g1.le-sou.org qui est un mirroir).

Cependant, je rappelle que, très concrètement, aujourd’hui la plupart des noeuds n’indexent pas l’historique des TX, et qu’en conséquence quasiment plus aucun utilisateur de la G1 (sauf @bpresles :slight_smile: ) ne peut voir ses opérations de compte…

Si nous décidons (dans un client) de passer par des noeuds tiers (spécialisés) pour certains services (historique des TX par exemple) il faut avoir en tete :

  • que les données qu’ils diffuseront seront potentiellement en décalage avec celles du noeud Duniter interrogé pour les autres services.
  • qu’il va falloir coder : coté noeuds et coté client. Pendant ce temps, la situation va perdurer sans accès aux opérations ?

Une fois les services spécialisés codés, dans des noeuds tiers, les utilisateurs n’auront il pas tendance, alors :

  • a nous remonté sans cesse des problèmes d’incohérence ?
  • a chercher à brancher leur client uniquement sur des noeuds offrant tous les services d’un coup, pour au moins sont cohérents dans les informations qu’ils émettent ?

Je ne parle pas à long terme, mais bien à court terme, dans les prochains mois. C’est à dire avec de fort risque de fork, donc d’incohérence entre les noeuds calculants, mirroirs/spécialisés…
Il faut réfléchir avec nos faibles moyens de développement d’aujourd’hui. Enfin il me semble…

Ne peut on pas gérer cela dans BMA pour le moment ? et activer l’option de stockaqge des TX par défaut ? le temps de s’organiser

Je suis assez d’accord par vos arguments côté client que côté serveur.

Côté client, actuellement BMA c’est un casse-tête chinois pour fournir une fonctionnalité avancée. Actuellement, je suis sur l’affichage de l’historique des transactions. Pour avoir un affichage des champs intéressants formatés pour une lecture humaine, il faut retourner dans tous les sens les résultats.

Je pense que GVA n’améliorera ça pas tant que ça.

Côté serveur, je trouve ça bien de limiter les nœuds calculant à faire avancer la chaîne et à recevoir de nouveaux documents. Mais, faire office de serveur d’information pour les clients, c’est pas nécessaire. Ça peut-être fait par un second cercle comme par des nœuds miroir avec interface BMA, GVA ou un indexeur qui travaille les donnés comme ElasticSearch aujourd’hui.

2 Likes

ou bien un noeud dont c’est l’objectif d’avoir pleins de fonctionalitées, connectivitées … Diversité quand tu nous tiens!

Je ne vois pas le probleme que pose le principe de “cache”

un Noeud + un pod + un client, c’est une architecture … particulière, ton choix, ayant pleins d’avantages, et des inconvenients… le but n’est pas de jeter les inconvenient aux autres.

pour moi le titre trahis un probleme conceptuel: si il y a des demande recurrente sur cesium, c’est un problème cesium.

plutôt que de dire

tu pourrais aussi commencer par “Ayant personnellement décidé que…” et tu vera que le probleme c’est pas Duniter ou son insuffisance mais bien une hypothèse biaisé dès le départ. dès lors, l’ensemble des solutions n’est pas nécesairement “evolution de duniter”, mais potentiellement “évolution de cesium”

Parfois faut tendre l’oreille aux suggestions qui te sont faites. Donc si t’as 20 000 g1 je veux bien exposer la fonctionalité qu’il te manque, ou tu peux t’inspirer d’un existant mal codé, ne respectant pas tes standards de la mort qui tue et résoudre le problème par toi même !

Good luck and have fun !

Je ne comprends pas, je ne vois pas en quoi le nombre de nœuds avec indexation des transactions activée influe sur la possibilité de voir celles-ci dans Cesium, vu que celui-ci fonctionne en mode client/serveur et généralement sur le même nœud : g1.duniter.org ou g1.duniter.fr. Il suffit que ces miroirs aient l’option activée.

Et si c’est à cause d’un bug, alors il suffit de le corriger.

Pourquoi ? Je ne vois pas de raison.

Encore une fois je ne vois pas de quoi tu parles, les nœuds indexent bel et bien les transactions si tu coches l’option.

Pourquoi sans cesse ? Et pourquoi des problèmes d’incohérence ? Le protocole Duniter est extrêmement simple pour qui ne fait qu’indexer les données sans les contrôler, et a fortiori pour qui ne va pas chercher à générer des blocs. En quoi est-ce difficile ou long ? Il suffit de scruter l’arrivée de blocs et leur revert.

J’ai l’impression que tu te fais une montagne d’un faux problème. Tu faisais avec BMA et c’est toujours possible. Ou alors il y a un truc qui m’échappe.

Je penses que je me suis mal exprimé. Il faut que je prennes d’avantage de temps pour me relire :slight_smile:

Le problème d’incohérence dont je parlais, c’était dans le cas où un utilisateur choisi un noeud calculant (par exemple le sien) pour les fonctionnalités de paiement, certif, etc. et un autre noeud (dans le même client) pour l’historique des transactions. C’est par exemple ce qui arriverait si l’historique des transactions étaient récupéré depuis un pod Cesium+, alors que le reste venait d’un noeud calculant.

Mais peut-etre que ca n’arrivera pas, effectivement, si les noeuds mirroir expose toutes les fonctionnalités… Mais s’ils en exposent que certaines, les utilisateurs verront des fonctionnalités acessible ou non, dans les clients, en fonction du noeud choisi. Ca me compliqué pour l’utilisateur lambda, non ?

Oui, ok. J’ai maintenant compris (grace à @bpresles) que l’historique ne s’affichait plus dans Cesium a cause d’un bug de l’API /tx/history de Duniter v1.7, mais que l’indexation se fait bien.

Dans les prochains mois, en tous les cas, en fonction du noeud Duniter que les utilisateurs choisirront, ils auront accès ou non à l’historique des transactions. Idem pour Silkaj ou tout les clients “légers”.
Vous êtes bien d’accord sur cette analyse, non ?
Et comment les faire comprendre la cause du problème, sans qu’il croit que c’est une régression de Cesium ?

@Junidev encore une fois je parle ici de court et moyen terme. L’intéret n’est pas pour moi de défendre Cesium, qui est “du jettable”. Dès qu’on aura mieux on s’en passera (moi le premier).
Tu sous-entend que j’aurais mieux fait de faire autrement, et je suis tout à fait d’accord, avec une autre architecture. Je suis d’accord.
Ici je cherche une solution pour que les utilisateurs voient leur suivi de compte facilité. c’est tout.
Le problème ici est exactement le même dans tous les clients “léger”, dont Silkaj. Enfin il me semble.

1 Like

Une idée :

une personne qui va modifier le noeud dans les paramètres peut recevoir un message (infobulle, pop-up, etc) lui indiquant que certains noeuds ne stockent pas les adresses, et que si elle voit un changement dans le comportement de Cesium, elle peut essayer un autre noeud.

Une liste des noeuds régionaux peut être ajoutée, comme noeuds “fiable” .

autre idée :

quand Cesium détecte que le compte est rempli mais que la liste des transactions est vide, une pop-up similaire apparaît.

1 Like

En fait je suis 100% d’accord avec toi la dessus @kimamila.
Si je n’avais pas en vue la supression du mécanisme actuel de destruction des sources je t’aurait dit oui il faut expliciter cette destruction dans les blocs :slight_smile:
Sauf que dans le cas présent cela reviendrai a entériner dans le format même des blocs un mécanisme qu’on souhaite retirer.
Comme ajouter un champ au format des blocs demande de toute façon de changer de version du protocole, quitte a changer de version du protocole autant supprimer ce mécanisme.

C’est une évol qui peut venir assez vite car elle est relativement simple et qu’il y au consensus parmi les dev de serveur blockchain :wink:

Sur l’historique des transactions

J’ai repensé cette nuit à l’historique des transactions…
Ne devrait on pas mettre l’indexation des TX activée par défaut, lorsque BMA est activé sur un noeud ?

En effet, aujourd’hui les clients “légers” ne se connectent qu’à des nœuds avec BMA.
@cgeek suggère (si je comprends bien) que de tels nœuds seront en priorité des nœuds mirroirs, avec de multiples API de communication d’activés (BMA, GVA, etc). Cela me semble effectivement la bonne direction à prendre. D’ailleurs, on voit que beaucoup de nœuds calculant sont exclusivement WS2P, sans BMA.

Du coup, ce ne serait pas gênant, me semble t il, d’activer l’historique par défaut, afin d’avoir une API BMA complète (avec historique) sur la grande majorité des nœuds déclarants un endpoint BMA. Dans des clients comme Cesium, l’utilisateur n’aurait pas tester un par un les nœuds, pour voir si l’historique sera disponible dans le logiciel client. Cela serait plus simple pour l’utilisateur de base…

Qu’en pensez-vous ?

Une autre solution est de faire une API de endpoint différente pour “BMA sans historique”, afin de filtrer facilement dans la liste des nœuds, typiquement dans le choix du noeud à utiliser par le client.

Sur la destruction de monnaie

Ah, tu es sûr de ce que tu dis ? Je n’avais pas compris, en lisant @cgeek, qu’il était ok pour enlever la destruction de monnaie…

EDIT : Je lis seulement maintenant cette discussion sur l’interdiction des transactions avec des sources < 1.00G1.

Si l’on garde la suppression, comme je crois l’avoir compris, voici une solution que je propose :

  • Lorsque l’API BMA complète (avec l’historique des transactions) est activé - typiquement sur des noeuds miroirs - alors les blocs JSON renvoi aussi un champ avec les infos de destruction.
    Ainsi :
  • le protocole n’est pas changé.
  • le raw document du bloc reste intact
  • Les clients légers ou indexeurs légers (Pod Cs+) n’ont pas à parser toute la BC (pour calculer la balance, etc.);
  • La compatibilité avec les clients existants restent intacts : un champs supplémentaire ne devraient pas leur poser de soucis…

Qu’en pensez-vous ?

1 Like

Comme tu le suggérais : BMA devrait renvoyer un code erreur HTTP (genre une HTTP#501 - Not Implemented), ce qui permet à Cesium d’interpréter le message et alerter l’utilisateur.

Un ticket svp ? :slight_smile:

C’est que ça te travaille ! :wink:

C’est une bonne idée.

Du coup vers la fin de cette discussion, nous sommes tombés d’accord sur le fait de ne pas conserver ce mécanisme.

2 Likes

Absolument pas, tu déforme mon propos, c’est tres desagréable, elle est tres bien ton archi, elle est tres solide, mais tres lourde. tout ce que je dis c’est que si c’est ton choix, alors c’est ton probleme, pas celui des autres ! Tu ne cherche pas une solution, tu demande aux autres de résoudre ton problème. c’est fondamentalement different.

Merci de ne pas me faire dire ce que je n’ai pas dit, si tu n’en est pas capable merci d’ignorer mes messages et de ne pas y répondre. Surtout si, au passage, tu ignores complétement les suggestions qu’on prends le temps de te faire.

Si j’ai “déformé” tes mots, ce n’était pas volontaire. j’ai reformulé aussi afin de vérifier comprendre ce que tu voulais dire.
Je me suis trompé, visiblement. Mieux vaut s’en apercevoir, plutot que de de ne jamais rien reformuler et partir sur une incompréhension plus difficile a démasquer.

J’essaie de comprendre ce que tu cherches à me faire entendre. Excuses moi de ne pas réussir du premier coup. Je ne fais pas exprès.

Si je relis et relis encore ces phrases ci :

Je ne vois pas du tout où tu veux en venir…

De mon point de vue, il est intéressant de chercher ensemble une solution, car a plusieurs on n’aboutit au même résultat. Par exemple, cette discussion a permis de se mettre d’accord sur plusieurs choses (pas de suppression de monnaie implicite, et que BMA active l’historique des transactions par défaut, etc).

Ensuite, obtenir une solution ne dit rien sur qui va ensuite l’implémenter. Je n’ai aucun moyen d’imposer quoi que ce soit, a quiconque.

Enfin, je voulais souligner qu’un logiciel dit “client” ne peut être totalement autonome. Il dépend nécessairement de l’API serveur qu’il utilise. Je souligne également que ce découpage client-noeud n’est pas un choix personnel de ma part, car je n’ai pas initié Cesium. Cesium a commencé a exploiter BMA dès le départ, avec une vue réseau. De fait, c’est bel et bien un dépendance du client par rapport a cette API. Mais ce n’est pas un choix personnel, mais plutôt collégiale car les deux (API et client) ont ensuite évolué en discutant ensemble de nos besoins respectif.
Cela a bien fonctionné, avec @cgeek et @inso, @vit, moul, etc.

Aussi, je ne comprends pas bien pourquoi je devrais revoir ma façon de poser le problème, ici.
N’est-ce pas plutôt a eux de me dire si ma manière d’aborder la question ne leur convient pas ?
J’espère (je penses) qu’ils sont assez libres pour le faire, sans que tu le fasse a leur place.

J’y ai pensé figures toi (a ignorer ton 1er message), car je n’étais pas sur de le comprendre.
A la vue de ta réaction très agressive, je regrette de ne pas l’avoir fait.
Je te suggère la même chose a mon égard : si ma manière de communiquer ou de poser le problème ne te va pas, tu peux tout a fait ignorer mes messages. C’est symétrique, quoi ! :slight_smile:
Et si tu me réponds, merci de ne pas me faire la leçon, ni de défouler une quelconque agressivité a laquelle je ne sens totalement non responsable.
Mon but est d’avancer vers la monnaie libre, pas de nous tirer dans les pattes ni de nous défouler les uns sur les autres.

1 Like

Je profite de la discussion pour balancer mes 2 cents.
Si j’ai bien compris, il y a un problème de calcul des historiques parce que y’a des Junes qui s’effacent…

Perso je trouve bizarre de les effacer, mais ça peut permettre de libérer des portefeuilles trop petits pour d’autres dans 150 ans :wink:

Je pense qu’un code qui comporte le moins de lignes de code est le plus efficace, sûr et stable. Alors le coeur doit rester light. Dans ce cas faut introduire des proxy/cache (les noeuds spécialisés qui gardent les TX?) qui prémoulinent la blockchain selon le genre de requête qui lui sera faite (elasticsearch est en piste?).

Concernant les craintes que remonte Benoit, je les comprends. La G1 devient de plus en plus connue et tout dysfonctionnement constaté par l’utilisateur est fortement préjudiciable à la confiance ressentie dans le truc. Vu le sujet artistique abordé, y’a pas de seconde chance…

C’est pour cette raison, que je m’investi sur le client/serveur Ḡ1SMS et Ḡ1Billet.
Pour simplifier l’interface Humain / Blockchain et lisser, alléger les requêtes sur Duniter.
Pour le moment, ça marche bien en monoposte, maintenant, il faut que je relie les serveurs pour qu’ils connaissent leurs comptes entre eux. Maillage de VPN, IPFS, CJDNS… J’espère arriver avec qqch au RML.

ONE LOVE

1 Like

Je verrouille ce topic, on a fait le tour de la question et les réponses techniques ont été apportées.

Voila le p’tit ticket #1359 :slight_smile:

2 Likes