Merge branch 'main' into waku-peer-exchange

.github/workflows/.gitignore

@@ -0,0 +1 @@
+.DS_Store

.github/workflows/.markdownlint.json

@@ -0,0 +1,9 @@
+{
+        "MD013": {
+                "tables": false,
+                "code_blocks" : false,
+                "line_length" : false
+        }
+
+        "MD024": false
+}

.github/workflows/markdown-lint.yml

@@ -0,0 +1,23 @@
+name: markdown-linting
+
+on:
+
+  push:
+    branches: 
+      - '**'
+  pull_request:
+    branches: 
+      - '**'
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v2
+
+      - name: Markdown Linter
+        uses: DavidAnson/markdownlint-cli2-action@v15
+        with:
+          config: .github/workflows/.markdownlint.json
+          globs: '**/*.md'

README.md

@@ -2,22 +2,46 @@
 
 *NOTE*: This repo is WIP. We are currently restructuring the RFC process.
 
-## 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 apart of the [IFT portfolio](https://free.technology/).
-[Vac](https://vac.dev) is an [IFT service](https://free.technology/services) that will manage the RFC process within this repository.
-The goal of the RFC, [Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments),
-process is to standardize techincal specification. 
-Specifications will adhere to [1/COSS](./vac/1/coss.md) by obtianing rough consensus within each project.
-
-**See [rfc.vac.dev](https://rfc.vac.dev) for an easy to browse index of all RFCs.**
+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.
+
+## New RFC Process
+
+This repository replaces the previous `rfc.vac.dev` resource.
+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,
+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.
+
+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
+reach a rough consensus for techcinal specifications.
 
 ## Contributing
 
-Please see [1/COSS](https://rfc.vac.dev/spec/1/) for general guidelines and specification lifecycle.
+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). 
-There's a channel specifically for RFC discussions.
+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](none)
+- [Nomos Raw Specifications](https://github.com/logos-co/nomos-specs)

codex/README.md

@@ -1 +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.

nomos/README.md

@@ -1 +1,6 @@
 # Nomos RFCs
+
+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