footnotes/cleanup (#108)

* cleans up footnotes

* Update mvds.md

* Update waku.md
This commit is contained in:
Dean Eigenmann 2020-02-24 04:32:49 -05:00 committed by GitHub
parent a6a9d6bcb1
commit 98942ed342
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 40 additions and 40 deletions

View File

@ -14,10 +14,10 @@ authors: Oskar Thorén <oskar@status.im>, Dean Eigenmann <dean@status.im>
4. [Usage](#usage)
1. [`parents`](#parents)
2. [`ephemeral`](#ephemeral)
5. [Footnotes](#footnotes)
6. [Changelog](#changelog)
7. [Acknowledgements](#acknowledgements)
8. [Copyright](#copyright)
5. [Changelog](#changelog)
6. [Acknowledgements](#acknowledgements)
7. [Copyright](#copyright)
8. [Footnotes](#footnotes)
## Abstract
@ -62,9 +62,9 @@ message Message {
### `parents`
This field contains a list of parent [`message identifier`s](mvds.md#payloads) for the specific message. It MUST NOT contain any messages as parent whose `ack` flag was set to `false`. This establishes a directed acyclic graph (DAG)<sup>1</sup> of persistent messages.
This field contains a list of parent [`message identifier`s](mvds.md#payloads) for the specific message. It MUST NOT contain any messages as parent whose `ack` flag was set to `false`. This establishes a directed acyclic graph (DAG)[^1] of persistent messages.
Nodes MAY buffer messages until dependencies are satisfied for causal consistency<sup>2</sup>, they MAY also pass the messages straight away for eventual consistency<sup>3</sup>.
Nodes MAY buffer messages until dependencies are satisfied for causal consistency[^2], they MAY also pass the messages straight away for eventual consistency[^3].
A parent is any message before a new message that a node is aware of that has no children.
@ -80,11 +80,6 @@ Nodes MAY decide to not persist ephemeral messages, however they MUST NOT be sha
Nodes SHOULD send ephemeral messages in batch mode. As their delivery is not needed to be guaranteed.
## Footnotes
1. <https://en.wikipedia.org/wiki/Directed_acyclic_graph>
2. <https://jepsen.io/consistency/models/causal>
3. <https://en.wikipedia.org/wiki/Eventual_consistency>
## Changelog
| Version | Comment |
@ -97,3 +92,9 @@ Nodes SHOULD send ephemeral messages in batch mode. As their delivery is not nee
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
## Footnotes
[^1]: <https://en.wikipedia.org/wiki/Directed_acyclic_graph>
[^2]: Jepsen. [Causal Consistency](https://jepsen.io/consistency/models/causal). Jepsen, LLC.
[^3]: <https://en.wikipedia.org/wiki/Eventual_consistency>

View File

@ -16,17 +16,17 @@ authors: Oskar Thorén <oskar@status.im>, Dean Eigenmann <dean@status.im>
1. [State](#state)
2. [Flow](#flow)
3. [Retransmission](#retransmission)
5. [Formal Specification](#formal-Specification)
6. [Footnotes](#footnotes)
7. [Changelog](#changelog)
8. [Acknowledgements](#acknowledgements)
9. [Copyright](#copyright)
5. [Formal Specification](#formal-specification)
6. [Changelog](#changelog)
7. [Acknowledgements](#acknowledgements)
8. [Copyright](#copyright)
9. [Footnotes](#footnotes)
## Abstract
In this specification, we describe a minimum viable protocol for data synchronization inspired by the Bramble Synchronization Protocol<sup>1</sup>. This protocol is designed to ensure reliable messaging between peers across an unreliable peer-to-peer (P2P) network where they may be unreachable or unresponsive.
In this specification, we describe a minimum viable protocol for data synchronization inspired by the Bramble Synchronization Protocol[^1]. This protocol is designed to ensure reliable messaging between peers across an unreliable peer-to-peer (P2P) network where they may be unreachable or unresponsive.
We present a reference implementation<sup>2</sup> including a simulation to demonstrate its performance.
We present a reference implementation[^2] including a simulation to demonstrate its performance.
## Definitions
@ -149,11 +149,6 @@ The record of the type `Type` SHOULD be retransmitted every time `Send Epoch` is
MVDS has been formally specified using TLA+: <https://github.com/vacp2p/formalities/tree/master/MVDS>.
## Footnotes
1. <https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md>
2. <https://github.com/vacp2p/mvds>
## Changelog
| Version | Comment |
@ -172,3 +167,8 @@ MVDS has been formally specified using TLA+: <https://github.com/vacp2p/formalit
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
## Footnotes
[^1]: akwizgran et al. [BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md). Briar.
[^2]: <https://github.com/vacp2p/mvds>

View File

@ -18,16 +18,16 @@ authors: Oskar Thorén oskar@status.im, Dean Eigenmann dean@status.im
3. [Remote log](#remote-log)
4. [Next page semantics](#next-page-semantics)
5. [Interaction with MVDS](#interaction-with-mvds)
5. [Footnotes](#footnotes)
6. [Changelog](#changelog)
7. [Acknowledgements](#acknowledgements)
8. [Copyright](#copyright)
5. [Changelog](#changelog)
6. [Acknowledgements](#acknowledgements)
7. [Copyright](#copyright)
8. [Footnotes](#footnotes)
## Abstract
A remote log is a replication of a local log. This means a node can read data from a node that is offline.
This specification is complemented by a proof of concept implementation <sup>1</sup>.
This specification is complemented by a proof of concept implementation[^1].
## Definitions
@ -223,10 +223,6 @@ in time.
[vac.mvds.Message](mvds.md#payloads) payloads are the only payloads that MUST be uploaded. Other messages types MAY be uploaded, depending on the implementation.
## Footnotes
1. <https://github.com/vacp2p/research/tree/master/remote_log>
## Changelog
| Version | Comment |
@ -234,8 +230,6 @@ 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
TBD.
@ -243,3 +237,7 @@ TBD.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
## Footnotes
[^1]: <https://github.com/vacp2p/research/tree/master/remote_log>

View File

@ -35,7 +35,6 @@ authors: Adam Babik <adam@status.im>, Andrea Maria Piana <andreap@status.im>, De
- [Implementation Matrix](#implementation-matrix)
- [Recommendations for clients](#recommendations-for-clients)
- [Node discovery](#node-discovery)
- [Footnotes](#footnotes)
- [Changelog](#changelog)
- [Version 0.4](#version-04)
- [Version 0.3](#version-03)
@ -44,6 +43,7 @@ authors: Adam Babik <adam@status.im>, Andrea Maria Piana <andreap@status.im>, De
- [Differences between shh/6 waku/0](#differences-between-shh6-waku0)
- [Acknowledgements](#acknowledgements)
- [Copyright](#copyright)
- [Footnotes](#footnotes)
## Abstract
@ -75,7 +75,7 @@ In Whisper, messages are gossiped between peers. Whisper is a form of rumor-mong
### Use of RLPx transport protocol
All Waku messages are sent as devp2p RLPx transport protocol, version 5<sup>[1](https://github.com/ethereum/devp2p/blob/master/rlpx.md)</sup> 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.
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).
@ -510,10 +510,6 @@ Resource restricted devices SHOULD use [EIP-1459](https://eips.ethereum.org/EIPS
Known static nodes MAY also be used.
## Footnotes
1. <https://github.com/ethereum/devp2p/blob/master/rlpx.md>
## Changelog
### Version 0.4
@ -574,3 +570,8 @@ confirmations-enabled and rate-limits
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
## Footnotes
[^1]: Felix Lange et al. [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md). Ethereum.