mirror of
https://github.com/vacp2p/specs.git
synced 2026-01-09 15:28:03 -05:00
Merge branch 'master' into feat/relay
This commit is contained in:
David Dias
@@ -1,43 +1,7 @@
|
||||
3 Requirements and considerations
|
||||
=================================
|
||||
|
||||
## 3.1 NAT traversal
|
||||
|
||||
Network Address Translation is ubiquitous in the Internet. Not only are most consumer devices behind many layers of NAT, but most data center nodes are often behind NAT for security or virtualization reasons. As we move into containerized deployments, this is getting worse. IPFS implementations SHOULD provide a way to traverse NATs, otherwise it is likely that operation will be affected. Even nodes meant to run with real IP addresses must implement NAT traversal techniques, as they may need to establish connections to peers behind NAT.
|
||||
|
||||
`libp2p` accomplishes full NAT traversal using an ICE-like protocol. It is not exactly ICE, as IPFS networks provide the possibility of relaying communications over the IPFS protocol itself, for coordinating hole-punching or even relaying communication.
|
||||
|
||||
It is recommended that implementations use one of the many NAT traversal libraries available, such as `libnice`, `libwebrtc`, or `natty`. However, NAT traversal must be interoperable.
|
||||
|
||||
## 3.2 Relay
|
||||
|
||||
Unfortunately, due to symmetric NATs, container and VM NATs, and other impossible-to-bypass NATs, `libp2p` MUST fallback to relaying communication to establish a full connectivity graph. To be complete, implementations MUST support relay, though it SHOULD be optional and able to be turned off by end users.
|
||||
|
||||
Connection relaying SHOULD be implemented as a transport, in order to be transparent to upper layers.
|
||||
|
||||
For an instantiation of relaying, see the [/ipfs/relay/circuit transport](transports/circuit-relay.md).
|
||||
|
||||
## 3.3 Encryption
|
||||
|
||||
Communications on `libp2p` may be:
|
||||
|
||||
- **encrypted**
|
||||
- **signed** (not encrypted)
|
||||
- **clear** (not encrypted, not signed)
|
||||
|
||||
We take both security and performance seriously. We recognize that encryption is not viable for some in-datacenter high performance use cases.
|
||||
|
||||
We recommend that:
|
||||
|
||||
- implementations encrypt all communications by default
|
||||
- implementations are audited
|
||||
- unless absolutely necessary, users normally operate with encrypted communications only.
|
||||
|
||||
`libp2p` uses cyphersuites like TLS.
|
||||
|
||||
**Note:** We do not use TLS directly, because we do not want the CA system baggage. Most TLS implementations are very big. Since the `libp2p` model begins with keys, `libp2p` only needs to apply ciphers. This is a minimal portion of the whole TLS standard.
|
||||
|
||||
## 3.4 Transport agnostic
|
||||
## 3.1 Transport agnostic
|
||||
|
||||
`libp2p` is transport agnostic, so it can run over any transport protocol. It does not even depend on IP; it may run on top of NDN, XIA, and other new Internet architectures.
|
||||
|
||||
@@ -64,7 +28,7 @@ In order to reason about possible transports, `libp2p` uses [multiaddr](https://
|
||||
|
||||
**TODO:** Define how unreliable transport would work. Base it on WebRTC.
|
||||
|
||||
## 3.5 Multi-multiplexing
|
||||
## 3.2 Multi-multiplexing
|
||||
|
||||
The `libp2p` protocol is a collection of multiple protocols. In order to conserve resources, and to make connectivity easier, `libp2p` can perform all its operations through a single port, such as a TCP or UDP port, depending on the transports used. `libp2p` can multiplex its many protocols through point-to-point connections. This multiplexing is for both reliable streams and unreliable datagrams.
|
||||
|
||||
@@ -94,7 +58,44 @@ To give an example, imagine a single IPFS node that:
|
||||
|
||||
Not providing this level of flexbility makes it impossible to use `libp2p` in various platforms, use cases, or network setups. It is not important that all implementations support all choices; what is critical is that the spec is flexible enough to allow implementations to use precisely what they need. This ensures that complex user or application constraints do not rule out `libp2p` as an option.
|
||||
|
||||
## 3.6 Enable several network topologies
|
||||
## 3.3 Encryption
|
||||
|
||||
Communications on `libp2p` may be:
|
||||
|
||||
- **encrypted**
|
||||
- **signed** (not encrypted)
|
||||
- **clear** (not encrypted, not signed)
|
||||
|
||||
We take both security and performance seriously. We recognize that encryption is not viable for some in-datacenter high performance use cases.
|
||||
|
||||
We recommend that:
|
||||
|
||||
- implementations encrypt all communications by default
|
||||
- implementations are audited
|
||||
- unless absolutely necessary, users normally operate with encrypted communications only.
|
||||
|
||||
`libp2p` uses cyphersuites like TLS.
|
||||
|
||||
**Note:** We do not use TLS directly, because we do not want the CA system baggage. Most TLS implementations are very big. Since the `libp2p` model begins with keys, `libp2p` only needs to apply ciphers. This is a minimal portion of the whole TLS standard.
|
||||
|
||||
## 3.4 NAT traversal
|
||||
|
||||
Network Address Translation is ubiquitous in the Internet. Not only are most consumer devices behind many layers of NAT, but most data center nodes are often behind NAT for security or virtualization reasons. As we move into containerized deployments, this is getting worse. IPFS implementations SHOULD provide a way to traverse NATs, otherwise it is likely that operation will be affected. Even nodes meant to run with real IP addresses must implement NAT traversal techniques, as they may need to establish connections to peers behind NAT.
|
||||
|
||||
`libp2p` accomplishes full NAT traversal using an ICE-like protocol. It is not exactly ICE, as IPFS networks provide the possibility of relaying communications over the IPFS protocol itself, for coordinating hole-punching or even relaying communication.
|
||||
|
||||
It is recommended that implementations use one of the many NAT traversal libraries available, such as `libnice`, `libwebrtc`, or `natty`. However, NAT traversal must be interoperable.
|
||||
|
||||
## 3.5 Relay
|
||||
|
||||
Unfortunately, due to symmetric NATs, container and VM NATs, and other impossible-to-bypass NATs, `libp2p` MUST fallback to relaying communication to establish a full connectivity graph. To be complete, implementations MUST support relay, though it SHOULD be optional and able to be turned off by end users.
|
||||
|
||||
Connection relaying SHOULD be implemented as a transport, in order to be transparent to upper layers.
|
||||
|
||||
For an instantiation of relaying, see the [/ipfs/relay/circuit transport](transports/circuit-relay.md).
|
||||
|
||||
|
||||
# 3.6 Enable several network topologies
|
||||
|
||||
Different systems have different requirements and with that comes different topologies. In the P2P literature we can find these topologies being enumerated as: unstructured, structured, hybrid and centralized.
|
||||
|
||||
@@ -107,3 +108,11 @@ With this in consideration, `libp2p` must be ready to perform different routing
|
||||
`libp2p` also solves the problem with discoverability of resources inside of a network through *records*. A record is a unit of data that can be digitally signed, timestamped and/or used with other methods to give it an ephemeral validity. These records hold pieces of information such as location or availability of resources present in the network. These resources can be data, storage, CPU cycles and other types of services.
|
||||
|
||||
`libp2p` must not put a constraint on the location of resources, but instead offer ways to find them easily in the network or use a side channel.
|
||||
|
||||
## 3.8 Messaging
|
||||
|
||||
Efficient messaging protocols offer ways to deliver content with minimum latency and/or support large and complex topologies for distribution. `libp2p` seeks to incorporate the developments made in Multicast and PubSub to fulfil these needs.
|
||||
|
||||
## 3.9 Naming
|
||||
|
||||
Networks change and applications need to have a way to use the network in such a way that it is agnostic to its topology, naming appears to solve this issues.
|
||||
|
||||
@@ -77,7 +77,7 @@ See [/ipfs/relay/circuit transport](transports/circuit-relay.md).
|
||||
|
||||
### 4.3.1 Record
|
||||
|
||||
Follows [IPRS](../iprs-interplanetary-record-system).
|
||||
Follows [IPRS spec](../iprs).
|
||||
|
||||
### 4.3.2 abstract-record-store
|
||||
|
||||
@@ -112,3 +112,11 @@ Bootstrap-List is a Discovery Protocol that uses local storage to cache the addr
|
||||
- The list should be stored in long-term local storage, whatever that means to the local node (e.g. to disk).
|
||||
- Protocols can ship a default list hardcoded or along with the standard code distribution (like DNS).
|
||||
- In most cases (and certainly in the case of IPFS) the bootstrap list should be user configurable, as users may wish to establish separate networks, or place their reliance and trust in specific nodes.
|
||||
|
||||
## 4.5 Messaging
|
||||
|
||||
#### 4.5.1 PubSub
|
||||
|
||||
## 4.6 Naming
|
||||
|
||||
#### 4.5.2 IPNS
|
||||
|
||||
113
README.md
113
README.md
@@ -1,4 +1,4 @@
|
||||
# specs (work in progress!)
|
||||
# libp2p specification
|
||||
|
||||
|
||||
|
||||
@@ -6,18 +6,16 @@
|
||||
[](http://github.com/libp2p/libp2p)
|
||||
[](http://webchat.freenode.net/?channels=%23ipfs)
|
||||
|
||||
> The specs for libp2p and associated submodules.
|
||||
> tl;dr; This document presents `libp2p`, a modularized and extensible network stack to overcome the networking challenges faced when doing peer-to-peer applications. `libp2p` is used by IPFS as its networking library.
|
||||
|
||||
Authors:
|
||||
|
||||
- [Juan Benet](https://github.com/jbenet)
|
||||
- [David Dias](https://github.com/diasdavid)
|
||||
- [Juan Benet](https://github.com/jbenet)
|
||||
- [David Dias](https://github.com/diasdavid)
|
||||
|
||||
Reviewers:
|
||||
|
||||
|
||||
> tl;dr; This document presents `libp2p`, a modularized and extensible network stack to overcome the networking challenges faced when doing peer-to-peer applications. `libp2p` is used by IPFS as its networking library.
|
||||
|
||||
- `N/A`
|
||||
|
||||
## Abstract
|
||||
|
||||
@@ -25,9 +23,7 @@ This describes the [IPFS](https://ipfs.io/) network protocol. The network layer
|
||||
|
||||
This document defines the spec implemented in `libp2p`.
|
||||
|
||||
## Status of this spec
|
||||
|
||||
|
||||
## Status of this spec 
|
||||
|
||||
## Organization of this document
|
||||
|
||||
@@ -35,52 +31,63 @@ This RFC is organized by chapters described on the *Table of contents* section.
|
||||
|
||||
## Table of contents
|
||||
|
||||
- [1 Introduction](1-introduction.md)
|
||||
- [1.1 Motivation](1-introduction.md#11-motivation)
|
||||
- [1.2 Goals](1-introduction.md#12-goals)
|
||||
- [2 An analysis the state of the art in network stacks](2-state-of-the-art.md)
|
||||
- [2.1 The client-server model](2-state-of-the-art.md#21-the-client-server-model)
|
||||
- [2.2 Categorizing the network stack protocols by solutions](2-state-of-the-art.md#22-categorizing-the-network-stack-protocols-by-solutions)
|
||||
- [2.3 Current shortcommings](2-state-of-the-art.md#23-current-shortcommings)
|
||||
- [3 Requirements](3-requirements.md)
|
||||
- [3.1 NAT traversal](3-requirements.md#31-nat-traversal)
|
||||
- [3.2 Relay](3-requirements.md#32-relay)
|
||||
- [3.3 Encryption](3-requirements.md#33-encryption)
|
||||
- [3.4 Transport agnostic](3-requirements.md#34-transport-agnostic)
|
||||
- [3.5 Multi-multiplexing](3-requirements.md#35-multi-multiplexing)
|
||||
- [3.6 Enable several network topologies](3-requirements.md#36-enable-several-network-topologies)
|
||||
- [3.7 Resource discovery](3-requirements.md#37-resource-discovery)
|
||||
- [4 Architecture](4-architecture.md)
|
||||
- [4.1 Peer Routing](4-architecture.md#41-peer-routing)
|
||||
- [4.2 Swarm](4-architecture.md#42-swarm)
|
||||
- [4.3 Distributed Record Store](4-architecture.md#43-distributed-record-store)
|
||||
- [4.4 Discovery](4-architecture.md#44-discovery)
|
||||
- [5 Data structures](5-datastructures.md)
|
||||
- [6 Interfaces](6-interfaces.md)
|
||||
- [6.1 libp2p](6-interfaces.md#61-libp2p)
|
||||
- [6.2 Peer Routing](6-interfaces.md#62-peer-routing)
|
||||
- [6.3 Swarm](6-interfaces.md#63-swarm)
|
||||
- [6.4 Distributed Record Store](6-interfaces.md#64-distributed-record-store)
|
||||
- [6.5 Peer Discovery](6-interfaces.md#65-peer-discovery)
|
||||
- [6.6 libp2p interface and UX](6-interfaces.md#66-libp2p-interface-and-ux)
|
||||
- [7 Properties](7-properties.md)
|
||||
- [7.1 Communication Model - Streams](7-properties.md#71-communication-model---streams)
|
||||
- [7.2 Ports - Constrained Entrypoints](7-properties.md#72-ports---constrained-entrypoints)
|
||||
- [7.3 Transport Protocol](7-properties.md#73-transport-protocols)
|
||||
- [7.4 Non-IP Networks](7-properties.md#74-non-ip-networks)
|
||||
- [7.5 On the wire](7-properties.md#75-on-the-wire)
|
||||
- [7.5.1 Protocol-Multiplexing](7-properties.md#751-protocol-multiplexing)
|
||||
- [7.5.2 multistream - self-describing protocol stream](7-properties.md#752-multistream---self-describing-protocol-stream)
|
||||
- [7.5.3 multistream-selector - self-describing protocol stream selector](7-properties.md#753-multistream-selector---self-describing-protocol-stream-selector)
|
||||
- [7.5.4 Stream Multiplexing](7-properties.md#754-stream-multiplexing)
|
||||
- [7.5.5 Portable Encodings](7-properties.md#755-portable-encodings)
|
||||
- [7.5.6 Secure Communications](7-properties.md#756-secure-communications)
|
||||
- [8 Implementations](8-implementations.md)
|
||||
- [9 References](9-references.md)
|
||||
- [1 Introduction](1-introduction.md)
|
||||
- [1.1 Motivation](1-introduction.md#11-motivation)
|
||||
- [1.2 Goals](1-introduction.md#12-goals)
|
||||
- [2 An analysis the state of the art in network stacks](2-state-of-the-art.md)
|
||||
- [2.1 The client-server model](2-state-of-the-art.md#21-the-client-server-model)
|
||||
- [2.2 Categorizing the network stack protocols by solutions](2-state-of-the-art.md#22-categorizing-the-network-stack-protocols-by-solutions)
|
||||
- [2.3 Current shortcommings](2-state-of-the-art.md#23-current-shortcommings)
|
||||
- [3 Requirements](3-requirements.md)
|
||||
- [3.1 Transport agnostic](3-requirements.md#34-transport-agnostic)
|
||||
- [3.2 Multi-multiplexing](3-requirements.md#35-multi-multiplexing)
|
||||
- [3.3 Encryption](3-requirements.md#33-encryption)
|
||||
- [3.4 NAT traversal](3-requirements.md#31-nat-traversal)
|
||||
- [3.5 Relay](3-requirements.md#32-relay)
|
||||
- [3.6 Enable several network topologies](3-requirements.md#36-enable-several-network-topologies)
|
||||
- [3.7 Resource discovery](3-requirements.md#37-resource-discovery)
|
||||
- [3.8 Messaging](3-requirements.md#38-messaging)
|
||||
- [3.9 Naming](3-requirements.md#38-naming)
|
||||
- [4 Architecture](4-architecture.md)
|
||||
- [4.1 Peer Routing](4-architecture.md#41-peer-routing)
|
||||
- [4.2 Swarm](4-architecture.md#42-swarm)
|
||||
- [4.3 Distributed Record Store](4-architecture.md#43-distributed-record-store)
|
||||
- [4.4 Discovery](4-architecture.md#44-discovery)
|
||||
- [4.5 Messaging](4-architecture.md#45-messaging)
|
||||
- [4.5.1 PubSub]()
|
||||
- [4.6 Naming]()
|
||||
- [4.6.1 IPRS]()
|
||||
- [4.6.1 IPNS]()
|
||||
- [5 Data structures](5-datastructures.md)
|
||||
- [6 Interfaces](6-interfaces.md)
|
||||
- [6.1 libp2p](6-interfaces.md#61-libp2p)
|
||||
- [6.1 Transport](6-interfaces.md)
|
||||
- [6.2 Connection](6-interfaces.md)
|
||||
- [6.3 Stream Multiplexer](6-interfaces.md)
|
||||
- [6.3 Swarm](6-interfaces.md#63-swarm)
|
||||
- [6.5 Peer Discovery](6-interfaces.md#65-peer-discovery)
|
||||
- [6.2 Peer Routing](6-interfaces.md#62-peer-routing)
|
||||
- [6.2 Content Routing](6-interfaces.md#62-peer-routing)
|
||||
- [6.3.1 Distributed Record Store](6-interfaces.md#64-distributed-record-store)
|
||||
- [6.6 libp2p interface and UX](6-interfaces.md#66-libp2p-interface-and-ux)
|
||||
- [7 Properties](7-properties.md)
|
||||
- [7.1 Communication Model - Streams](7-properties.md#71-communication-model---streams)
|
||||
- [7.2 Ports - Constrained Entrypoints](7-properties.md#72-ports---constrained-entrypoints)
|
||||
- [7.3 Transport Protocol](7-properties.md#73-transport-protocols)
|
||||
- [7.4 Non-IP Networks](7-properties.md#74-non-ip-networks)
|
||||
- [7.5 On the wire](7-properties.md#75-on-the-wire)
|
||||
- [7.5.1 Protocol-Multiplexing](7-properties.md#751-protocol-multiplexing)
|
||||
- [7.5.2 multistream - self-describing protocol stream](7-properties.md#752-multistream---self-describing-protocol-stream)
|
||||
- [7.5.3 multistream-selector - self-describing protocol stream selector](7-properties.md#753-multistream-selector---self-describing-protocol-stream-selector)
|
||||
- [7.5.4 Stream Multiplexing](7-properties.md#754-stream-multiplexing)
|
||||
- [7.5.5 Portable Encodings](7-properties.md#755-portable-encodings)
|
||||
- [7.5.6 Secure Communications](7-properties.md#756-secure-communications)
|
||||
- [8 Implementations](8-implementations.md)
|
||||
- [9 References](9-references.md)
|
||||
|
||||
## Contribute
|
||||
|
||||
Please contribute! [Dive into the issues](https://github.com/libp2p/spec/issues)!
|
||||
Please contribute! [Dive into the issues](https://github.com/libp2p/specs/issues)!
|
||||
|
||||
Please be aware that all interactions related to multiformats are subject to the IPFS [Code of Conduct](https://github.com/ipfs/community/blob/master/code-of-conduct.md).
|
||||
|
||||
|
||||
169
pubsub/README.md
Normal file
169
pubsub/README.md
Normal file
@@ -0,0 +1,169 @@
|
||||
# libp2p pubsub specification
|
||||
|
||||
This is the specification for generalized pubsub over libp2p. Pubsub in libp2p
|
||||
is currently still experimental and this specification is subject to change.
|
||||
This document does not go over specific implementation of pubsub routing
|
||||
algorithms, it merely describes the common wire format that implementations
|
||||
will use.
|
||||
|
||||
libp2p pubsub currently uses reliable ordered streams between peers. It assumes
|
||||
that each peer is certain of the identity of each peer is it communicating
|
||||
with. It does not assume that messages between peers are encrypted, however
|
||||
encryption defaults to being enabled on libp2p streams.
|
||||
|
||||
You can find information about the PubSub research and notes in the following repos:
|
||||
|
||||
- https://github.com/libp2p/research-pubsub
|
||||
- https://github.com/libp2p/pubsub-notes
|
||||
|
||||
## The RPC
|
||||
|
||||
All communication between peers happens in the form of exchanging protobuf RPC
|
||||
messages between participating peers.
|
||||
|
||||
The RPC protobuf is as follows:
|
||||
|
||||
```protobuf
|
||||
message RPC {
|
||||
repeated SubOpts subscriptions = 1;
|
||||
repeated Message publish = 2;
|
||||
|
||||
message SubOpts {
|
||||
optional bool subscribe = 1;
|
||||
optional string topicid = 2;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This is a relatively simple message containing zero or more subscription
|
||||
messages, and zero or more content messages. The subscription messages contain
|
||||
a topicid string that specifies the topic, and a boolean signifying whether to
|
||||
subscribe or unsubscribe to the given topic. True signifies 'subscribe' and
|
||||
false signifies 'unsubscribe'.
|
||||
|
||||
## The Message
|
||||
|
||||
The RPC message can contain zero or more messages of type 'Message' (perhaps
|
||||
this should be named better?). The Message protobuf looks like this:
|
||||
|
||||
```protobuf
|
||||
message Message {
|
||||
optional string from = 1;
|
||||
optional bytes data = 2;
|
||||
optional bytes seqno = 3;
|
||||
repeated string topicIDs = 4;
|
||||
}
|
||||
```
|
||||
|
||||
The `from` field denotes the author of the message, note that this is not
|
||||
necessarily the peer who sent the RPC this message is contained in. This is
|
||||
done to allow content to be routed through a swarm of pubsubbing peers.
|
||||
|
||||
The `data` field is an opaque blob of data, it can contain any data that the
|
||||
publisher wants it to.
|
||||
|
||||
The `seqno` field is a linearly increasing, number unique among messages
|
||||
originating from each given peer. No two messages on a pubsub topic from the
|
||||
same peer should have the same seqno value, however messages from different
|
||||
peers may have the same sequence number, so this number alone cannot be used to
|
||||
address messages. (Notably the 'timecache' in use by the floodsub
|
||||
implementation uses the concatenation of the seqno and the 'from' field)
|
||||
|
||||
The `topicIDs` field specifies a set of topics that this message is being
|
||||
published to.
|
||||
|
||||
Note that messages are currently *not* signed. This will come in the near
|
||||
future.
|
||||
|
||||
## The Topic Descriptor
|
||||
|
||||
The topic descriptor message is used to define various options and parameters
|
||||
of a topic. It currently specifies the topics human readable name, its
|
||||
authentication options, and its encryption options.
|
||||
|
||||
The TopicDescriptor protobuf is as follows:
|
||||
|
||||
```protobuf
|
||||
message TopicDescriptor {
|
||||
optional string name = 1;
|
||||
optional AuthOpts auth = 2;
|
||||
optional EncOpts enc = 3;
|
||||
|
||||
message AuthOpts {
|
||||
optional AuthMode mode = 1;
|
||||
repeated bytes keys = 2;
|
||||
|
||||
enum AuthMode {
|
||||
NONE = 0;
|
||||
KEY = 1;
|
||||
WOT = 2;
|
||||
}
|
||||
}
|
||||
|
||||
message EncOpts {
|
||||
optional EncMode mode = 1;
|
||||
repeated bytes keyHashes = 2;
|
||||
|
||||
enum EncMode {
|
||||
NONE = 0;
|
||||
SHAREDKEY = 1;
|
||||
WOT = 2;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The `name` field is a string used to identify or mark the topic, It can be
|
||||
descriptive or random or anything the creator chooses.
|
||||
|
||||
The `auth` field specifies how authentication will work for this topic. Only
|
||||
authenticated peers may publish to a given topic. See 'AuthOpts' below for
|
||||
details.
|
||||
|
||||
The `enc` field specifies how messages published to this topic will be
|
||||
encrypted. See 'EncOpts' below for details.
|
||||
|
||||
### AuthOpts
|
||||
|
||||
The `AuthOpts` message describes an authentication scheme. The `mode` field
|
||||
specifies which scheme to use, and the `keys` field is an array of keys. The
|
||||
meaning of the `keys` field is defined by the selected `AuthMode`.
|
||||
|
||||
There are currently three options defined for the `AuthMode` enum:
|
||||
|
||||
#### AuthMode 'NONE'
|
||||
No authentication, anyone may publish to this topic.
|
||||
|
||||
#### AuthMode 'KEY'
|
||||
Only peers whose peerIDs are listed in the `keys` array may publish to this
|
||||
topic, messages from any other peer should be dropped.
|
||||
|
||||
#### AuthMode 'WOT'
|
||||
Web Of Trust, Any trusted peer may publish to the topic. A trusted peer is one
|
||||
whose peerID is listed in the `keys` array, or any peer who is 'trusted' by
|
||||
another trusted peer. The mechanism of signifying trust in another peer is yet
|
||||
to be defined.
|
||||
|
||||
|
||||
### EncOpts
|
||||
|
||||
The `EncOpts` message describes an encryption scheme for messages in a given
|
||||
topic. The `mode` field denotes which encryption scheme will be used, and the
|
||||
`keyHashes` field specifies a set of hashes of keys whose purpose may be
|
||||
defined by the selected mode.
|
||||
|
||||
There are currently three options defined for the `EncMode` enum:
|
||||
|
||||
#### EncMode 'NONE'
|
||||
Messages are not encrypted, anyone can read them.
|
||||
|
||||
#### EncMode 'SHAREDKEY'
|
||||
Messages are encrypted with a preshared key. The salted hash of the key used is
|
||||
denoted in the `keyHashes` field of the `EncOpts` message. The mechanism for
|
||||
sharing the keys and salts is undefined.
|
||||
|
||||
#### EncMode 'WOT'
|
||||
Web Of Trust publishing. Messages are encrypted with some certificate or
|
||||
certificate chain shared amongst trusted peers. (Spec writers note: this is the
|
||||
least clearly defined option and my description here may be wildly incorrect,
|
||||
needs checking).
|
||||
Reference in New Issue
Block a user