mirror of https://github.com/vacp2p/rfc.git
moved specs
This commit is contained in:
decanus
parent
67922a0549
commit
5cbb34cab0
12
README.md
12
README.md
|
|
@ -12,17 +12,17 @@ The entire vac protocol is under active development, each specification has its
|
|||
|
||||
These protocols define various components of the [vac](https://vac.dev) stack.
|
||||
|
||||
- [mvds](./mvds.md) - Data Synchronization protocol for unreliable transports.
|
||||
- [remote log](./remote-log.md) - Remote replication of local logs.
|
||||
- [mvds metadata](./mvds-metadata.md) - Metadata field for [MVDS](./mvds.md) messages.
|
||||
- [mvds](specs/mvds.md) - Data Synchronization protocol for unreliable transports.
|
||||
- [remote log](specs/remote-log.md) - Remote replication of local logs.
|
||||
- [mvds metadata](specs/mvds-metadata.md) - Metadata field for [MVDS](specs/mvds.md) messages.
|
||||
|
||||
### Waku
|
||||
|
||||
Waku is a protocol that substitutes [EIP-627](https://eips.ethereum.org/EIPS/eip-627).
|
||||
|
||||
- [waku](./waku/waku.md) - ÐΞVp2p wire protocol, substituting [EIP-627](https://eips.ethereum.org/EIPS/eip-627).
|
||||
- [envelope data format](./waku/envelope-data-format.md) - [waku](./waku/waku.md) envelope data field specification.
|
||||
- [mailserver](./waku/mailserver.md) - Mailserver specification for archiving and delivering historical [waku](./waku/waku.md) envelopes on demand.
|
||||
- [waku](specs/waku/waku.md) - ÐΞVp2p wire protocol, substituting [EIP-627](https://eips.ethereum.org/EIPS/eip-627).
|
||||
- [envelope data format](specs/waku/envelope-data-format.md) - [waku](specs/waku/waku.md) envelope data field specification.
|
||||
- [mailserver](specs/waku/mailserver.md) - Mailserver specification for archiving and delivering historical [waku](specs/waku/waku.md) envelopes on demand.
|
||||
|
||||
## Style guide
|
||||
|
||||
|
|
|
|||
12
_config.yml
12
_config.yml
|
|
@ -1,4 +1,14 @@
|
|||
title: "Vac Protocol"
|
||||
|
||||
markdown: kramdown
|
||||
theme: minima
|
||||
theme: minima
|
||||
|
||||
defaults:
|
||||
-
|
||||
scope:
|
||||
path: "specs"
|
||||
values:
|
||||
layout: ""
|
||||
|
||||
header_pages:
|
||||
- waku.md
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
## Abstract
|
||||
|
||||
In this specification, we describe a method to construct message history that will aid the consistency guarantees of [MVDS](./mvds.md). Additionally we explain how data sync can be used for more lightweight messages that do not require full synchronization.
|
||||
In this specification, we describe a method to construct message history that will aid the consistency guarantees of [MVDS](mvds.md). Additionally we explain how data sync can be used for more lightweight messages that do not require full synchronization.
|
||||
|
||||
## Motivation
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ message Metadata {
|
|||
}
|
||||
```
|
||||
|
||||
Nodes MAY transmit a `Metadata` message by extending the MVDS [message](./mvds.md#payloads) with a `metadata` field.
|
||||
Nodes MAY transmit a `Metadata` message by extending the MVDS [message](mvds.md#payloads) with a `metadata` field.
|
||||
|
||||
```diff
|
||||
message Message {
|
||||
|
|
@ -54,14 +54,14 @@ message Message {
|
|||
|
||||
| Name | Description |
|
||||
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `parents` | list of parent [`message identifier`s](./mvds.md#payloads) for the specific message. |
|
||||
| `parents` | list of parent [`message identifier`s](mvds.md#payloads) for the specific message. |
|
||||
| `ephemeral` | indicates whether a message is ephemeral or not. |
|
||||
|
||||
## Usage
|
||||
|
||||
### `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)<sup>1</sup> 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>.
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
|
|||
- All records that require retransmission are added to the payload, given `Send Epoch` has been reached.
|
||||
|
||||
<p align="center">
|
||||
<img src="./assets/mvds/interactive.png" />
|
||||
<img src="../assets/mvds/interactive.png" />
|
||||
<br />
|
||||
Figure 1: Delivery without retransmissions in interactive mode.
|
||||
</p>
|
||||
|
|
@ -126,7 +126,7 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT
|
|||
<!-- diagram -->
|
||||
|
||||
<p align="center">
|
||||
<img src="./assets/mvds/batch.png" />
|
||||
<img src="../assets/mvds/batch.png" />
|
||||
<br />
|
||||
Figure 2: Delivery without retransmissions in batch mode.
|
||||
</p>
|
||||
|
|
@ -153,7 +153,7 @@ The *remote log* protobuf is what is stored in the name system.
|
|||
<!-- diagram -->
|
||||
|
||||
<p align="center">
|
||||
<img src="./assets/remotelog/remote-log.png" />
|
||||
<img src="../assets/remotelog/remote-log.png" />
|
||||
<br />
|
||||
Figure 1: Remote log data synchronization.
|
||||
</p>
|
||||
|
|
@ -220,7 +220,7 @@ in time.
|
|||
|
||||
### Interaction with MVDS
|
||||
|
||||
[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.
|
||||
[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
|
||||
|
||||
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
## Abstract
|
||||
|
||||
In this specification, we describe the [data field used in Waku](./waku.md#abnf-specification) for the encryption, decryption and signing of messages.
|
||||
In this specification, we describe the [data field used in Waku](waku.md#abnf-specification) for the encryption, decryption and signing of messages.
|
||||
|
||||
## Specification
|
||||
|
||||
|
|
@ -68,7 +68,7 @@ For nodes to communicate, they MUST implement devp2p and run RLPx. They MUST hav
|
|||
|
||||
### Gossip based routing
|
||||
|
||||
In Whisper, messages are gossiped between peers. Whisper is a form of rumor-mongering protocol that works by flooding to its connected peers based on some factors. Messages are elgible for retransmission until their TTL expires. A node SHOULD relay messages to all connected nodes if an envelope matches their PoW and bloom filter settings. If a node works in light mode, it MAY choose not to forward envelopes. A node MUST NOT send expired envelopes, unless the envelopes are sent as a [mailserver](./mailserver.md) response. A node SHOULD NOT send a message to a peer that it has already sent before.
|
||||
In Whisper, messages are gossiped between peers. Whisper is a form of rumor-mongering protocol that works by flooding to its connected peers based on some factors. Messages are elgible for retransmission until their TTL expires. A node SHOULD relay messages to all connected nodes if an envelope matches their PoW and bloom filter settings. If a node works in light mode, it MAY choose not to forward envelopes. A node MUST NOT send expired envelopes, unless the envelopes are sent as a [mailserver](mailserver.md) response. A node SHOULD NOT send a message to a peer that it has already sent before.
|
||||
|
||||
## Wire Specification
|
||||
|
||||
|
|
@ -346,7 +346,7 @@ Packet codes `0x7E` and `0x7F` may be used to implement Waku Mail Server and Cli
|
|||
|
||||
Waku supports multiple capabilities. These include light node, rate limiting and bridging of traffic. Here we list these capabilities, how they are identified, what properties they have and what invariants they must maintain.
|
||||
|
||||
Additionally there is the capability of a mailserver which is documented in its on [specification](./mailserver.md).
|
||||
Additionally there is the capability of a mailserver which is documented in its on [specification](mailserver.md).
|
||||
|
||||
### Light node
|
||||
|
||||
Loading…
Reference in New Issue