Compare revisions

thomasbromehead · Éloïs · Moul · Moul · Thomas Bromehead · Éloïs
--- a/.gitignore
+++ b/.gitignore
@@ -5,7 +5,6 @@ include/
 lib/
 local/
 output/
-pelican-plugins/
 pelican.pid
 pelicanconf.pyc
 pip-selfcheck.json

--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
+stages:
+  - build
+  - package
+  - release
+  - deploy
+build-job:
+  image: python:slim
+  stage: build
+  rules:
+    - if: '$CI_COMMIT_BRANCH'
+  script:
+    - mkdir -p /usr/share/man/man1 # Because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863199
+    - apt-get update && apt-get install -y plantuml graphviz
+    - pip install -r requirements.txt
+    - pelican content -s publishconf.py -e OUTPUT_PATH='"public"'
+  artifacts:
+    paths:
+      - public/
+    name: build
+    expire_in: 7 days
+package-job:
+  stage: package
+  image: curlimages/curl:latest
+  script:
+    - PACKAGE_VERSION="$(date +%Y.%m).${CI_PIPELINE_IID}"
+    - PACKAGE_REGISTRY_URL="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/releases/${PACKAGE_VERSION}"
+    - echo 'Creating generic package'
+    - cd public/
+    - tar cvf $HOME/website.tar *
+    - ls -al
+    - 'curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file $HOME/website.tar ${PACKAGE_REGISTRY_URL}/website.tar'
+  rules:
+    - if: '$CI_COMMIT_BRANCH == "master"'
+release-job:
+  stage: release
+  image: registry.gitlab.com/gitlab-org/release-cli:latest
+  rules:
+    - if: '$CI_COMMIT_BRANCH == "master"'
+  script:
+    - PACKAGE_VERSION="$(date +%Y.%m).${CI_PIPELINE_IID}"
+    - PACKAGE_REGISTRY_URL="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/releases/${PACKAGE_VERSION}"
+    - echo 'Creating release'
+    - release-cli create --name "$PACKAGE_VERSION" --tag-name $PACKAGE_VERSION --assets-link "{\"name\":\"wesbite.tar\",\"url\":\"$PACKAGE_REGISTRY_URL/website.tar\"}"
+pages:
+  stage: deploy
+  rules:
+    - if: '$CI_COMMIT_BRANCH == "master"'
+  script:
+    - echo "Publishing to Gitlab pages"
+  artifacts:
+    paths:
+      - public/
--- a/README.md
+++ b/README.md
@@ -8,14 +8,14 @@ You may want to reproduce this website locally, for developement purposes for ex
 Clone the sources
-    git clone https://github.com/duniter/website.git
+    git clone https://git.duniter.org/websites/website_en.git
 Install python stuff
-    cd website
+    cd website_en
-    virtualenv .
+    python3 -m venv .venv
-    source bin/activate
+    source .venv/bin/activate
-    pip install pelican pelican-youtube markdown beautifulsoup4
+    pip install -r requirements.txt
 Install system dependencies for plantuml plugin (plantuml and GraphViz utilities) :
 ```bash
@@ -25,10 +25,11 @@ apt install plantuml graphviz
 Generate the site
    pelican
+    # or python3 -m pelican
 Serve it
-    ./develop_server.sh restart 8557
+    pelican --listen --autoreload --port 8557 # port is hardcoded in develop conf file
 The website should be available at http://localhost:8557.
@@ -38,7 +39,7 @@ You just need to give the production configuration file to Pelican:
    pelican -s publishconf.py
-You may want to change the production parameters, like the domain name: just edit `publishconf.py` and modify the `SITEURL` to whatever value you want.
+You may want to change the production parameters, like the domain name: just edit `publishconf.py` and modify the `SITEURL` to whatever value you want. You can also override any other value simply by adding it.
 For example if you want to host the site at `https://my.website.org`, set:

--- a/content/2015-06-09-recap-of-the-5th-fmm-4-days-focusing-on-money-systems.md
+++ b/content/2015-06-09-recap-of-the-5th-fmm-4-days-focusing-on-money-systems.md
@@ -20,7 +20,7 @@ The presentation was in French, but I took the time to translate it in case you
 This day was an opportunity for client softwares to be presented. Let's see the two firsts: *CuteCoin* and *uCoinApps*.
 ### Cutecoin
-The morning was dedicated to [Cutecoin](https://github.com/duniter/sakia), the very first client of uCoin software. We steped through:
+The morning was dedicated to [Cutecoin](https://github.com/duniter/sakia), the very first client of uCoin software. We stepped through:
 *   Current state of the application
 *   Work to be done
@@ -75,21 +75,21 @@ The morning has seen the demonstration by Stéphane Laborde, the author of the R
 **The RTM in color** ([english](http://cuckooland.free.fr/TheRtmInColor.html) or [french](http://cuckooland.free.fr/LaTrmEnCouleur.html) version) is a brilliant web application to simulate and explore the concepts of a Freedom Money.
-![](/content/images/2015/08/rtm_in_color-1024x664.png)
+![Screenshot of the "The RTM in color" tool](/content/images/2015/08/rtm_in_color-1024x664.png)
 **The RTM for the kids** (available in [french](http://cuckooland.free.fr/LaTrmPourLesEnfants.html) only) is an interactive presentation trying to explain what is a Freedom Money and the RTM to kids, thanks to Elise and its fairy friend:
-![](/content/images/2015/08/rtm_for_the_kids.png)
+![Image of the RTM for kids](/content/images/2015/08/rtm_for_the_kids.png)
 ### Subscription to metab_brouzouf currency
 The afternoon was the occasion for people to try Cutecoin and [subscribe to metab_brouzouf currency](http://forum.ucoin.io/t/subscribing-to-meta-brouzouf-testing-currency)! As you can see, we now are about 23 active members testing uCoin:
-![](/content/images/2015/08/wot_fmm5.png)
+![A web of trust snapshot](/content/images/2015/08/wot_fmm5.png)
 And here is the currency overview:
-![](/content/images/2015/08/metab_fmm5.png)
+![uCoin currency snapshot](/content/images/2015/08/metab_fmm5.png)
 ## Conclusion

--- a/content/2016-03-22-bye-metabrouzouf.md
+++ b/content/2016-03-22-bye-metabrouzouf.md
@@ -17,7 +17,7 @@ For those who hadn't followed closely this experiment, here are some recalls to
 The uCoin project started during summer 2013. After a year and a half of development, on January 2015, the bases were considered established and the first pieces of code ready to be tested. It was then important to propose a first currency, was it a testing one, to allow other developers to produce *client softwares* equiped with graphical interfaces easing the money usage.
-<center>[![](https://camo.githubusercontent.com/39705402deb44e50a1b48b5ed1206394593278dd/68747470733a2f2f7261772e6769746875622e636f6d2f75636f696e2d696f2f73616b69612f6d61737465722f73616b69612e706e67)](http://sakia-wallet.org)</center> <center>_Logo of the first client: Sakia software_</center>
+<center>[![Sakia logo](https://camo.githubusercontent.com/39705402deb44e50a1b48b5ed1206394593278dd/68747470733a2f2f7261772e6769746875622e636f6d2f75636f696e2d696f2f73616b69612f6d61737465722f73616b69612e706e67)](http://sakia-wallet.org)</center> <center>_Logo of the first client: Sakia software_</center>
 Indeed, even if uCoin is the software at the heart of the money, its role *is not* to manage *your* transactions specifically, *but to handle any document* making it possible to live.
@@ -40,7 +40,7 @@ We can only observe that this objective, at the end of the experiment, was reach
 It's worth noting an active contributor of [YunoHost](http://yunohost.org) team also developed [a uCoin packet for YunoHost](https://github.com/duniter/duniter_ynh) greatly easing the installation of uCoin for self-hosting addicted people!
-<center>[![](https://avatars1.githubusercontent.com/u/1519495?v=3&s=200)](http://yunohost.org/)</center>
+<center>[![YunoHost logo](https://avatars1.githubusercontent.com/u/1519495?v=3&s=200)](http://yunohost.org/)</center>
 ### The known limits
@@ -60,8 +60,6 @@ Finally, the lifetime of **1 month** for certifications and memberships is way t
 For these reasons, no chance for this money to stay in time.
-<center>![](http://forum.ucoin.io/uploads/default/original/1X/da2e4d72317b4bb205d2b56001bb1add75435113.png)</center>
 ## The experiment results
 Despite these parameters which promised the early end of this testing currency, this latter totaly played its role notably because [several client software were borns](#thefirstclients), but also no less than **115 users** have actively participated the currency, and this despite of the project youth which requires a certain effort to reach the status of individual creating money.
@@ -113,5 +111,3 @@ As said earlier, this testing currency was an occasion to discover the limits of
 We have already implemented its next version **0.2** which carries a lot of newness. And so, what will happen?
 The next couple of weeks will tell you.
-<center><div style="width: 400px">![](http://forum.ucoin.io/uploads/default/original/1X/5deea7ee59d908a917eb2f099d44e8ee05e50198.png)</div></center> 
--- a/content/2016-04-04-transactions-0-2-overview.md
+++ b/content/2016-04-04-transactions-0-2-overview.md
@@ -26,7 +26,7 @@ But this protocol didn't let us create advanced features really important about
 uCoin is a software which identifies its users thanks to a [web of trust](https://en.wikipedia.org/wiki/Web_of_trust). For the individuals to be identified, they certify a trust of existence and uniqueness. This act, from individual to individual, composes a web which lets anyone knowing who is recognized by whom. However, for the individuals to be recognized, and to stop [sybil attacks](https://en.wikipedia.org/wiki/Sybil_attack) from happening, this web has to be tense and tight. A sybil attack consists in creating many fake identities to take the control of the network and the monetary community. Important efforts have to be executed for a cheater to multiply identities, so that cheating remains a minor factor.
-The consequence is that individuals have to be able to create many communities (and so, many moneys). Indeed, the web of trust is of a limited diameter (we will talk in details about it in a later article). Individuals need to be able to create many monetary communities so that any individual has the right to co-create a free money. Furthermore, creating many communities let us test many web of trust rules, looking for the best parameters. Thus, dozens of communities could potentially exist, and will have to exchange their money thanks to change rates. This exchange relationships has to be as automated as possible so that it is transparent for the users. Also, we would like to avoid having to introduce any trusted third party.
+The consequence is that individuals have to be able to create many communities (and so, many currencies). Indeed, the web of trust is of a limited diameter (we will talk in details about it in a later article). Individuals need to be able to create many monetary communities so that any individual has the right to co-create a free money. Furthermore, creating many communities let us test many web of trust rules, looking for the best parameters. Thus, dozens of communities could potentially exist, and will have to exchange their money thanks to exchange rates. This exchange relationships has to be as automated as possible so that it is transparent for the users. Also, we would like to avoid having to introduce any trusted third party.
 <center>![Swap exchange](https://framapic.org/uyFv0qtS0yjG/kWXNVu4DAmDg)</center>
@@ -37,49 +37,49 @@ In protocol 0.1, it is not possible to automate this inter-community exchange. I
 You see: we had to find a solution and enhance our blockchain.
 ## Never reinvent the wheel
-Bitcoin universe is rich, after 7 years of experimentation, their blockchain suffered by defects. Developers had to answer to many limitations, and had to create new features often. Even today, Bitcoin community continues to evolve and to think about developments to realize to enhance this software.
+Bitcoin universe is rich, after seven years of experimentation, their blockchain suffered of defects. Developers had to answer to many limitations, and had to oftenly create new features. Even today, Bitcoin community continues to evolve and to think about developments to be realize in orderto enhance the software.
 In Bitcoin blockchain, it is notably possible to program [scripted transactions](https://en.bitcoin.it/wiki/Script) in a language which is not [turing complete](https://en.wikipedia.org/wiki/Turing_completeness). This scripting language let us experiment and realize new features using Bitcoin blockchain, without having to develop new versions of the software.
-Bitcoin universe has also seen many [alternate crypto-currencies](https://coinmarketcap.com/) appear. Often, these forks are realized using simple cipher algorithm changes, or consensus algorithms. These alternative currencies let them users get their part of monetary creation, because Bitcoin does not anymore. Indeed, first miners have reaped everything, and one must now work for them to get his share.
+Bitcoin universe has also seen many [alternate crypto-currencies](https://coinmarketcap.com/) appear. Often, these forks are realized using simple cipher algorithm changes, or consensus algorithms. These alternative currencies let this users get their part of monetary creation, as Bitcoin does not allow it anymore. Indeed, first miners have reaped everything, and one must now work for them to get his share.
-For users to realize safe places of change, the algorithm of crosschain transactions appeared. It makes users of distinct moneys be able to exchange between them monetary units without trusted third party, and without the need to trust each other. These units are present in different blockchains, and yet, crosschain exchange will link the exchange between the two blockchains.
+For users to realize safe places of change, the algorithm of crosschain transactions appeared. It gives users of distinct currencies the ablility to exchange between them monetary units without trusted third party, and without the need to trust each other. These units are present in different blockchains, and yet, crosschain exchange will link the exchange between the two blockchains.
 <center>![Protocol 0.2 swap transactions](https://framapic.org/GsAAbeI5Nk6B/NyzAFH2sPuoS)</center>
-Previous example presents an ideal case, where Alice and Mark exchange their money without any interruption in the process. You should note that money can here get stuck in the blockchain : if Mark sends his money to Alice, and Alice does not answer anymore, Mark cannot get his money back. This is why it is necessary to introduce refund documents in the process. These documents are transactions which refund money owners. The algorithm is a bit more complex, so hang on :
+Previous example presents an ideal case, where Alice and Mark exchange their money without any interruption in the process. You should note that money can get stuck here in the blockchain: if Mark sends his money to Alice, and Alice does not answer anymore, Mark cannot get his money back. This is why it is necessary to introduce refund documents in the process. These documents are transactions which refund money owners. The algorithm is a bit more complex, so hang on:
 <center>![protocol 0.2 refund](https://framapic.org/to5m3slfBWjb/3h2TUn0Wk1Ws)</center>
 ## Keep It Simple
-To develop a scripting language into our transactions would have necessitate to much efforts, while we do not want our blockchain to transform in an application blockchain. We decided to develop this transaction mechanism in his simplest form : a writable condition in the blockchain.
+To develop a scripting language into our transactions would have necessitate to much efforts, while we do not want our blockchain to be transformed into an application blockchain. We decided to develop this transaction mechanism in its simplest form: a writable condition in the blockchain.
-How does it works concretely ? Transactions still have a form of *Input* -> *Output*. Input his what is available for spending, while the output corresponds to money which will become available for spending for the recipient. But new elements makes their apparition : *Unlock parameters* and *locking conditions* of the money placed in this transaction. In practice, this change is simple. The transaction is now of the form of *Input* -> *Unlock* -> *Output lock*. The form a transaction is like the following :
+How does it works concretely? Transactions still have a form of *Input* -> *Output*. Input is what is available for spending, while the output corresponds to money which will become available for spending for the recipient. But new elements makes their apparition: *Unlock parameters* and *locking conditions* of the money placed in this transaction. In practice, this change is simple. The transaction is now of the form of *Input* -> *Unlock* -> *Output lock*. The form of a transaction is like the following:
 ```
-ISSUERS: List of identifiers of the signers of this transaction
+ISSUERS: List of public keys of the signers of this transaction
-INPUTS: List of source transaction, to which the signers must be the owners
+INPUTS: List of sources of money, which the signers must be the owners
-UNLOCKS : List of unlock paremeters of the inputs
+UNLOCKS: List of unlock parameters of the inputs
-OUTPUTS: Locking conditions of the money
+OUTPUTS: Locking conditions of the sources of money
 SIGNATURES
 ```
-2 types of locks are possibles.
+Two types of locks are available:
-* A lock **SIG(PUBKEY)** which means *The signature of PUBKEY is necessary to use this money*.
+* **SIG(PUBKEY)** lock, which means *The signature of PUBKEY is necessary to unlock the source of money*.
-* A second lock is **XHX(HASH)**, which means *X number generating HASH is necessary to use this money*.
+* **XHX(HASH)** lock, which means *X number generating HASH is necessary to unlock the source of money*.
-These locks can be combined with operators **OR** and **AND**. Finally, it is possible to place a temporal lock **LOCKTIME** on a transaction. This lock prevents a transaction from being written in the blockchain before a fixed time.
+These locks can be combined with **OR** and **AND** operators. Finally, it is possible to place a temporal lock **LOCKTIME** on a transaction. This lock prevents a transaction from being written in the blockchain before a fixed time.
 ## Some examples of the new possibilities
-Our simple transaction of 0.1 protocol transforms into a new form. To send money to public key **A** we place a locking condition **SIG(A°** meaning *Transaction has to be signed by pubkey A for this money to be unlocked*.
+Our simple transaction from v0.1 of the protocol are transformed into a new form. To send money to public key **A** we place a locking condition **SIG(A°** meaning *Transaction has to be signed by pubkey A for this money to be unlocked*.
-To send money to a pubkey **A**, while retaining control of the time it will be spendable, we will use a lock **XHX(HASH)** combined with a **SIG(A)**. We will choose a number **X** which, hashed, will generate the **HASH**. We will give this number **X** to **A** only when we will want him to be able to spend his money, for example when he did do his part of a contract.
+To send money to a pubkey **A**, while retaining control of the time it will be spendable, we will use a lock **XHX(HASH)** combined with a **SIG(A)**. We will choose a number **X** which, hashed, will generate the **HASH**. We will give this number **X** to **A** only when we will want him to be able to spend his money, for example when he will have fulfilled his part of the contract.
 We can also consider to implement *consumable* bills. A bill will be locked on a money consumable only by a secret number hidden in the bill. Physical destruction of the bill will reveal the number and let one get the money. A lot of physical destruction means are possible, like tickets to scratch, a chemical revealer, etc.
-These are only first ideas we had while discussing between us. These new protocol rules will allow a lot of new systems to be developed, always more decentralized. The developers only need to appropriate these new means and develop new applications, for individuals to become always more free !
+These are only first ideas we had while discussing between us. These new protocols rules will allow a lot of new systems to be developed, always more decentralized. The developers only need to appropriate these new means and develop new applications, for individuals to become always more free!
-Article redacted by [@Inso](https://twitter.com/_inso), uCoin contributor and founder of Sakia client 
+Article written by [@Inso](https://twitter.com/_inso), uCoin contributor and founder of Sakia client
--- a/content/2016-10-17-release-0.40.md
+++ b/content/2016-10-17-release-0.40.md
@@ -9,5 +9,3 @@ Thumbnail: /images/box.svg
 Duniter upgrades again to a superior version and is now very close to exploitation level! This version allows to tune the last technical details before thinking seriously about the setup of a real, in-production libre money.
 To get more details concerning this version, and to update your installation, [please go to the official announcement (french)](https://forum.duniter.org/t/nouvelle-version-0-40-vers-un-protocole-dexploitation/1334) made on the forum.
-![](https://forum.duniter.org/uploads/default/optimized/2X/e/e77c36e74254de2b20365284782b956eef96a496_1_690x417.png)
--- a/content/2017-06-07-gune-test.md
+++ b/content/2017-06-07-gune-test.md
@@ -78,7 +78,7 @@ PercentRot: 0.67 # => 33.5% of calculators are excluded
 ### With Duniter Desktop:
-![](./images/gune-test-restarted/sync.png)
+![Screenshot showing how to synchronize](./images/gune-test-restarted/sync.png)
 ### With Duniter Server:

--- a/content/2017-06-07-videos-rml9.md
+++ b/content/2017-06-07-videos-rml9.md
@@ -20,7 +20,7 @@ You will also find the interventions of:
 * Eloïs which presents its specialized node [duniter-currency-monit](https://github.com/duniter/duniter-currency-monit)
 * Kimamila which presents the new features of Cesium
-![](./images/rml9/paperwallet.png)
+![A Paperwallet](./images/rml9/paperwallet.png)
 ## RML10 in Montpellier

--- a/content/2017-06-13-duniter-rmll2017.md
+++ b/content/2017-06-13-duniter-rmll2017.md
@@ -6,7 +6,7 @@ Slug: duniter-rmll2017
 Authors: cgeek
 Thumbnail: /images/calendar.svg
-[![](../images/rmll2017.png)](https://2017.rmll.info/)
+[![RML banner](./images/rmll2017.png)](https://2017.rmll.info/)
 The 2017 Worldwide Free Software Meeting (RMLL) will take place in Saint-Étienne from 1st to 7th July 2017.

--- a/content/2017-06-13-duniter-version-1.3.md
+++ b/content/2017-06-13-duniter-version-1.3.md
@@ -36,11 +36,11 @@ The Cesium client was historically delivered with Duniter. With the arrival of m
 ## Synchronization
-> <span class="icon">![](../images/icons/white_check_mark.png)</span> No need to resynchronize. 
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span> No need to resynchronize. 
 ## Compatibility
-> <span class="icon">![](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
 -----

--- a/content/2017-06-14-new-website.md
+++ b/content/2017-06-14-new-website.md
@@ -15,7 +15,7 @@ In reality, it goes beyond a simple ergonomic change. Small tour of the owner.
 First, the ergonomics was revised: we wanted the site to be more attractive and not hinder its consultation. Some extra images and a revised layout avoid a too austere reception:
-![]({filename}./images/rework/change.png)
+![Screenshot of the website before and after the change]({static}./images/rework/change.png)
 ## A fully editable site
@@ -23,7 +23,7 @@ One of the great novelties: the site is now [entirely editable](../wiki/enhance-
 You will find on each page in the sidebar a button "Edit page on GitHub" or "Edit article on GitHub". It looks like this:
-![]({filename}./images/wiki/btn_modifier.png)
+![Screenshot of the newly available edit button]({static}./images/wiki/btn_modifier.png)
 You will be able to propose modifications or even add new content to this site. A simple validation of our part, and here is the modified site!

--- a/content/2017-07-05-duniter-correctif-version-1.3.14.md
+++ b/content/2017-07-05-duniter-correctif-version-1.3.14.md
@@ -18,11 +18,11 @@ This patch has been tested on a network node Ğ1, which immediately reveals node
 ## Synchronization
-> <span class="icon">![](../images/icons/white_check_mark.png)</span>No need to resynchronize.
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span>No need to resynchronize.
 ## Compatibility
-> <span class="icon">![](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
 -----

--- a/content/2017-08-011-duniter-v1.4.md
+++ b/content/2017-08-011-duniter-v1.4.md
@@ -20,11 +20,11 @@ For details on all these changes, see [release notes](https://github.com/duniter
 ## Synchronization
-> <span class="icon">![](../images/icons/white_check_mark.png)</span> No need to resynchronize.
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span> No need to resynchronize.
 ## Compatibility
-> <span class="icon">![](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
 -----

--- a/content/2017-08-22-duniter-v1.5.md
+++ b/content/2017-08-22-duniter-v1.5.md
@@ -21,11 +21,11 @@ This new version brings mainly a lot of important fixes for the stability of the
 ## Synchronization
-> <span class="icon">![](../images/icons/white_check_mark.png)</span> No need to resynchronize.
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span> No need to resynchronize.
 ## Compatibility
-> <span class="icon">![](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
+> <span class="icon">![White check mark](../images/icons/white_check_mark.png)</span> Compatible with Ğ1.
 -----

--- a/content/2017-09-02-rapport-etat-toile.md
+++ b/content/2017-09-02-rapport-etat-toile.md
@@ -17,7 +17,7 @@ The objective of these short regular reports is not to be exhaustive, but rather
 If you regularly read my reports, which you regularly read *g1-monit* and you want to write reports, you can [contact me](https://librelois.fr/contact/) to be discussed :)
 # Prerequisites
-Before reading these reports, it is strongly recommended that you review the [license Ğ1](https://duniter.org/en/files/licence_g1.txt) and read all the following pages:
+Before reading these reports, it is strongly recommended that you review the [license Ğ1](https://duniter.org/en/files/license_g1.txt) and read all the following pages:
 * [Becoming a member of the Ğ1 web of trust](https://duniter.org/en/wiki/become-member)
 * [**How the web of trust works**](https://duniter.org/fr/introduction-a-la-toile-de-confiance/)

--- a/content/2018-06-18-deep-dive-duniter-web-of-trust.md
+++ b/content/2018-06-18-deep-dive-duniter-web-of-trust.md
@@ -76,7 +76,7 @@ It is of the utmost importance that we remain free from any state or corporation
 * __In-degree of vertex A__: number of incoming edges / head ends to A.
-![degress of a vertex diagram]({filename}/images/wiki/degrees.jpg)
+![degress of a vertex diagram]({static}/images/wiki/degrees.jpg)
 * __Path__: -aka “walk”- path to follow to get from vertex A to vertex B. 
@@ -116,7 +116,7 @@ This calls for a temporary ‘buffer’ storage space for
 # Exploring the rules behind a Duniter Web of Trust
-The Duniter WoTs -one per currency- work with a set of 8 fundamental rules, themselves enforced through 11 different parameters. Ten of these parameters are set within the genesis block, the eleventh one - `msPeriod`- having being hard-coded in the Ğ1’s code subsequently.
+The Duniter WoTs -one per currency- work with a set of eight fundamental rules, themselves enforced through eleven different parameters. Ten of these parameters are set within the genesis block, the eleventh one - `msPeriod`- having being hard-coded in the Ğ1’s code subsequently.
 ## 1.Distance rule and referent members (`stepMax` and `xPercent`)
@@ -128,11 +128,11 @@ The Duniter WoTs -one per currency- work with a set of 8 fundamental rules, them
 Let’s now define the distance rule:
-> **Distance rule** : member A is said to observe this rule if and only if for a subset xPercent % of referent members R there exists a path of length less than or equal to `stepMax` between R and A.**
+> **Distance rule**: member A is said to observe this rule if and only if for a subset `xPercent`% of referent members R there exists a path of length less than or equal to `stepMax` between R and A.**
 Referent members only exist so that the distance rule can take effect, they have no special privileges over non-referent members.
 In a perfect web, that is one in which each member has certified all members he/she legitimately can, all members would be referent members. However, because the web progressively grows in size and because members die and are replaced by new ones, there are always members at any given time `t` who haven’t yet certified all members they legitimately could. These members would hinder the evolution of the web if they were taken into account in the calculation of the distance rule and the web would effectively stop growing. 
-You can see what would happen if the notion of ‘referent member’ didn’t exist by going to the ‘gaussianWotQuality’ page on [currency-monit](https://g1-monit.librelois.fr/gaussianWotQuality?lg=en&unit=quality) and activating ‘if the concept of referent members didn’t exist’-.
+-You can see what would happen if the notion of ‘referent member’ didn’t exist by going to the ‘gaussianWotQuality’ page on [currency-monit](https://monit.g1.nordstrom.duniter.org/gaussianWotQuality?lg=en&unit=quality) and activating ‘if the concept of referent members didn’t exist’-.
 > **When is the distance rule applied?**
@@ -153,14 +153,13 @@ Every single member -or old member who hasn’t revoked his identity or been exc
 A new request will be stored in the ‘pool’ for a maximum of `msWindow` seconds before it’s included in the blockchain. Once again, this can only happen once/if the member meets both the `siqQty` rule and the distance rule -if these criterion are already matched it’s just a case of waiting for a new block to be mined-.
 If a member hasn’t requested a renewal for longer than `msValidity` seconds, he/she automatically ceases being a member. From this moment on, the ex-member has another `msValidity` window to renew his/her membership.
-When this period of 2 * `msValidity’ runs out, the membership will expire and this identity will never be available for use again in the web. If the person so desires, he/she will have to start from zero to regain access to the WoT.
+When this period of `2 × msValidity` runs out, the membership will expire and this identity will never be available for use again in the web. If the person so desires, he/she will have to start from zero to regain access to the WoT.
-## 4. Rule of certification lifespan (`sigValidity`
+## 4. Rule of certification lifespan (`sigValidity`)
-)
-All certifications included in the blockchain expire **sigValidity** seconds after they were **issued**.
+All certifications included in the blockchain expire `sigValidity` seconds after they were **issued**.
-/!\ The issuance and the inclusion of a certification in the blockchain occur at different times. When member A issues a certification at time t1, it gets stored in the pool starting at t1 and only finds its way into the blockchain at t2 when all of the web’s rules are observed. Several weeks can thus go by between t1 and t2!!!
+/!\ The issuance and the inclusion of a certification in the blockchain occur at different times. When member A issues a certification at time _t1_, it gets stored in the pool starting at _t1_ and only finds its way into the blockchain at _t2_ when all of the web’s rules are observed. Several weeks can thus go by between _t1_ and _t2_!
 ## 5. Rule of limited supply of active certifications (`sigStock`)
@@ -168,7 +167,6 @@ By ‘active certifications’ we refer to certifications included in the blockc
 The total of active certifications issued by any member at any single time must be less than or equal to `sigStock`. When this threshold is reached the member will have to wait for one of his active certifications to expire before he/she can issue a new one. 
 ## 6. Rule of the time period between two certification issuances. (`sigPeriod`)
 As soon as a certification issued by member A gets included in the blockchain, he/she will be unable to issue a new one before another `sigPeriod` seconds.
@@ -197,38 +195,38 @@ As soon as the genesis block has been created, the other identities can start mi
 The distance rule is there to curb the maximum size of a Sybil region as well as that of the monetary community as a whole. The `xpercent` parameter prevents the creation of a ‘faction’ that could take hold of the blockchain.
-![Sybil region]({filename}/images/wiki/wot-sybil.jpg)
+![Sybil region]({static}/images/wiki/wot-sybil.jpg)
 The Sybil regions are isolated from the rest of the graph in the sense that they can only receive certifications from other ill-intentioned Sybil members. As a consequence, the shortest edge/path between a legitimate member and a Sybil one has to have the attack’s author as an endpoint. The maximum depth the Sybil region can attain is therefore contingent on the distance between the attacking edge-s- and the xpercent% closest referent members, this distance is known as `stepAttackers`.
 The maximum size of a Sybil region created by `sigQty` members depends on the L parameter, defined as L = sigQty/sigStock:
-    Maximum Sybil region size = -sigStock-sigQty-*-1-L^-stepMax-stepAttackers--/-1-L-
+    Maximum Sybil region size = (sigStock-sigQty)*(1-L^(stepMax-stepAttackers))/(1-L)
 The maximum size of the Web of Trust is given by the following formula:
-    WoTmax = -sigStock-*L^-stepMax-1-
+    WoTmax = (sigStock)*L^(stepMax-1)
-However we know for a fact that members will never use all of their available certifications. Many studies have proven that we all know a maximum average of 50 people, let’s then replace sigStock by 50:
+However we know for a fact that members will never use all of their available certifications. Many studies have proven that we all know a maximum average of fifty people, let’s then replace sigStock by fifty:
-  WoTavg= -50-*-sigQty/50-^-stepMax-1-
+    WoTavg= (50)*(sigQty/50)^(stepMax-1)
-Our goal with the Ğ1 is to create a community of about 1 million members enjoying the world’s first true [catallaxy](https://en.wikipedia.org/wiki/Catallaxy) -free economy with a spontaneous order of things-. Let’s see how we can tweak the pair of sigQty and stepMax- to reach this size:
+Our goal with the Ğ1 is to create a community of about one million members enjoying the world’s first true [catallaxy](https://en.wikipedia.org/wiki/Catallaxy) -free economy with a spontaneous order of things-. Let’s see how we can tweak the pair of sigQty and stepMax- to reach this size:
-![graphe WoTmoy en fonction de sigQty et stepMax]({filename}/images/wiki/graph-WoTmoy.png)
+![graphe WoTmoy en fonction de sigQty et stepMax]({static}/images/wiki/graph-WoTmoy.png)
 The maximum size of a Sybil region grows linearly with `sigQty` but exponentially with `stepMax`. Logic has it that we need to keep `stepMax` as low as possible to ensure sufficient strength to the web. The above graph shows that the lowest value of `stepMax` for a web of a million members is of 5. This is an order of magnitude and is likely to be much higher in reality, we cannot measure it for sure.
-For `sigQty` we can choose a value of **4** for a web of **1.5 million members** or **5** for **half a million members**. Calculating WOTavg gives us a pretty good idea of how the web would scale bearing in mind that it considers all members are referent members too -which isn’t the case as explained previously-. Hence the maximum size of the web is likely larger, a ballpark figure of half a million is enough for now especially knowing that the smaller `sigQty` is, the easier it is to launch a Sybil attack -it’s easier to find four accomplices than five-. For security reasons we have settled on five:
+For `sigQty` we can choose a value of **4** for a web of **1.5 million members** or **5** for **half a million members**. Bear in mind these are gross figures and could be significantly higher, we are talking anywhere between 1 and 10 million in reality. Calculating WOTavg gives us a pretty good idea of how the web would scale bearing in mind that it considers all members are referent members too -which isn’t the case as explained previously-. Hence the maximum size of the web is likely larger, a ballpark figure of half a million is enough for now especially knowing that the smaller `sigQty` is, the easier it is to launch a Sybil attack -it’s easier to find four accomplices than five-. For security reasons we have settled on five:
 stepMax = 5
 sigQty = 5
 sigStock >= 50
-The maximum size of a Sybil region therefore is : `-sigStock-sigQty-*-1--sigStock/5-^-5-stepAttackers--/-1--sigStock/5--`
+The maximum size of a Sybil region therefore is: `(sigStock-sigQty)*(1-(sigStock/5)^(5-stepAttackers))/(1-(sigStock/5))`
-with sigStock = 50 we have a Sybil region of  : `45*-1-10^-5-stepAttackers--/--9-`
+with sigStock = 50 we have a Sybil region of: `45*(1-10^(5-stepAttackers))/(-9)`
-A good practice for protecting the web is to maximise `stepAttackers`. That’s why we decided that referent members in the genesis block had to be at least 4 steps away from each other.
+A good practice for protecting the web is to maximise `stepAttackers`. That’s why we decided that referent members in the genesis block had to be at least four steps away from each other.
 Another way to keep a Sybil attack at bay, were it slow enough for members to notice it, would be for referent members to ‘stretch’ the web intentionally to limit the growth of the region by ensuring that the attackers’ legitimate certifications received in the first place aren’t renewed. 
 But what if bot accounts were created and certified each other super fast and following all rules, how would we counter that?
@@ -241,27 +239,27 @@ To help us deter a Sybil attack, we’ve decided to impose a minimum period of t
 Here is a graph showing the evolution of a Sybil region with the variation of `sigPeriod`:
-![graph of the WoT's size according to sigPeriod and stepAttackers]({filename}/images/wiki/impact_sig_period.png)
+![graph of the WoT's size according to sigPeriod and stepAttackers]({static}/images/wiki/impact_sig_period.png)
 As you’ll easily be able to tell, there is a strong link between the growth speed of the region and `sigPeriod`. As evidenced here, we need a `sigPeriod` high enough in order to ensure that the legitimate web can grow at least as fast as a Sybil region.
 In addition, the higher `sigPeriod` is, the more members will exercise their certification power gingerly, the action coming at a higher ‘cost’.
-There are numerous advantages to giving `sigPeriod` a high value and no technical barriers to it, hence our choice of 5 days. 
+There are numerous advantages to giving `sigPeriod` a high value and no technical barriers to it, hence our choice of five days. 
-We could have also gone for 7 days -1 week- for the sake of simplicity however there was an underlying idea behind our choice which was quite simply the pace of today’s life. 
+We could have also gone for seven days -one week- for the sake of simplicity however there was an underlying idea behind our choice which was quite simply the pace of today’s life.
-Certifying someone can be a lengthy process as one needs to make sure he/she is correctly applying the Ğ1 license and people nowadays wait for the weekend to enjoy a bit of free-time. Thus the idea to allow one to certify at the end of every working week -5 days- instead of a whole calendar one.
+Certifying someone can be a lengthy process as one needs to make sure he/she is correctly applying the Ğ1 licence and people nowadays wait for the weekend to enjoy a bit of free-time. Thus the idea to allow one to certify at the end of every working week -five days- instead of a whole calendar one.
 ## 3. Trust me now, trust me forever? (`sigValidity`, `msValidity`)
 There would be two main drawbacks to a lifetime membership in the Ğ1’s Web of Trust:
->1	First of all we need to take into account that some members will pass and those accounts should no longer produce the Universal Dividend. 
+>First of all we need to take into account that some members will pass and those accounts should no longer produce the Universal Dividend. 
->2 Secondly it is of the utmost importance that ‘rogue’ accounts can be excluded from the web at some point.
+>Secondly it is of the utmost importance that ‘rogue’ accounts can be excluded from the web at some point.
 To achieve this, certifications have a limited lifetime and members need to seek renewal from their peers after `sigValidity` time. On the other hand, this time can’t be too short that members would spend more time seeking renewal than they would exchanging in the currency.
 Furthermore, a certification with too short a lifetime would foster careless certifying behaviours. The act of certifying must have a ‘perceived’ cost high-enough to make it feel like an important act.
 Lastly, we also wanted this lifetime to be easy enough to remember. 
 Historically speaking, we first settled on the values of 
-`sigPeriod` and `sigStock`, meant one could issue all of his/her certifications in 495 days, one year was therefore not long enough. We deemed 3 years to bee much and that’s how we agreed on 2 years in the end.
+`sigPeriod` and `sigStock`, meant one could issue all of his/her certifications in 495 days, one year was therefore not long enough. We deemed three years to be too much and that’s how we agreed on two years in the end.
 Thinking that a deceased member could continue producing the UD for two long years without anyone benefitting from it was also something we needed to address.
 We choose a value of one year for **msValidity**. The act of renewing every year is done through one of the clients interacting with the blockchain, through a simple click on a button.
@@ -279,13 +277,13 @@ We settled on two months, and gave this value to all three parameters `idtyWindo
 ## 5. Avoiding single members from ‘knowing too many people’ (`sigStock`)
-Many sociology studies have shown that we all know an average of 50 people. This of course is an average, some of us know more than 50 people, others much less.
+Many sociology studies have shown that we all know an average of fifty people. This of course is an average, some of us know more than fifty people, others much less.
 Once again we went for a number that would be easy to remember. 
-Although `sigStock`’s impact on the size of a Sybil region is fairly limited, its value nonetheless has to be kept reasonable. We settled on 100.
+Although `sigStock`’s impact on the size of a Sybil region is fairly limited, its value nonetheless has to be kept reasonable. We settled on hundred.
 ## 6. Avoiding locking minorities (`xpercent`)
-It’s easy enough to become a referent member, one of the Sybil strategies could therefore be to create a region of referent members. Such a region would grow slower than otherwise but could confer a locking power to its members by using the distance rule. That’s why the distance rule cannot be calculated on 100% of the referent members. Hence the introduction of the `xpercent` parameter which defines the percentage of referent members needing to be less than 5 edges -steps- from each other.
+It’s easy enough to become a referent member, one of the Sybil strategies could therefore be to create a region of referent members. Such a region would grow slower than otherwise but could confer a locking power to its members by using the distance rule. That’s why the distance rule cannot be calculated on 100% of the referent members. Hence the introduction of the `xpercent` parameter which defines the percentage of referent members needing to be less than five edges -steps- from each other.
 This percentage needs to be low enough to prevent the formation of a locking minority -referent Sybil members being too far from legitimate referent members-. On the other hand, it needs to be high enough so as to restrict the maximum size of the Sybil region through the distance rule. The `xpercent` parameter was one of the hardest to define, we therefore reserve ourselves the right of modifying its value during the Ğ1 experiment.
@@ -294,5 +292,5 @@ We were inspired by the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_
 ## 7. Spam protection with (`msPeriod`)
 This parameter stands out a bit on its own, as it was added after the genesis block. It is there to protect the Duniter P2P infrastructure against ‘spam’ attacks.
-We had to think of a strategy against attacks such as high-frequency membership renewal requests -i.e: in every block, every 5 minutes- or worse still, hundreds of these requests per minute to flood the Duniter nodes. 
+We had to think of a strategy against attacks such as high-frequency membership renewal requests -i.e: in every block, every five minutes- or worse still, hundreds of these requests per minute to flood the Duniter nodes. 
-Without such limits, nodes are supposed to address all renewal requests, even in cases where they were last published 5 minutes ago! The `msPeriod` parameter was given the same value as `idtyWindow`, `sigWindow` and `msWindow`, i.e. 2 months.
+Without such limits, nodes are supposed to address all renewal requests, even in cases where they were last published five minutes ago! The `msPeriod` parameter was given the same value as `idtyWindow`, `sigWindow` and `msWindow`, i.e. two months.
\ No newline at end of file
--- a/content/2022-04-21-duniter-substrate.md
+++ b/content/2022-04-21-duniter-substrate.md
+Title: Duniter v2 with Substrate 🏗
+Date: 2022-04-21
+Category: duniter
+Slug: duniter-substrate
+Authors: hugo
+Thumbnail: /images/logos/duniter.png
+[TOC]
+## A necessary and beneficial evolution 👍
+Duniter software has seen many evolutions since its launch [in April 2016](/ucoin-rename-duniter), and so have blockchain technologies. While at the time a "home-made" solution was relevant, we believe that it is now better to base our software on widely tested and proven bricks to ensure scalability. We found the [Substrate](https://substrate.io/) blockchain framework to be particularly well suited to our needs. Indeed, its modular architecture by "[pallet](https://docs.substrate.io/v3/getting-started/glossary/#pallet)" will let us assemble bricks developed by professionals and focus on what makes Duniter unique: its web of trust and the monetary creation by Universal Dividend (UD).
+### Migrating the Ğ1 🏆
+Duniter's first objective is to power the Ğ1 currency whose web of trust currently counts 4971 members with a 300 members / month growth rate. We want to work together with the community to make the transition towards Duniter v2 as smooth as possible without a "hard fork". Each member will keep his/her status, each wallet will keep its balance, the currency parameters will remain nearly unchanged, wallets (formerly "clients") software will be adapted, and we will try to make the transition as short as possible (ideally less than a day).
+### International outreach 🌍
+Unlike the "home-made" solution documented mainly in French, Substrate is opening us to an international community of developers. Duniter will bring what the cryptocurrency world is missing: a solid and sound monetary theory. Conversely, the cryptocurrency world will provide Duniter with the expertise needed to take the next step in experimenting with a free currency. To make understanding easier, we will be using a precise vocabulary [(fr)](https://forum.duniter.org/t/vocabulaire-de-base-pour-comprendre-duniter-v2s-lecture-fortement-recommandee-pour-tous/9053) already well established in the domain.
+### Blockchain as a common resource 🌲
+[🔗 forum (fr)](https://forum.duniter.org/t/comment-partager-equitablement-cette-ressource-commune-quest-la-blockchain-g1/9050/)
+Duniter v1 was already part of a comprehensive approach to treat blockchain as a **[common](https://en.wikipedia.org/wiki/Commons)**, <q> a resource that community manage for individual and collective benefit </q>. The migration to Substrate is an ideal opportunity to push the thinking further, by introducing *on-chain* governance tools for collective decisions (voting, protocol evolution) and the allocation of finite blockchain resources (ex. spam resistance).
+## Some technical points 👩💻
+Let's now move on to the technical part, where we deal with the concrete issues raised by this migration.
+### Dropping the PoW mechanism in favor for BABE/GRANDPA 👾
+[🔗 forum (fr)](https://forum.duniter.org/t/abandon-de-la-pow-au-profit-de-babe-grandpa/8901) [🔗 forum (fr)](https://forum.duniter.org/t/g1v2-proposition-de-passer-au-consensus-hybride-babe-grandpa/8610)
+Duniter's proof of work was often a criticised point. Although our custom [personalised difficulty](/wiki/duniter/2018-11-27-duniter-proof-of-work/#personalised-difficulty) which reduces the energy consumption and distributes the addition of blocks among blacksmiths, the [BABE](https://docs.substrate.io/v3/advanced/consensus/#babe) for block authoring and [GRANDPA](https://docs.substrate.io/v3/advanced/consensus/#grandpa) for finalization will allow us to greatly accelerate the data validation (~30 minutes → ~30 seconds) while limiting the "waste" of CPU resources.
+### Blacksmiths subweb 🌋
+[🔗 forum (fr)](https://forum.duniter.org/t/la-sous-toile-forgerons/9047)
+In Duniter v1, any member of the web of trust is given the rights to create the UD, certify, and add blocks all at once. This is a major security flaw because by hacking into 30 poorly secured accounts it is possible to take control of the entire blockchain. With the increasing number of users, it is better to decouple different rights to grant block authoring only under security conditions that cannot be imposed on the general public.
--- a/content/images/wiki/impact_sig_period-2.png
+++ b/content/images/wiki/impact_sig_period-2.png
--- a/content/pages/about.md
+++ b/content/pages/about.md
@@ -25,4 +25,4 @@ If the project takes off on long term, the creation of a Foundation is already c
 ## Contact
-More informations on the [Contact](/contact) page.
+Please get in touch on the [duniter forum](https://forum.duniter.org/).
\ No newline at end of file
No results found