Fix Files for Linting (#94)

.github/workflows/.markdownlint.json

@@ -0,0 +1,6 @@
+{
+        "MD013": {
+                "tables": false,
+                "code_blocks" : false
+        }
+}

.github/workflows/markdown-lint.yml

@@ -19,5 +19,5 @@ jobs:
       - name: Markdown Linter
         uses: DavidAnson/markdownlint-cli2-action@v15
         with:
-          configFile: .github/workflows/markdownlint.json
+          config: .github/workflows/.markdownlint.json
           globs: '**/*.md'

README.md

@@ -2,38 +2,46 @@
 
 *NOTE*: This repo is WIP. We are currently restructuring the RFC process.
 
-This repository contains specifications from the [Waku](https://waku.org/), [Nomos](https://nomos.tech/), 
-[Codex](https://codex.storage/), and [Status](https://status.app/) projects that are part of the [IFT portfolio](https://free.technology/).
-[Vac](https://vac.dev) is an [IFT service](https://free.technology/services) that will manage the RFC, [Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments), process within this repository. 
+This repository contains specifications from the [Waku](https://waku.org/), [Nomos](https://nomos.tech/),
+[Codex](https://codex.storage/), and
+[Status](https://status.app/) projects thatare part of the [IFT portfolio](https://free.technology/).
+[Vac](https://vac.dev) is an
+[IFT service](https://free.technology/services) that will manage the RFC,
+[Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments),
+process within this repository.
 
 ## New RFC Process
 
 This repository replaces the previous `rfc.vac.dev` resource.
-Each project will maintain initial specifications in separate repositories, 
+Each project will maintain initial specifications in separate repositories,
 which may be considered as a **raw** specification.
-All [Vac](https://vac.dev) **raw** specifications and discussions will live in the Vac subdirectory.
-When projects have reached some level of maturity for a specification living in their repository,
+All [Vac](https://vac.dev) **raw** specifications and
+discussions will live in the Vac subdirectory.
+When projects have reached some level of maturity
+for a specification living in their repository,
 the process of updating the status to **draft** may begin in this repository.
-Specifications will adhere to [1/COSS](./vac/1/coss.md) before obtaining **draft** status.
+Specifications will adhere to
+[1/COSS](./vac/1/coss.md) before obtaining **draft** status.
 
 Implementations should follow specifications as described,
 and all contributions will be discussed before the **stable** status is obtained.
-The goal of this RFC process will to engage all interseted parities and 
+The goal of this RFC process will to engage all interseted parities and
 reach a rough consensus for techcinal specifications.
 
 ## Contributing
 
 Please see [1/COSS](./vac/1/coss.md) for general guidelines and specification lifecycle.
 
-Feel free to join the [Vac discord](https://discord.gg/Vy54fEWuqC). 
+Feel free to join the [Vac discord](https://discord.gg/Vy54fEWuqC).
 
 Here's the project board used by core contributors and maintainers: [Projects](https://github.com/orgs/vacp2p/projects/5)
 
 ## IFT Projects' Raw Specifications
 
 The repository for each project **raw** specifications:
+
 - [Vac Raw Specifications](./vac/raw)
 - [Status Raw Specifications](./status/raw)
 - [Waku Raw Specificiations](https://github.com/waku-org/specs/tree/master)
-- [Codex Raw Specifications]()
+- [Codex Raw Specifications](none)
 - [Nomos Raw Specifications](https://github.com/logos-co/nomos-specs)

codex/README.md

@@ -1,4 +1,5 @@
 # Codex RFCs
 
 Specifications related the Codex decentralised data storage platform.
-Visit [Codex specs](https://github.com/codex-storage/codex-spec) to view the new Codex specifications currently under discussion.
+Visit [Codex specs](https://github.com/codex-storage/codex-spec)
+to view the new Codex specifications currently under discussion.

nomos/README.md

@@ -1,6 +1,6 @@
 # Nomos RFCs
 
-Nomos is building a secure, flexible, and 
+Nomos is building a secure, flexible, and
 scalable infrastructure for developers creating applications for the network state.
 To learn more about Nomos current protocols under discussion,
 head over to [Nomos Specs](https://github.com/logos-co/nomos-specs).

status/24/curation.md

@@ -9,73 +9,98 @@ editor: Szymon Szlachtowicz <[email protected]>
 ---
 
 ## Abstract
-This specification is a voting protocol for peers to submit votes to a smart contract. Voting is immutable, 
+
+This specification is a voting protocol for peers to submit votes to a smart contract.
+Voting is immutable,
 this will help avoid sabotage from malicious peers.
 
 ## Motivation
 
-In open p2p protocol there is an issue with voting off-chain as there is much room for malicious peers to only include votes that support their case when submitting votes to chain.
+In open p2p protocol there is an issue with voting off-chain
+as there is much room for malicious peers to only include votes that support
+their case when submitting votes to chain.
 
-Proposed solution is to aggregate votes over waku and allow users to submit votes to smart contract that aren't already submitted.
+Proposed solution is to aggregate votes over waku and
+allow users to submit votes to smart contract that aren't already submitted.
 
 ### Smart contract
 
 Voting should be finalized on chain so that the finished vote is immutable.
 Because of that, smart contract needs to be deployed.
-When votes are submitted smart contract has to verify what votes are properly signed and that sender has correct amount of SNT.
-When Vote is verified the amount of SNT voted on specific topic by specific sender is saved on chain.
+When votes are submitted
+smart contract has to verify what votes are properly signed and
+that sender has correct amount of SNT.
+When Vote is verified
+the amount of SNT voted on specific topic by specific sender is saved on chain.
 
 ### Double voting
 
-Smart contract should also keep a list of all signatures so that no one can send the same vote twice.
+Smart contract should also keep a list of all signatures so
+that no one can send the same vote twice.
 Another possibility is to allow each sender to only vote once.
 
 ### Initializing Vote
 
-When someone wants to initialize vote he has to send a transaction to smart contract that will create a new voting session.
-When initializing a user has to specify type of vote (Addition, Deletion), amount of his initial SNT to submit and public key of community under vote.
+When someone wants to initialize vote
+he has to send a transaction to smart contract that will create a new voting session.
+When initializing a user has to specify type of vote (Addition, Deletion),
+amount of his initial SNT to submit and public key of community under vote.
 Smart contract will return a ID which is identifier of voting session.
-Also there will be function on Smart Contract that when given community public key it will return voting session ID or undefined if community isn't under vote.
+Also there will be function on Smart Contract that
+when given community public key it will return voting session ID or
+undefined if community isn't under vote.
 
 ## Voting
 
 ### Sending votes
 
-Sending votes is simple every peer is able to send a message to Waku topic specific to given application: 
-```
+Sending votes is simple every peer is able to send a message to Waku topic
+specific to given application:
+
+```json
+
 /status-community-directory-curation-vote/1/{voting-session-id}/json
+
 ```
 
-vote object that is sent over waku should contain information about: 
+vote object that is sent over waku should contain information about:
 
 ```ts
 type Vote = {
     sender: string // address of the sender
     vote: string // vote sent eg. 'yes' 'no'
     sntAmount: BigNumber //number of snt cast on vote
     sign: string // cryptographic signature of a transaction (signed fields: sender,vote,sntAmount,nonce,sessionID)
-    nonce: number // number of votes cast from this address on current vote (only if we allow multiple votes from the same sender)
+    nonce: number // number of votes cast from this address on current vote 
+    // (only if we allow multiple votes from the same sender)
     sessionID: number // ID of voting session
 }
 ```
 
 ### Aggregating votes
 
-Every peer that is opening specific voting session will listen to votes sent over p2p network, and aggregate them for a single transaction to chain.
+Every peer that is opening specific voting session
+will listen to votes sent over p2p network, and
+aggregate them for a single transaction to chain.
 
 ### Submitting to chain
 
-Every peer that has aggregated at least one vote will be able to send them to smart contract.
-When someone votes he will aggregate his own vote and will be able to immediately send it.
+Every peer that has aggregated at least one vote
+will be able to send them to smart contract.
+When someone votes he will aggregate his own vote and
+will be able to immediately send it.
 
 Peer doesn't need to vote to be able to submit the votes to the chain.
 
-Smart contract needs to verify that all votes are valid (eg. all senders had enough SNT, all votes are correctly signed) and that votes aren't duplicated on smart contract.
+Smart contract needs to verify that all votes are valid
+(eg. all senders had enough SNT, all votes are correctly signed) and
+that votes aren't duplicated on smart contract.
 
-### Finalizing 
+### Finalizing
 
 Once the vote deadline has expired, the smart contract will not accept votes anymore.
-Also directory will be updated according to vote results (community added to directory, removed etc.)
+Also directory will be updated according to vote results
+(community added to directory, removed etc.)
 
 ## Copyright
 

status/28/featuring.md

@@ -9,26 +9,32 @@ editor: Szymon Szlachtowicz <[email protected]>
 ---
 
 ## Abstract
+
 This specification describes a voting method to feature different active Status Communities.
 
 ## Overview
 
-When there is a active community that is seeking new members, current users of community should be able to feature their community so that it will be accessible to larger audience.
+When there is a active community that is seeking new members,
+current users of community should be able to feature their community so
+that it will be accessible to larger audience.
 Status community curation DApp should provide such a tool.
 
 Rules of featuring:
     - Given community can't be featured twice in a row.
     - Only one vote per user per community (single user can vote on multiple communities)
     - Voting will be done off-chain
-    - If community hasn't been featured votes for given community are still valid for the next 4 weeks
+    - If community hasn't been featured
+    votes for given community are still valid for the next 4 weeks
 
-Since voting for featuring is similar to polling solutions proposed in this spec could be also used for different applications.
+Since voting for featuring is similar to polling solutions proposed
+in this spec could be also used for different applications.
 
 ### Voting
 
-Voting for featuring will be done through waku v2. 
+Voting for featuring will be done through waku v2.
 
 Payload of waku message will be :
+
 ```ts
 type FeatureVote = {
     voter: string // address of a voter
@@ -44,12 +50,16 @@ timestamp is necessary so that votes can't be reused after 4 week period
 ### Counting Votes
 
 Votes will be counted by the DApp itself.
-DApp will aggregate all the votes in the last 4 weeks and calculate which communities should be displayed in the Featured tab of DApp.
+DApp will aggregate all the votes in the last 4 weeks and
+calculate which communities should be displayed in the Featured tab of DApp.
 
 Rules of counting:
-    - When multiple votes from the same address on the same community are encountered only the vote with highest timestamp is considered valid.
-    - If a community has been featured in a previous week it can't be featured in current week.
-    - In a current week top 5 (or 10) communities with highest amount of SNT votes up to previous Sunday 23:59:59 UTC are considered featured.
+    - When multiple votes from the same address on the same community are encountered
+    only the vote with highest timestamp is considered valid.
+    - If a community has been featured in a previous week
+    it can't be featured in current week.
+    - In a current week top 5 (or 10) communities with highest amount of SNT votes
+    up to previous Sunday 23:59:59 UTC are considered featured.
 
 ## Copyright