AtHeartEngineer/specs
1
0
Fork 0
mirror of https://github.com/vacp2p/specs.git synced 2026-01-09 15:28:03 -05:00
Code Issues Packages Projects Releases Wiki Activity

update TOC

Browse Source
This commit is contained in:
protolambda
2020-09-24 19:23:27 +02:00
parent 0ccb3b01ef
commit e80c67cc15
2 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
pubsub/README.md
View File

@@ -32,6 +32,7 @@ and spec status.
- [The RPC](#the-rpc) - [The RPC](#the-rpc)
- [The Message](#the-message) - [The Message](#the-message)
- [Message Signing](#message-signing) - [Message Signing](#message-signing)
- [Message Identification](#message-identification)
- [The Topic Descriptor](#the-topic-descriptor) - [The Topic Descriptor](#the-topic-descriptor)
- [AuthOpts](#authopts) - [AuthOpts](#authopts)
- [AuthMode 'NONE'](#authmode-none) - [AuthMode 'NONE'](#authmode-none)
@@ -145,7 +146,7 @@ economics (see e.g.
and and
[here](https://ethresear.ch/t/improving-the-ux-of-rent-with-a-sleeping-waking-mechanism/1480)). [here](https://ethresear.ch/t/improving-the-ux-of-rent-with-a-sleeping-waking-mechanism/1480)).
## Message identification ## Message Identification
To uniquely identify a message in a set of topics, a `message_id` is computed based on the message. To uniquely identify a message in a set of topics, a `message_id` is computed based on the message.
This can be configured on the application layer, as `message_id_fn(*Message) => message_id`, This can be configured on the application layer, as `message_id_fn(*Message) => message_id`,

7
pubsub/gossipsub/gossipsub-v1.1.md
View File

@@ -37,7 +37,8 @@ See the [lifecycle document][lifecycle-spec] for context about maturity level an
- [Explicit Peering Agreements](#explicit-peering-agreements) - [Explicit Peering Agreements](#explicit-peering-agreements)
- [PRUNE Backoff and Peer Exchange](#prune-backoff-and-peer-exchange) - [PRUNE Backoff and Peer Exchange](#prune-backoff-and-peer-exchange)
- [Protobuf](#protobuf) - [Protobuf](#protobuf)
- [Signature policy](#signature-policy) - [Signature Policy](#signature-policy)
- [Signature Policy Options](#signature-policy-options)
- [Flood Publishing](#flood-publishing) - [Flood Publishing](#flood-publishing)
- [Adaptive Gossip Dissemination](#adaptive-gossip-dissemination) - [Adaptive Gossip Dissemination](#adaptive-gossip-dissemination)
- [Outbound Mesh Quotas](#outbound-mesh-quotas) - [Outbound Mesh Quotas](#outbound-mesh-quotas)
@@ -135,7 +136,7 @@ message PeerInfo {
} }
``` ```
### Signature policy ### Signature Policy
The usage of the `signature`, `key`, `from`, and `seqno` fields in `Message` is now configurable. The usage of the `signature`, `key`, `from`, and `seqno` fields in `Message` is now configurable.
Initially this could be configured globally, however, configuration on a per-topic basis will facilitate mixed protocols better. Initially this could be configured globally, however, configuration on a per-topic basis will facilitate mixed protocols better.
@@ -146,7 +147,7 @@ the `seqno` and `from` fields form the `message_id`, and should be verified to a
In content-stamped messaging, the fields may negatively affect privacy: In content-stamped messaging, the fields may negatively affect privacy:
revealing the relationship between `data` and `from`/`seqno`. revealing the relationship between `data` and `from`/`seqno`.
#### Signature policy options #### Signature Policy Options
In gossipsub v1.1, these fields are strictly present and verified, or completely omitted altogether: In gossipsub v1.1, these fields are strictly present and verified, or completely omitted altogether:
- `StrictSign`: - `StrictSign`: