Super ! Laquelle ? La justification de SigStock est une toute petite partie de la partie 3-Duniter Web of Trust, qui va être revue par @Lucas. Je t’inclus dans notre fil de MP.
J’aimerais bien avoir une version quasi-aboutie au 1er mai. Mais ça n’empêche pas de la retoucher après.
tiens si vous voulez faire de la rédaction collaborative sans passer par git (pour qu’il n’y ait pas que des codeurs qui le fassent) il existe un genre de framapad dédié au markdown: hackmd
C’est pas juste la même chose que CodiMD mais en privateur ?
Pour un tel document, le pad a l’inconvénient de ne pas avoir de validation a priori. On peut donc spammer, faire une erreur qui ne sera pas remarquée, et s’il n’y a pas d’historique, perdre des morceaux…
effectivement, j’avais pas vu que les sources n’étaient pas libres. je privilégie les outils libres le plus possible.
celui ci propose une intégration à git, je ne sais pas ce qu’il en est des autres.
avoir un historique oui c’est la base. je vois ce que tu veux dire, après il faut reconnaître qu’il n’y a pas énormément de gens pour écrire ces documents donc peu de chances de se faire vandaliser un texte.
ça conviendrait parfaitement à la rédaction d’un chapitre à plusieurs mains, surtout si les gens ne sont pas à l’aise avec git.
Il me semble qu’il y a dans ton papier une confusion entre les notions de « excluded » et de « revoked ». Est exclue une identité qui a été mais n’est plus membre, quelle qu’en soit la raison. Elle peut toutefois, sous certaines conditions, le redevenir. Est révoquée une identité qui ne peut plus redevenir membre.
Du coup, je ne vois que quatre catégories d’identités dans la toile (et la piscine), et non pas cinq : REVOKED (révoquée), MISSING (exclue mais non révoquée), MEMBER (membre) et NEWCOMER (nouvelle identité, en piscine seulement). Ces noms sont ceux utilisés dans la nouvelle version de WotWizard, bientôt disponible.
Chouette première version.
je n’ai pas encore tout lu mais j’ai déjà deux questions de relou:
les formules ne s’affichent pas en latex?
y’a une version française prévue ? (je lis l’anglais mais ça serait un plus énorme niveau comm que d’avoir ce livre blanc en Français, chez Btc et Eth ils sont dispos aussi en Fr)
petit ajout au dépot de whitepaper, la publication en html avec du style, et la compilation du livre blanc en epub, mobi et fb2.
j’y propose aussi un dossier pour la version FR (qui ne contient pour le moment que les textes en english en markdown) de chacun des chapitres et une table des matières pour la version HTML.
lancer bash publication.sh pour rebuilder le tout vers un dossier « built ».
le script de publication râle si il manque pandoc ou ebook-convert de Calibre.
Markdown n’est pas un standard, n’a pas de spécification. Chacun fait son markdown.
Quelque soit le logiciel utilisé pour décliner différents format (pandoc, sphinx, Jrst, etc), je préconise d’utiliser le format RestructuredText pour le White Paper (on peut s’inspirer des sources de la TRM en ligne qui est en RestructuredText et regorge de formules mathématiques) .
@matograine, je peux t’aider là dessus, si tu décides de basculer en RestructuredText.
Concernant les formule, j’ai trouvé une solution, c’est d’utiliser le script JS MathJax. Je l’ai fait sur la branche formule. Il y a un copyright à respecter (licence Apache).
Ce souci se serait posé de la même façon avec du Rst, je pense.
@Vit J’ai regardé un peu la syntaxe Rst, et elle semble avoir plus d’options (échelle des figures, numérotation, etc…). Ça me paraît une bonne idée de passer sur ce format, je vais approfondir.
Whitepaper ou pas Whitepaper ?
Le terme « whitepaper » me semble de moins en moins approprié :
le doc que je prévois ne contient aucune preuve mathématique,
au vu des découvertes de @Lucas, le fonctionnement de la TdC va changer dans les prochaines versions de Duniter,
d’autres évolutions de protocole sont à prévoir, selon @elois. Le WP pourrait être amené à changer.
Avoir un document descriptif est tout de même essentiel pour faciliter l’accueil de nouveaux contributeurs. J’utiliserai donc le titre « descriptif technique », daterai le document, et indiquerai dès le début qu’il s’agit du d’un descriptif basé sur le protocole DUBP v13.
Comme je ne rentre pas trop loin dans les détails, la réécriture de certaines parties sera nécessaires pour des gros changements uniquement:
règles de la TdC
difficulté personnalisée (l’augmentation n’est pas linéaire)
OK, je suis passé sur Sphinx, et effectivement, les formules sont bien mieux gérées. J’ai numéroté les formules et les figures. Merci à @SALLY pour sa relecture, j’ai reformulé certains points.
Je suis allé aussi loin que j’ai pu, et le résultat est ici : html et pdf.
enlever le chemin qui n’a pas lieu d’être tout en haut de la page
élargir la colonne de table des matières
enlever la dépendance à gstatic (Sphinx utilise des polices g**gle )
en PDF, les sources sont placées en bas de page, or j’aimerais aussi les avoir dans la partie « sources » en fin de doc, comme dans le html. Saurais-tu faire cela ?
@tykayn, désolé, j’ai dû abandonner ton travail en cours de route.
Je pense que c’est fini sur le fonds, une relecture serait bienvenue
Le dossier build pourrit l’historique Git, ne faudrait-il pas l’ajouter dans .gitignore ? Il faudrait alors que publication.sh copie les fichiers publiables dans un autre dossier non ignoré.
Les images sont en JPEG, ça serait plus propre de les générer en LaTeX ou d’inclure des SVG, au pire des PNG.