mirror of https://github.com/vacp2p/rfc.git
github-actions-readme-spelling (#127)
* Create main.yml * Delete .travis.yml * Update README.md * Update main.yml * Create wordlist.txt * Update README.md * Create spellcheck.yaml * Update wordlist.txt * Update wordlist.txt * Update spellcheck.yaml * Update wordlist.txt * Update mvds-metadata.md * Update wordlist.txt * spelling * more * fixes * filter comments * spelling corrections, wordlist * more fixes * formt * undid * filter * remove * url * i think thats it * fix * removed to test * sorted * Update spellcheck.yaml * Update main.yml * trying * Update wordlist.txt * Update wordlist.txt * Update wordlist.txt * Update README.md * Update wordlist.txt
This commit is contained in:
Dean Eigenmann
GitHub
parent
0ead06e40f
commit
3b73cb85aa
|
|
@ -0,0 +1,31 @@
|
|||
# This is a basic workflow to help you get started with Actions
|
||||
|
||||
name: CI
|
||||
|
||||
# Controls when the action will run. Triggers the workflow on push or pull request
|
||||
# events but only for the master branch
|
||||
on: [pull_request]
|
||||
|
||||
jobs:
|
||||
spellcheck:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
||||
- name: Spellcheck Action
|
||||
uses: rojopolis/spellcheck-github-actions@0.2.0
|
||||
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
||||
- name: Set up Node.js
|
||||
uses: actions/setup-node@master
|
||||
with:
|
||||
node-version: 13
|
||||
- name: Install
|
||||
run: npm install
|
||||
- name: Test
|
||||
run: npm run lint
|
||||
15
.travis.yml
15
.travis.yml
|
|
@ -1,15 +0,0 @@
|
|||
sudo: required
|
||||
|
||||
dist: trusty
|
||||
|
||||
language: node_js
|
||||
|
||||
node_js:
|
||||
- "8"
|
||||
|
||||
script:
|
||||
- npm run lint
|
||||
|
||||
notifications:
|
||||
email: false
|
||||
|
||||
14
README.md
14
README.md
|
|
@ -1,4 +1,4 @@
|
|||
[](https://travis-ci.com/vacp2p/specs)
|
||||
|
||||
|
||||
This repository contains the specs for [vac](https://vac.dev), a modular peer-to-peer messaging stack, with a focus on secure messaging. A detailed explanation of the vac and its design goals can be found [here](https://vac.dev/vac-overview).
|
||||
|
||||
|
|
@ -30,3 +30,15 @@ The lifecycle of the specs follows the [COSS Lifecycle](https://rfc.unprotocols.
|
|||
## Meta
|
||||
|
||||
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
|
||||
|
||||
## Spellcheck
|
||||
|
||||
To run the spellchecker locally, you must install [pyspelling](https://facelessuser.github.io/pyspelling/).
|
||||
|
||||
It can then be run with the following command:
|
||||
|
||||
```console
|
||||
pyspelling -c spellcheck.yml
|
||||
```
|
||||
|
||||
Words that should be ignored or are unrecognized must be added to the [wordlist](./wordlist.txt).
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ redirect_from:
|
|||
1. [`parents`](#parents)
|
||||
2. [`ephemeral`](#ephemeral)
|
||||
5. [Changelog](#changelog)
|
||||
6. [Acknowledgements](#acknowledgements)
|
||||
6. [Acknowledgments](#acknowledgments)
|
||||
7. [Copyright](#copyright)
|
||||
8. [Footnotes](#footnotes)
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ If a message has no parents it is considered a root. There can be multiple roots
|
|||
|
||||
### `ephemeral`
|
||||
|
||||
When the `ephemeral` flag is set to `false`, a node MUST send an acknowledgement when they have received and processed a message. If it is set to `true`, it SHOULD NOT send any acknowledgement. The flag is `false` by default.
|
||||
When the `ephemeral` flag is set to `false`, a node MUST send an acknowledgment when they have received and processed a message. If it is set to `true`, it SHOULD NOT send any acknowledgment. The flag is `false` by default.
|
||||
|
||||
Nodes MAY decide to not persist ephemeral messages, however they MUST NOT be shared as part of the message history.
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ Nodes SHOULD send ephemeral messages in batch mode. As their delivery is not nee
|
|||
| :-----: | ------- |
|
||||
| [0.1.0](https://github.com/vacp2p/specs/blob/53bc8585add58695c28cfaf4382818f4daf8de84/mdf.md) | Initial Release |
|
||||
|
||||
## Acknowledgements
|
||||
## Acknowledgments
|
||||
- Andrea Maria Piana
|
||||
|
||||
## Copyright
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ redirect_from:
|
|||
3. [Retransmission](#retransmission)
|
||||
5. [Formal Specification](#formal-specification)
|
||||
6. [Changelog](#changelog)
|
||||
7. [Acknowledgements](#acknowledgements)
|
||||
7. [Acknowledgments](#acknowledgments)
|
||||
8. [Copyright](#copyright)
|
||||
9. [Footnotes](#footnotes)
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
|
|||
</p>
|
||||
|
||||
|
||||
> ***NOTE:** Batch mode is higher bandwidth whereas interactive mode is higer latency.*
|
||||
> ***NOTE:** Batch mode is higher bandwidth whereas interactive mode is higher latency.*
|
||||
|
||||
<!-- Interactions with state, flow chart with retransmissions? -->
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ MVDS has been formally specified using TLA+: <https://github.com/vacp2p/formalit
|
|||
| [0.5.1](https://github.com/status-im/bigbrother-specs/blob/20e2659447dcb5123a105526eb26816307c3780c/data_sync/mvds.md) | Documentation updates: clarifications on spec, RFC-2119 and message identifiers. |
|
||||
| [0.5.0](https://github.com/status-im/bigbrother-specs/blob/6d3d0771b46941791eabe9263f80cbaeaf3d1148/data_sync/mvds.md) | Initial Release |
|
||||
|
||||
## Acknowledgements
|
||||
## Acknowledgments
|
||||
- Preston van Loon
|
||||
- Greg Markou
|
||||
- Rene Nayman
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ redirect_from:
|
|||
4. [Next page semantics](#next-page-semantics)
|
||||
5. [Interaction with MVDS](#interaction-with-mvds)
|
||||
5. [Changelog](#changelog)
|
||||
6. [Acknowledgements](#acknowledgements)
|
||||
6. [Acknowledgments](#acknowledgments)
|
||||
7. [Copyright](#copyright)
|
||||
8. [Footnotes](#footnotes)
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ in time.
|
|||
| 0.1.1 (current) | Add protobuf package name, protobuf3 and fix typos. |
|
||||
| [0.1.0](https://github.com/vacp2p/specs/blob/ccb9ae7f44e32ff9778bdbe0ed02a56e0ff29996/remote-log.md) | Initial Release |
|
||||
|
||||
## Acknowledgements
|
||||
## Acknowledgments
|
||||
|
||||
TBD.
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ envelope = flags auxiliary-field payload padding [signature] [salt]
|
|||
|
||||
### Signature
|
||||
|
||||
Those unable to decrypt the envelope data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialised as the concatenation of the `R`, `S` and `V` parameters of the SECP-256k1 ECDSA signature, in that order. `R` and `S` MUST be big-endian encoded, fixed-width 256-bit unsigned. `V` MUST be an 8-bit big-endian encoded, non-normalised and should be either 27 or 28.
|
||||
Those unable to decrypt the envelope data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialized as the concatenation of the `R`, `S` and `V` parameters of the SECP-256k1 ECDSA signature, in that order. `R` and `S` MUST be big-endian encoded, fixed-width 256-bit unsigned. `V` MUST be an 8-bit big-endian encoded, non-normalized and should be either 27 or 28.
|
||||
|
||||
### Padding
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ redirect_from:
|
|||
- [Version 0.2](#version-02)
|
||||
- [Version 0.1](#version-01)
|
||||
- [Differences between shh/6 waku/0](#differences-between-shh6-waku0)
|
||||
- [Acknowledgements](#acknowledgements)
|
||||
- [Acknowledgments](#acknowledgments)
|
||||
- [Copyright](#copyright)
|
||||
- [Footnotes](#footnotes)
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ In Whisper, messages are gossiped between peers. Whisper is a form of rumor-mong
|
|||
|
||||
All Waku messages are sent as devp2p RLPx transport protocol, version 5[^1] packets. These packets MUST be RLP-encoded arrays of data containing two objects: packet code followed by another object (whose type depends on the packet code). See [informal RLP spec](https://github.com/ethereum/wiki/wiki/RLP) and the [Ethereum Yellow Paper, appendix B](https://ethereum.github.io/yellowpaper/paper.pdf) for more details on RLP.
|
||||
|
||||
Waku is a RLPx subprotocol called `waku` with version `0`. The version number corresponds to the major version in the header spec. Minor versions should not break compatiblity of `waku`, this would result in a new major. (Some expections to this apply in the Draft stage of where client implementation is rapidly change).
|
||||
Waku is a RLPx subprotocol called `waku` with version `0`. The version number corresponds to the major version in the header spec. Minor versions should not break compatibility of `waku`, this would result in a new major. (Some exceptions to this apply in the Draft stage of where client implementation is rapidly change).
|
||||
|
||||
### ABNF specification
|
||||
|
||||
|
|
@ -336,7 +336,7 @@ confirmation = "[" version response "]"
|
|||
The supported codes:
|
||||
`1`: means time sync error which happens when an envelope is too old or created in the future (the root cause is no time sync between nodes).
|
||||
|
||||
The drawback of sending message confirmations is that it increases the noise in the network because for each sent message, a corresponding confirmation is broadcasted by one or more peers.
|
||||
The drawback of sending message confirmations is that it increases the noise in the network because for each sent message, a corresponding confirmation is broadcast by one or more peers.
|
||||
|
||||
|
||||
#### P2P Request
|
||||
|
|
@ -389,7 +389,7 @@ Every epoch (say, every minute or every time an event happens) statistics SHOULD
|
|||
| peer1 | 0 | 123 |
|
||||
| peer2 | 10 | 40 |
|
||||
|
||||
In later versions this will be amended by nodes communication threshholds, settlements and disconnect logic.
|
||||
In later versions this will be amended by nodes communication thresholds, settlements and disconnect logic.
|
||||
|
||||
## Upgradability and Compatibility
|
||||
|
||||
|
|
@ -436,7 +436,7 @@ Waku is a different subprotocol from Whisper so it isn't directly compatible. Ho
|
|||
|
||||
It is desirable to have a strategy for maintaining forward compatibility between `waku/0` and future version of waku. Here we outline some concerns and strategy for this.
|
||||
|
||||
- **Connecting to nodes with multiple versions:** The way this SHOULD be accomplished in the future is by negotiating the versions of subprotocols, within the `hello` message nodes transmit their capabilities along with a version. As suggested in [EIP-8](https://eips.ethereum.org/EIPS/eip-8), if a node connects that has a higher version number for a specific capability, the node with a lower number SHOULD assume backwards compatiblity. The node with the higher version will decide if compatibility can be assured between versions, if this is not the case it MUST disconnect.
|
||||
- **Connecting to nodes with multiple versions:** The way this SHOULD be accomplished in the future is by negotiating the versions of subprotocols, within the `hello` message nodes transmit their capabilities along with a version. As suggested in [EIP-8](https://eips.ethereum.org/EIPS/eip-8), if a node connects that has a higher version number for a specific capability, the node with a lower number SHOULD assume backwards compatibility. The node with the higher version will decide if compatibility can be assured between versions, if this is not the case it MUST disconnect.
|
||||
- **Adding new packet codes:** New packet codes can be added easily due to the available packet codes. Unknown packet codes SHOULD be ignored. Upgrades that add new packet codes SHOULD implement some fallback mechanism if no response was received for nodes that do not yet understand this packet.
|
||||
- **Adding new options in `status-options`:** New options can be added to the `status-options` association list in the `status` and `status-update` packet as options are OPTIONAL and unknown option keys SHOULD be ignored. A node SHOULD NOT disconnect from a peer when receiving `status-options` with unknown option keys.
|
||||
|
||||
|
|
@ -478,7 +478,7 @@ Similar to bloom filter privacy, if you use a very specific topic you reveal mor
|
|||
|
||||
### Spam resistance
|
||||
|
||||
**PoW bad for heterogenerous devices:**
|
||||
**PoW bad for heterogeneous devices:**
|
||||
|
||||
Proof of work is a poor spam prevention mechanism. A mobile device can only have a very low PoW in order not to use too much CPU / burn up its phone battery. This means someone can spin up a powerful node and overwhelm the network.
|
||||
|
||||
|
|
@ -528,7 +528,7 @@ Released [April 21,2020](https://github.com/vacp2p/specs/commit/9e650995f2417984
|
|||
Released [March 17,2020](https://github.com/vacp2p/specs/commit/7b9dc562bc50c6bb844ac575cb221ec9cda2530a)
|
||||
|
||||
- Clarify the preferred way of handling unknown keys in the `status-options` association list.
|
||||
- Correct spec/implementation mismatch: Change RLP keys to be the their int values in order to reflect production behaviour
|
||||
- Correct spec/implementation mismatch: Change RLP keys to be the their int values in order to reflect production behavior
|
||||
|
||||
### Version 0.4
|
||||
|
||||
|
|
@ -561,7 +561,7 @@ Released [December 10, 2019](https://github.com/vacp2p/specs/blob/waku-0.2.0/wak
|
|||
- New packet codes: topic-interest (experimental), rate limits (experimental).
|
||||
- More details on handshake modifications.
|
||||
- Accounting for resources mode (experimental)
|
||||
- Appendix with security considerations: scalablity and UX, privacy, and spam resistance.
|
||||
- Appendix with security considerations: scalability and UX, privacy, and spam resistance.
|
||||
- Appendix with implementation notes and implementation matrix across various clients with breakdown per capability.
|
||||
- More details on handshake and parameters.
|
||||
- Describe rate limits in more detail.
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ redirect_from:
|
|||
- [Version 0.2](#version-02)
|
||||
- [Version 0.1](#version-01)
|
||||
- [Differences between shh/6 waku/1](#differences-between-shh6-waku1)
|
||||
- [Acknowledgements](#acknowledgements)
|
||||
- [Acknowledgments](#acknowledgments)
|
||||
- [Copyright](#copyright)
|
||||
- [Footnotes](#footnotes)
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ confirmation = "[" version response "]"
|
|||
The supported codes:
|
||||
`1`: means time sync error which happens when an envelope is too old or created in the future (the root cause is no time sync between nodes).
|
||||
|
||||
The drawback of sending message confirmations is that it increases the noise in the network because for each sent envelope, a corresponding confirmation is broadcasted by one or more peers.
|
||||
The drawback of sending message confirmations is that it increases the noise in the network because for each sent envelope, a corresponding confirmation is broadcast by one or more peers.
|
||||
|
||||
|
||||
#### P2P Request
|
||||
|
|
@ -399,7 +399,7 @@ Every epoch (say, every minute or every time an event happens) statistics SHOULD
|
|||
| peer1 | 0 | 123 |
|
||||
| peer2 | 10 | 40 |
|
||||
|
||||
In later versions this will be amended by nodes communication threshholds, settlements and disconnect logic.
|
||||
In later versions this will be amended by nodes communication thresholds, settlements and disconnect logic.
|
||||
|
||||
## Upgradability and Compatibility
|
||||
|
||||
|
|
@ -492,7 +492,7 @@ Similar to bloom filter privacy, if you use a very specific topic you reveal mor
|
|||
|
||||
### Spam resistance
|
||||
|
||||
**PoW bad for heterogenerous devices:**
|
||||
**PoW bad for heterogeneous devices:**
|
||||
|
||||
Proof of work is a poor spam prevention mechanism. A mobile device can only have a very low PoW in order not to use too much CPU / burn up its phone battery. This means someone can spin up a powerful node and overwhelm the network.
|
||||
|
||||
|
|
@ -556,7 +556,7 @@ Released [April 21,2020](https://github.com/vacp2p/specs/commit/9e650995f2417984
|
|||
Released [March 17,2020](https://github.com/vacp2p/specs/commit/7b9dc562bc50c6bb844ac575cb221ec9cda2530a)
|
||||
|
||||
- Clarify the preferred way of handling unknown keys in the `status-options` association list.
|
||||
- Correct spec/implementation mismatch: Change RLP keys to be the their int values in order to reflect production behaviour
|
||||
- Correct spec/implementation mismatch: Change RLP keys to be the their int values in order to reflect production behavior
|
||||
|
||||
### Version 0.4
|
||||
|
||||
|
|
@ -589,7 +589,7 @@ Released [December 10, 2019](https://github.com/vacp2p/specs/blob/waku-0.2.0/wak
|
|||
- New packet codes: topic-interest (experimental), rate limits (experimental).
|
||||
- More details on handshake modifications.
|
||||
- Accounting for resources mode (experimental)
|
||||
- Appendix with security considerations: scalablity and UX, privacy, and spam resistance.
|
||||
- Appendix with security considerations: scalability and UX, privacy, and spam resistance.
|
||||
- Appendix with implementation notes and implementation matrix across various clients with breakdown per capability.
|
||||
- More details on handshake and parameters.
|
||||
- Describe rate limits in more detail.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
matrix:
|
||||
- name: Markdown
|
||||
apsell:
|
||||
mode: en
|
||||
ignore-case: true
|
||||
dictionary:
|
||||
wordlists:
|
||||
- wordlist.txt
|
||||
output: wordlist.dic
|
||||
encoding: utf-8
|
||||
pipeline:
|
||||
- pyspelling.filters.url:
|
||||
- pyspelling.filters.markdown:
|
||||
- pyspelling.filters.html:
|
||||
comments: false
|
||||
ignores:
|
||||
- code
|
||||
- pre
|
||||
sources:
|
||||
- '**/*.md'
|
||||
|
|
@ -0,0 +1,134 @@
|
|||
abnf
|
||||
accreting
|
||||
ack
|
||||
acks
|
||||
acyclic
|
||||
adam
|
||||
AES
|
||||
akwizgran
|
||||
al
|
||||
Babik
|
||||
BestBit
|
||||
bitwise
|
||||
blockable
|
||||
bool
|
||||
Briar
|
||||
BSP
|
||||
cas
|
||||
Changelog
|
||||
COSS
|
||||
DAG
|
||||
DAGs
|
||||
Dapp
|
||||
DDoS
|
||||
De
|
||||
decrypt
|
||||
dereference
|
||||
deserialized
|
||||
devp
|
||||
DevP
|
||||
devp2p
|
||||
DNS
|
||||
ECDSA
|
||||
Eigenmann
|
||||
EIP
|
||||
endian
|
||||
enum
|
||||
et
|
||||
Ethereum
|
||||
extensibility
|
||||
GCM
|
||||
github
|
||||
growable
|
||||
hasherror
|
||||
html
|
||||
http
|
||||
https
|
||||
im
|
||||
invariants
|
||||
ip
|
||||
IPs
|
||||
Jacek
|
||||
Jepsen
|
||||
Kademlia
|
||||
Keccak
|
||||
keccak
|
||||
kimdemey
|
||||
Lange
|
||||
libp
|
||||
libp2p
|
||||
lifecycle
|
||||
LLC
|
||||
localHash
|
||||
mailserver
|
||||
mailservers
|
||||
Markou
|
||||
metainformation
|
||||
Mey
|
||||
mixnet
|
||||
mixnets
|
||||
Mscgen
|
||||
multiaddr
|
||||
mvds
|
||||
NameInit
|
||||
NameUpdate
|
||||
Naur
|
||||
Nayman
|
||||
nim
|
||||
noop
|
||||
Ok
|
||||
Oskar
|
||||
peerid
|
||||
peerID
|
||||
Piana
|
||||
Pluggable
|
||||
PoW
|
||||
proto
|
||||
protobuf
|
||||
PSS
|
||||
pyspelling
|
||||
qNAN
|
||||
remoteHash
|
||||
remotelog
|
||||
RemoteLog
|
||||
retransmission
|
||||
retransmissions
|
||||
retransmit
|
||||
retransmitted
|
||||
rlp
|
||||
rlpx
|
||||
RLPx
|
||||
rpc
|
||||
scalability
|
||||
SECP
|
||||
semver
|
||||
seqid
|
||||
Sieka
|
||||
sNAN
|
||||
suboptimal
|
||||
subprotocol
|
||||
subprotocols
|
||||
TBD
|
||||
TCP
|
||||
Thorén
|
||||
tla
|
||||
tls
|
||||
TODO
|
||||
tradeoff
|
||||
trilemma
|
||||
ttl
|
||||
uint
|
||||
underspecified
|
||||
unencrypted
|
||||
upgradability
|
||||
UX
|
||||
vac
|
||||
vacp
|
||||
vacp2p
|
||||
Vp
|
||||
waku
|
||||
WakuWhisper
|
||||
wms
|
||||
wns
|
||||
wordlist
|
||||
ÐΞVp2p
|
||||
Loading…
Reference in New Issue