Binarisation vs Format text du protocole blockchain


#21

Bon, en faisant l’impasse sur la légère agressivité sous jacente a ton post, c’est une contribution très intéressante que tu fais là.

J’avais pas entendu parler d’antlr depuis un moment (mes études en fait haha) mais c’est effectivement une très bonne idée pour résoudre nos problèmes de formalisation et de format des documents. A noter qu’il n’existe pas de target rust a ce jour : https://groups.google.com/forum/m/#!topic/antlr-discussion/T5kVspwfAyY
Je ne sais pas la difficulté que ce serait de réaliser un tel target, mais c’est un point qui peut être bloquant a court terme.

Peut être existe-t-il d’autres lexer plus généraux et moins spécifiques a l’univers Java ? Par exemple, on pourrait spécifier les documents au format BNF. Libre aux développeurs de traduire ça dans les parsers/lexers de leur choix ensuite. ( https://en.m.wikipedia.org/wiki/Extended_Backus–Naur_form ). On trouve des parsers de BNF dans tous les langages, même Rust ( https://github.com/shnewto/bnf )

L’argument de la compression intégré directement à la carte réseau est très pertinent par ailleurs.


#22

De la façon dont tu cites le texte, on croirait que ce sont mes paroles alors que c’est en fait @elois que tu cites. Je le dis juste pour que ce soit plus clair.


#23
  • Je ne réécrirais la grammaire une troisieme fois que si un groupe de travail se forme et que le choix techno me semble apporter quelque chose.
  • j’ai pris antlr pour l’export du parser, je suis pas fan de l’outil et c’est la première fois que je l’utilise mais c’est un bon outil.
  • antlr n’as de java que le runtime original, depuis traduis dans plusieurs langues.
  • c’est un trade off entre ce que l’outil permet et le formalisme lui même c’est pourquoi j’écris plusieurs grammaires:
    • une pour traduire (plein d’actions println )
    • une pour parser (gros lexer, petite grammaire, souple)
    • une pour spécifier (gros lexer, grosse grammaire, strict)

7 langues c’est mieux qu’ 1 que personne ne parle.

Ca n’est pas a moi d’assumer des choix techno pris par d’autres. je pars de mon expérience à maintenir des systèmes et je préfère ne pas m’isoler car je n’ai pas l’intention de promettre d’être là dans 10 ans pour le maintenir… par ailleurs, je n’ai pas l’œil du théoricien que d’autres apportent. j’ai l’œil d’un employé lambda de la maintenance de système informatique et je penses que ça ferais vraiment pas de mal a certains de changer de rôle pour découvrir la merde que c’est a maintenir des systèmes imaginé et conçu pour duré 1000 ans … Il s’agit d’un processus évolutif a mon sens qu’il s’agit de faire communiquer (d’une version)+ a l’autre… comme la g1 au cours du temps. elle nourrira les suivant puis s’estompera. les procédés immortelles deviennent des entraves. ne succombez pas !

BNF éventuellement … mais faut que ça apporte quelque chose, Antlr est UTILE car il apporte des outils. ca ne m’intéresse qu’a moitié de déclarer la grammaire dans une langue qui me permet seulement de le parser en ligne de commande… autant faire une autre spec.

Si je faisais ça pour prendre mon pieds, j’utiliserais perl6, si mes choix se porte sur java / antlr c’est pour ouvrir un dialogue avec des développeurs back. pas pour satisfaire mon égo et écrire le protocole en 500 lignes. (car je penses que c’est possible en perl)

Les questions que je me pose:

  • considères-t’on le format comme inhérent au canal ? GVA -> graphql, BMA -> rest, text -> WS2P…
    ou bien devrais-t’on ajouter un champ “format” (accepté & produit) aux endpoints?
  • est-il utile de décomposer
    • les buids -> bnum ‘-’ bhash
    • les fonctions en
      • fonction -> name ( param )
      • fonction -> sig | xhx …
        … …sig -> param
    • would you wrap the parameter or assume its type ?
  • la signature est-elle un fils de document ou bien fils d’un noeud certif/tx/indentity/… qu’est-ce qui à le plus de sens ?
  • il y a des nuances sur la structure de la grammaire qui ont parfois du sens d’un point de vue du code, de la facilité d’implémentation mais pas d’un point de vue sémantique.

Les remarques:

  • Le format des endpoints (TYPE (ip4 | ip6 | dns)+ PORT) actuel est presque ambiguë a cause de PORT en fin de ligne, il faudra faire attention à sa description en rajoutant des champs.
  • la validation locale des hashs utilisant des libs de cryptos peut se faire par import dans la grammaire (en théorie) ce qui implique que le parser généré de cette façon verifie les hashs/signature. un noeud mirroir codé avec un tel parser s’émanciperait du besoin de gérer l’aspet crypto (enfin je penses), la vérification locale peut également être faite sur un proxy … pas besoin d’un noeud super méga compilé, s’il est bien proxyfié, il ne sera pas spammé
  • on peut utiliser la grammaire pour specifier simplement un format de bulk load:
    • “block contenant DU” suivis de plusieurs “block sans DU” suivis d’un hash global… ou pas
    • bulk -> block[DU] (block[!DU])+ BULK_HASH?
  • On peut spécifier le merkel tree …
  • et donc !? … on peut … ???
  • Oui on peut ! enfin … en théorie

Bref je serais ravis si quelqu’un en écris une autre, BNF? ou modifie mes grammaires pour discuter des nuances, les détailler et éventuellement en choisir une commune en spécification. en attendant je continue sur antlr car je compte bien l’utiliser un jour.

je commit mon taf se week end. A bientôt


#24

Je suis prêt a suivre les choix de la majorité même s’il ne sont pas les miens, je ne suis pas aussi têtu et borné que certains semblent le croire :wink:

En revanche, concernant le dénominateur commun obligatoire entre toutes les implémentations, c’est à dire le protocole blockchain, je demande a minima a ce que l’implémentation du protocole puisse être faite de zéro sous n’importe-quel langage, ce qui implique que l’implémentation du protocole ne doit pas dépendre d’un intermédiaire obligatoire qui bloquera certains.

Sinon on va se retrouver avec 2 monnaies libres et les utilisateurs de la Ğ1 devront choisir l’une ou l’autre.
J’ai déjà passé des milliers d’heures sur Durs, il est évident que je ne vais pas lâché ce projet.

Le compromis proposé par @Inso qui est de passer par un format BNF et de laisser libre les dev de chaque implémentation de choisir ensuite les parsers/lexers de leur choix me semble tout a fait sage.

Nous devons tous mettre un peu d’eau dans notre vin et faire des concession sinon l’équipe de dev vas finir par se scindée en deux et la Ğ1 avec…
Je suis prêt a faire des concessions de mon coté et a renoncer au format binaire, @anon2076149 et tu capable d’en faire également (des concessions) afin que la Ğ1 ne se scinde pas ?


#25

D’après Wikipedia, ANTLR4 s’appuie sur une syntaxe ENBF ( https://en.wikipedia.org/wiki/Comparison_of_parser_generators ). Pour ta grammaire, j’attends de voir le commit pour voir si elle serait pas généralisable :slight_smile:

C’est un oeil important que tu apportes là :slight_smile:

La spec décrit les documents au format texte pour les échanges et le contenu de la blockchain. C’est ce format qui est signé et vérifié par les clients comme les serveurs.

Pour GVA et BMA, le format des données dépend effectivement de l’API sous-jacente. Dans les deux cas ces formats produisent du JSON. Cependant

  • les requêtes et réponses sont très différentes entre une API REST et une API GraphQL
  • ces API clients ne fournissent pas nécessairement que des documents Duniter. Les clients n’ont pas nécessairement besoin des documents en tant que tel, mais d’informations sur l’état de la blockchain

Ainsi, il ne me semble pas nécessaire d’avoir de conversion strict du format texte vers le format JSON. C’est à chaque API de spécifier la forme des réponses qu’elles donnent. Ca peut cependant être utile pour les documents d’avoir un format JSON “générique” utilisable par n’importe quelle API JSON, ça allège et simplifie légèrement le parsing dans les librairies clients.

Les blockUID : il faut pouvoir extraire le block number indépendamment du block hash. Le parser d’un block uid doit s’attendre à avoir ces deux éléments, mais doit pouvoir ensuite les fournir indépendamment. (Exemple d’une classe portant un BlockUID dans la lib python : https://git.duniter.org/clients/python/duniterpy/blob/master/duniterpy/documents/block.py#L23 )

Personellement, je partirais plutôt sur sig | xhx ; sig -> param. En effet, c’est une liste finie, et on ne sait pas si un jour on ne permettrait pas des fonctions portant plusieurs paramètres, ou portant d’autres fonctions en paramètres etc (bon là j’ai peur qu’on obtienne une langage turing-complet, mais on sait jamais !)

Pour l’exemple, côté python j’ai codé les fonctions avec une grammaire PEG : https://git.duniter.org/clients/python/duniterpy/blob/master/duniterpy/grammars/output.py . Le type attendu est strict.

Je pense qu’il faut les lister, ça fait partie de cette démache de standardisation que de détecter les cas ambiguës.

Les signatures sont un cas que j’ai eu du mal à traiter convenablement. Les documents ne portent pas nécessairement les signatures. Mais ils sont tous signés. Ils peuvent même être signé par plusieurs identités.

Côté duniterpy, j’ai considéré que les signatures font partie d’un document, mais que cette liste peut être vide.

Il me semble que la spec WS2Pv2 améliore ce point ?

Je n’ai pas bien compris ce point ?


#26

Bon, ici il est bon de commencer à prendre conscience du point fondamental qui régit une monnaie : ce n’est pas son support physique ou la forme de son protocole ! C’est la force de son inertie économique.

Ainsi le passage des Francs, Mark, Lire, Pesetas etc. à l’€ en 2000 s’est réalisé par changement total de support physique et de protocole, mais en gardant 100% des comptes par pure transformation linéaire simple.

Penser à scinder une monnaie est donc une bonne rigolade… La réalité c’est que c’est la communauté économique la plus forte qui l’emportera sur ses choix technique, et pas du tout l’inverse. Un fork technique n’est pas du tout de même ampleur qu’un fork économique, on est là sur deux facteurs d’échelles incomparables.

Pour la même raison, penser qu’il y aura une Ğ2 est une franche rigolade. Cette probabilité chute vers zéro au fur et à mesure des années d’utilisation de la Ğ1. C’est trivialement vérifiable concernant des phénomènes de moindre ampleur économique (non-monétaires) concernant par exemple l’utilisation des logiciels et on peut aussi voir les forks Linux pour se faire une idée (mais les forks monétaires sont beaucoup plus inertiels ! Car on ne peut pas comparer véritablement un outil réseau interconnecté, avec un outil utilisable individuellement).

La monnaie est une intégrale temporelle interconnectée, ce qui rend son inertie considérable ! Seules de nouvelles formes de monnaies peuvent prétendre concurrencer sur le long terme les autres intégrales temporelles interconnectées, mais le facteur d’échelle spatial et temporel n’a rien de comparable avec ce qu’on connaît des forks de phénomènes non-cumulés temporellement, non-interconnectés spatialement, qui sont extrêmement rapides (10 ans à l’échelle considérée, c’est très rapide !).

Pour du plus long terme en terme de compréhension, on pourra réfléchir aux forks génétiques qui constituent la trame de ce qu’on appelle l’évolution, là on est sur sur du plus lourd que la monnaie, dont on a ainsi deux bornes d’échelles hautes et basses d’encadrement, pour mieux cerner le sujet.

Bonne réflexion :wink:


#27

Toujours est t’il que si Juniter par sur des spec que je ne peut pas implémenter en Rust même en y mettant toute la bonne volonté du monde alors Juniter et Durs ne pourront pas faire fonctionner la même monnaie.
Duniter devra alors choisir quel protocole suivre, mais forcément l’une des implémentations sera exclue et le dev derrière devra choisir entre accepter de jeter a la poubelle ses milliers d’heures de travail (voir plus) ou décider de lancer une autre monnaie libre avec son implémentation avec les personnes qui voudront bien le suivre.

Je ne demande pas la Lune, simplement le respect de chaque contributeur. De mon coté je fait attention a proposer des choix techniques qui n’exclurons aucune implémentation du cœur ni aucun client, par respect pour l’investissement personnel de chaque contributeur. Et j’estime que tout contributeur Ğ1 se doit d’en faire autant.


#28

Le but d’une base formel c’est justement ça, le parser multilingue c’est pour les gens qui veulent faire leurs propre noeud sans trop se prendre la tête sur les détails, un objet à étudier. un truc pour comprendre quoi

c’est un choix politique sans doute mais je préfère cela qu’une distance de 6 par exemple… moi je crois que la wot, sa dimension politique. est plus fondamentale que la monnaie.

Je ne te le demande pas, pourquoi ferais-tu cela ? c’est une très bonne idée de le faire tourner sur arduino je te demande de ne pas l’imposer.

Je ne me sens pas faire partie d’une équipe, j’ai produis un bout de code que je propose en partage.

L’ambiguïté de ton langage n’est pas de tout repos mais j’y surviverais :wink:

donc quand tu affirme avec vigueur qu’il faudra fork sur ton implémentation qu’il est “obligatoire” , “nécessaire” de ceci ou de cela. par limitation et incompatibilité entre l’implémentation que tu prépare et l’existant, tu respectes le travail des autres? Non je ne penses pas! Si tu étais honnête dans ton raisonnement alors tu partirais de l’état actuel et tu chercherais à l’améliorer, car la plupart des choses n’ont pas besoin de fork technique si l’implémentation accepte plusieurs versions du protocole. enfin il me semble mais je n’ai pas réfléchis à tout

Par pitié arrête e te faire passer pour le bon samaritain alors que t’est comme tout le monde t’as un un ego, des défaillances et des envies

Dis le mec qui change le format, change le hashage, force le fork ! [Modération propos inacceptables]. T’as l’attitude type du militant politique, je dirais même un militant d’Asselineau par ta manière de détourner le langage, de rendre pestiféré les autres en leur assignant tes propres défaut. Je préfère vraiment ne plus te lire. je perds mon temps et je m’ennerves. je ferais mon truc dans mon coins, si ya des gens que ça intéressent, tant mieux, sinon tempis, je le ferais pour moi.

Je force personne, j’implémente mon nœud, et je dis ce que je fais, pas ce que les autres doivent faire. point barre. Ton esprit d’équipe qui se résume par “être d’accords avec toi” sinon être marginalisé. tu te prends pour qui ? Ignore moi, ignore Juniter, fais comme si j’étais pas la et va pourrir quelqu’un d’autre.


#29

@anon2076149
Comme inso et malgré mon incompétence informatique je trouve que tes arguments sont interessants et propres à être débattus. En revanche les attaques personnelles et propos insultants ne sont pas acceptables et en violation de toutes les chartes de forums.
Il serait bon de continuer à communiquer avec des idées plutôt qu’avec des jugements.
C’est la raison pour laquelle j’ai modéré ton post.


#30

Pourtant en contribuant au protocole technique de la Ğ1 tu fait parti de facto de l’équipe technique de la Ğ1, et cela implique de respecter les autres contributeurs de l’équipe. C’est peut-être bien ce quiproquo qui provoque tant d’incompréhension, il n’est pas possible de contribuer tout en disant rester a l’écart, du moment que l’on contribue à un projet alors on en deviens parti prenante avec tout les avantages et inconvénients que cela infère, tu n’est pas sur un projet perso :wink:

Je n’ai jamais affirmé de telles choses. Je crois surtout que tu m’en veut car tu a sur-interprété mes propos en fait de nombreuses suppositions erronés sur mes positions et intentions.
Pour bien communiquer avec les autres une chose importante est de ne jamais faire de suppositions sur les intentions d’autrui (c’est très difficile a faire, mais si tu décide de le faire tu verra que tes échanges avec les autres seront beaucoup plus fluides et que tu te mettre bien moins souvent en colère :slight_smile: ).

En fait c’est exactement ce que je fais depuis 2 ans que j’ai rejoins ce projet. Je part de l’état actuel et je cherche a l’améliorer. Et suite a de nombreux échanges avec @cgeek, @Inso, @nanocryk et quelques autres il fini par se dégager des axes puis l’on s’engage sur des changements. C’est suite a cela que je me suis par exemple engagé sur WS2Pv2 et sur la binarisation du protocole blockchain.
Comprend simplement que lorsque je m’engage sur une voie après plusieurs mois d’échanges avec les autres contributeurs et que tu arrive comme un cheveux sur la soupe pour proposer quelque chose d’incompatible avec ce sur quoi je me suis engagé, forcément je parle d’incompatibilité et d’impossibilité.
Je me suis certainement mal exprimé, et je m’en excuse, mais dans tout les cas tes réactions sont beaucoup trop disproportionnés et sur-interprètes trop mes propos.

J’ai pas changé le hashage, ou a tu vu cela ? C’est toujours du sha256, ou alors tu parle de la façon de hasher, qui pour moi est intimement liée au format. Et comme dit plus haut je ne force pas le fork, je suis désolé que ce soit l’impression que je t’ai donné dans nos échanges, c’est un gros malentendus !

Oui c’est vrai, j’ai toutefois réagi car suite au poitn bloquant soulevé par @inso tu a répondu ceci :

Ce qui est clairement est attaque personnelle contre le choix du Rust, qui est pourtant un choix très pertinent pour Duniter a bien des égards, on en a déjà parlé sur d’autres fil je ne m’étalerai pas plus ici.

Un dernier point : C’est la 3ème fois que tu m’attaque personnellement, et la deuxième fois que tu m’insulte, pourquoi fait tu cela ?? Tu vois bien que ça ne sert à rien, et même ça désert tes propos.
Comme dit en privé j’attends toujours des excuses de ta part.


#32

J’ai beaucoup re-réfléchi a cette question du futur format des documents du protocole, je pense toujours que la binarisation est le meilleur choix, mais j’entends la volonté de bon nombre d’entre vous de vouloir garder un format texte. J’ai donc exploré d’autres pistes, et demandé autour de moi, on m’a dit “mais pourquoi vous n’utilisez pas une gramme PEG ?”.

Effectivement pour notre besoin, une Parsing Expression Grammar me semble être le meilleur choix si nous restons sur du texte.

C’est une grammaire qui a de nombreux avantages par rapport aux autres :

Parsing expression grammars look quite similar to other parsing tools you might be used to, like regular expressions, BNF grammars, and others (Yacc/Bison, LALR, CFG). However, PEGs behave subtly differently: PEGs are eager, non-backtracking, ordered, and unambiguous.

Cela signifie, entre autre, que lorsqu’un texte est parsé avec succès, il n’existe qu’un seul et unique arbre possible. On peut donc se baser dessus pour signer et vérifier les signatures.

En plus, il existes des implémentation de PEG dans tout les langages :

JS : https://pegjs.org/

Python : https://github.com/erikrose/parsimonious

Java : https://github.com/sirthias/parboiled/wiki

Rust : https://pest.rs/


Ainsi, nous pourrions a l’avenir définir le format des documents via une grammaire PEG dans le protocole et chaque développeur n’aurait qu’a utiliser directement cette grammaire dans son langage favoris pour être sur de parser chaque document de la même façon que tout le monde :slight_smile:

Voici par exemple, une grammaire PEG qui parse le document d’identité actuel :

alpha ← [a-z] / [A-Z]
alphanum ← [0-9] / alpha
hexa ← [0-9] / [A-F]
base58 ← !('O' / 'I' / 'l') alphanum
integer ← [1-9] [0-9]*
newline ← '\n'

currency ←  (alpha / '_')+
pubkey ← base58{43,44}
uid ← alpha (alphanum / '_')*
blockstamp ← integer '-' hexa{64}

idty_doc ← "Version: " integer newline
    "Type: Identity" newline
    "Currency: " currency newline
    "Issuer: " pubkey newline
    "UniqueID: " uid newline
    "Timestamp: " blockstamp newline

Et voici un exemple concret d’implémentation avec pest : https://pest.rs/?bin=15hpya#editor


A noter que PEG est a sens unique, on ne peut pas utiliser une grammaire PEG pour régénérer le texte de départ a partir de l’arbre. Ce qui veut dire qu’il faudrait se transmettre les documents sous leur format plain text tel qu’il sera parsé par la grammaire.

Or JSON ne permet pas de transmettre des chaines de caractère avec sauts de lignes, il y a plusieurs façon de contourner ça ( a ceux qui font les spec de l’API Client de choisir) :

EDIT : En fait non, JSON le permet.


Donc, que diriez vous d’adopter une grammaire PEG pour décrire le format des documents dans le protocole ?


#33

A priori je trouve ça bien, ça lève les ambiguïtés je suppose. Qu’en est-il des champs optionnels ? Je pense au champ Parameters du bloc#0 par exemple.

Que veux-tu dire par là ? Duniter en transmet bien :

{
"raw": "Version: 10\nType: Peer\nCurrency: g1-test\nPublicKey: 3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj\nBlock: 266809-000046326B93332B4194F480FF21C6AC51687D3178609484E0EE13846864FD71\nEndpoints:\nBASIC_MERKLED_API 88.174.120.187 10900\nWS2P 6523edcc 88.174.120.187 20900\nWS2P 46dd97e4 88.174.120.187 20902\nWS2P 05b54304 88.174.120.187 20902\nNbpnhcb+BoaqzqIpdkXrfueRos6XT31o2KHs07Ii3MOdIzYdUsOk6KFhdvHsrXEls51pBycfcbsCpIYSA0k2CA==\n"
}

#34

Oui c’est le but :slight_smile:

On peut définir des champs optionnels avec le ?, exemple :

idty_doc ← "Version: " integer newline
    "Type: Identity" newline
    "Currency: " currency newline
    "Issuer: " pubkey newline
    "UniqueID: " uid newline
    "Timestamp: " blockstamp newline
    ("optionalField: " field_rule newline)?

Ha ok, tant mieux, il me semblais que c’était une limitation du JSON, autant pour moi :sweat_smile:


#35

Du coup, c’est l’arbre qui est signé et non la version texte ?
si oui, ça me semble dommage que la conversion soit à sens unique.
En effet, la conversion à double sens permettrait d’échanger indifféremment au format texte ou binaire, et donc de pouvoir utiliser le format que l’on veut au niveau réseau.


#36

Ça c’est a nous de décider, on peut signer la version texte a condition d’écrire une grammaire qui n’accepte pas les whitespace afin d’être sur qu’il n’y a pas de variante possible, PEG permet cela (ça n’est pas une obligation dans PEG, mais si l’on signe le format texte c’est une obligation).

En fait il est tout a fait possible d’écrire le code permettant la régénération du document texte a partir de l’arbre. Mais je ne vois pas en quoi c’est utile, l’arbre généré par PEG n’est pas le format binaire, c’est un format existant temporairement juste de temps de wrapper l’objet correspondant.
Dans la pratique, le code de regénération du document texte utilisera l’objet wrappé en entrée, et pas l’arbre PEG.
De même, si l’on décidais d’utiliser également un format binaire des documents pour certains types de transmission réseau, ça ne serait pas l’arbre PEG de toute façon, mais une sérialisation binaire de l’objet wrappé :wink:


#37

Je viens de passer ces dernière jours a intégrer une grammaire PEG complète dans Durs, la grammaire que j’ai rédigée passe bien tout les tests automatisés de Durs et la synchro rapide fonctionne sur les blockchain g1 et g1-test, j’ai donc bon espoir que la grammaire PEG que j’ai rédigée soit conforme au protocole DUP actuel, la grammaire est ici :

@cgeek tu peut donc la traduire directement au format attendu par SimplePEG (ou toute autre lib PEG pour Node) si ça te dit d’utiliser une grammaire PEG dans Duniter :slight_smile:

EDIT : SimplePEG a l’air plus dans l’esprit des grammaires PEG et suffisamment complet : https://github.com/SimplePEG/JavaScript#readme. En plus ils proposent des implémentations identiques pour Java, Python et Go : https://github.com/SimplePEG.
A contrario, pegjs propose beaucoup de features en plus qui n’ont rien a voir avec PEG et ne semble pas permettre d’intégrer directement une grammaire selon la syntaxe classique de PEG.

Dans le fichier que je pointe c’est la syntaxe de pest (lib rust), en gros il suffit de supprimer tout les {, } et ~ pour avoir une syntaxe assez proche de ce qui se fait dans les autres implémentations de PEG :wink:

Et pour les curieux qui veulent une demo, vous pouvez tester ma grammaire en live sur pest.rs (lien avec exemple de transaction) :blush:


#38

Est-ce que c’est automatique de régénérer un doc “en clair” à partir du document, lisible quoi, ou bien il faut que quelqu’un écrive une fonction + ou - rébarbative ? Ou bien j’ai pas compris ?
(Ça pourrait me faire un début)


#39

Qu’entend tu par un doc “en clair” ? (Je veut dire, de quel format parle tu)

Voici les différents formats dans lesquels peut-être un document :

  • Format raw/plain text => c’est actuellement le format dans lequel est générée/vérifiée la signature, le problème étant qu’on peut interpréter plusieurs façon différentes de rédiger ce format raw, d’où la nécessité de soit changer de format pour la signature (je propose le format binaire) soit rendre ce format raw strictement non ambiguë en le décrivant via une grammaire strictement non ambiguë (je propose une grammaire PEG).

  • Format compact : format dans lequel le document est inclus dans le format raw du block (donc le block n’a pas de format compact), pose les même problèmes que ci-dessus, il faudra donc que j’ajoute les formats compact a la grammaire PEG que je propose.

  • Format objet wrappé => spécifique a chaque logiciel selon le langage utilisé et la façon dont l’objet est décris par le développeur, c’est ce format qui est manipulé par le logiciel et a partir duquel doivent pouvoir être généré tout les autres.

  • Format JSON => Utilisé par l’API Client pour échanger le document avec les clients. Utilisé également dans WS2Pv1 pour échanger le document entre les nœuds Duniter. (Dans Durs convertible automatiquement vers/depuis l’objet wrappé via serde_json, convertible automatiquement aussi dans Duniter du fait que le JSON est un format JS au départ).

  • Format binaire => Sérialisation de l’objet wrappé en vecteur d’octets, actuellement utilisé dans Durs pour WS2Pv2. Seul format qui est strictement non-ambiguë par nature, dans Durs il est convertible automatiquement en objet wrappé via bincode.

Il est évidemment possible et souhaitable de pouvoir convertir un document dans n’importe lequel de ces formats selon les besoins, et c’est d’ailleurs déjà quasiment le cas aujourd’hui. (Dans Durs par exemple, le code permettant de convertir un document dans n’importe-lequel de ces 5 formats est déjà écrit).

Qu’apporte PEG la dedans ? Un mécanisme de contrôle de la génération du format raw : il suffit de placer dans les test unitaires un parsing (via la grammaire PEG) du format raw généré et de vérifier que le parsing n’échoue pas et qu’on retrouve bien l’objet de départ.


#40

Faut arrêter avec cette assertion @elois, un format binaire peut etre tout aussi ambigu qu’un format texte… Dans les 2 cas ce sont une suite de champs qui doivent être interprété suivant des règles. Ce sont ces règles qui peuvent etre ambigu ou non.

L’avantage d’une grammaire, c’est qu’elle défini des règles non-ambigu, c’est sa raison d’être.


#41

C’est pas faux, disons qu’il est bien plus facile de rendre un format binaire strictement non-ambiguë car on n’a pas de problème de whitespaces, de confusion " “/”/t", d’interprétation des sauts de lignes (entre \n, \r\n et \r…), pas de problème entre des digits hexadéciamux uppercase ou lowercase, et la liste est encore très longue de toutes les raisons qui rendent un format texte potentiellement ambiguë et qui n’existent tout simplement pas dans un format binaire.

Ce que je sous-entendais, c’est que si tu part d’un objet strictement défini, il y a une infinité de façons de le représenter textuellement, beaucoup moins binairement. Typiquement un format binaire n’a pas besoin de grammaire pour être strictement non-ambiguë.

Enfin, bincode propose une norme permettant de sérialiser tout objet en un vecteur d’octet strictement non-ambiguë, il n’existe rien de tel pour les formats textuels quel qu’ils soient, du coup, on n’est obligé de rédiger une grammaire pour s’en sortir convenablement, ce qui représente plus de boulot, c’est donc plus compliqué.

Vous préférez la solution la plus compliquée, soit je m’y conforme, mais ne me dites pas que c’est pareil :wink: