Suite à la publication de la dépèche sur Linuxfr.org, on nous demande encore si nous avons un Whitepaper. Il me semble bien que non : actuellement, qui s’intéresse à Duniter/Ğ1 sur le plan technique doit fouiller dans les forums.
Dans la stratégie actuelle de recrutement de devs, la publication d’un whitepaper me semble appropriée, car elle faciliterait l’information d’éventuels contributeurs techniques. ceci a été discuté sur ce fil, mais à l’époque dans une optique de communication « grand public ».
Je pense connaître suffisamment bien le projet pour écrire un brouillon (en français), mais ce brouillon devra nécessairement être relu, fortement corrigé et complété et éventuellement traduit par la suite.
Je pense pouvoir rédiger ce brouillon d’ici les RML15 et proposer un atelier de correction dessus. D’autres personnes veulent-elles y participer ?
edit - en fait, la plus grosse partie du travail est déjà rédigée, « plus qu’à » compiler et traduire :
mentionner l’égalité spatiale et temporelle de tout humain devant la création monétaire.
À un moment, si des gens demandent ‹ pourquoi l’égalité est-elle nécessaire ›, on peut les renvoyer à la déclaration des droits de l’Homme et du Citoyen, laquelle peut être dans les sources du papier.
Je sais que sur presque chaque point, je vais devoir faire des recherches sur le forum ou dans le protocole. Quand j’en serai là, il sera bien temps de passer à l’anglais.
Qui dit “whitepaper” dit vouloir parler le langage de la communauté crypto selon les bonnes pratiques en vigueur, donc je dirais que oui le contexte doit être présenté mais aussi bien détailler la technique.
Un papier blanc se construit souvent tel que:
D’où on part
contexte
énoncer le(s) problème(s) à résoudre
parler d’autres projet similaire mais problématiques (notamment BTC, blockchain et surtout PoW energivore, )
@matograine > Tiens, c’est marrant que tu parles de ça, je crois que j’en parlais justement avec @Martino aux RML.
Parce que c’est vrai que quand on regarde ce qu’il y a au-dessus de la ligne de flottaison de la plupart des projets qui se rapprochent le plus du nôtre, le whitepaper n’est jamais loin :
@matograine > Du coup il faudra qu’on réfléchisse où caser le lien sur la nouvelle version du site (preview). Et peut-être qu’on réfléchisse à comment ton travail et le mien vont s’harmoniser.
Concernant le whitepaper, je vais utiliser certains textes sous licence CC-by-SA, donc j’ai besoin de l’autorisation des auteurs pour les modifier et redistribuer sous une forme modifiée. Les auteurs seront évidemment cités dans le document final.
@cgeek (l’auteur n’est pas indiqué, donc je demande au propriétaire de duniter.org): puis-je utiliser et modifier, pour la rédaction du whitepaper, les textes :
Tu as le droit, sans autorisation, de modifier et redistribuer un document qui est sous CC BY-SA, tant qu’il reste en CC BY-SA ou compatible et que les auteurs sont cités. (détails)
Puisque les documents à traduire sont plutôt longs, il serait pratique d’utiliser une plateforme de traduction collaborative, non ?
Keep It Stupid Simple. Les documents en question possèdent déjà tous une excellente traduction en anglais.
Il n’y a donc rien a traduire pour le moment. Il conviens d’abord d’écrire un plan organisé et de voir comment on compile l’existant, qu’est ce que l’on rajoute, car a mon avis il y aura des choses a rajouter.
Bref, le gros du boulot ce n’est pas de la traduction puisqu’on compile des ressources en anglais, le gros du boulot c’est de déterminer comment articuler tout ça
Ce qui serait idéal serait que le contenu de ce document soit au format markdown dans un dépôt git sur notre GitLab qui génère tous les formats souhaités (pdf, epub, html…) de la même manière que cet outil pour les CV.
J’ai mis @elois developpeur dessus, je vais mettre @jytou à sa demande. Demandez-moi si vous voulez que je vous inclue dans ce dépôt. Mais les MR, ça marche aussi.
format markdown : c’est prévu
génération automatique dans différents formats : je ne sais pas gérer la CI/CD. Si quelqu’un veut s’y pencher, tant mieux, sinon j’écris en MD et je publie en HTML, PDF et sans doute EPUB à la mano.
J’ai un petit souci de compréhension sur la difficulté personnalisée source :
IssuersCount/Frame
C’est notamment le “5X” ou"5Y" blocs que je ne comprends pas :
if issuersCount increases by N -and with a maximum step of N = 1 - then issuersFrame will increase by one unit over a period of 5N blocks.
Si on a issuersFrame = 160, et qu’un nouveau membre crée un bloc, alors on a (choisir la bonne réponse):
A - issuersFrame = 161, et reste à 161 si les blocs suivants sont créés par des membres déjà connus ?
B - issuresFrame = 161, pour 5 blocs (et ensuite ? et que se passe-t-il si un membre entre au bloc suivant ?)
C - issuersFrame = 161, 162, 163, 164, 165 pour les 5 blocs suivants ?
Ğ - La réponse Ğ
Je comprends que c’est la réponse C, mais dans ce cas cette phrase est fausse:
Ce qui fait que si un nouvel auteur apparaît au bloc T et un autre disparaît à T+1, issuersFrame augmentera de 1 unité à T+1 puis diminuera de 1 unité à T+2, pour se stabiliser.
Que vient faire “0.33*nbPreviousIssuers” ? Il n’a rien à voir avec l’explication, et ce que je comprends est également juste :
Take as an example nbPreviousIssuers = 6 and nbBlocksSince = 3:
(0.67* 6 / )1 + 3)) = 1.005 → exFact = 1
However, if the member computed a block one block ago (nbBlocksSince = 1):
(.67 * 6 / (1 + 1)) = 2.01 → exFact = 2
Merci à celleux qui pourront me répondre. Je n’en ai pas fini avec ce chapitre
Oui c’est bien la réponse C et oui cette phrase porte a confusion, mais issuersFrame diminue bien de 1 unité a T+2, cette diminution st en effet compensée mais je ne voyais pas trop commet le formuler simplement, si tu a une proposition de reformulation qui reste claire et précise je suis preneur
oui
0,67 est en réalité un paramètre monétaire (percentRot) qui indique la proportion de membres calculant non-exclus du calcul a un instant T.
C’est pour cela que l’on dit qu’un tiers des membres calculant sont exclus à tout instant t. Cette exclusion étant justement assurée par le facteur d’exclusion exFact, l’objectif de ce passage est de montrer qu’un membre ne peut pas être exclus plus d’un tiers du “temps” de la fenêtre courante. Ce qui se traduit par le fait que son facteur d’exclusion doit valoir 1 si nbBlocksSince dépasse le tiers des membres calculant.
C’est moi qui aie écrit cet article, je pensais être rentré suffisamment dans le détail, je me rends compte avec tes remarques que certains détails n’ont pas été suffisamment précisés, merci de ta relecture, ça fait plaisir de voir quelqu’un essayer de vraiment comprendre mon article a fond, tu es le 2ᵉ après @thomasbromehead (le traducteur)
