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 : GitHub - erikrose/parsimonious: The fastest pure-Python PEG parser I can muster
Java : Home · sirthias/parboiled Wiki · GitHub
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 
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 : pest. The Elegant Parser
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 ?
