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

minor tweak to lifestyle doc phrase (#494)

Browse Source
This commit is contained in:
Danny Salman
2022-12-14 11:09:28 -05:00
committed by GitHub
parent 3fe53ec835
commit 946441e549
20 changed files with 69 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
00-framework-02-document-header.md
View File

@@ -17,7 +17,7 @@ Interest Group: [@raulk], [@vyzo], [@mgoelzer], [@jacobheun], [@tomaka]
[@jacobheun]: https://github.com/jacobheun [@jacobheun]: https://github.com/jacobheun
[@tomaka]: https://github.com/tomaka [@tomaka]: https://github.com/tomaka
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -33,7 +33,7 @@ help move it forward in its evolution.
This document defines a header format to convey this key status information in This document defines a header format to convey this key status information in
an easy-to-read manner. an easy-to-read manner.
## Example ## Example
```markdown ```markdown
# Spec title # Spec title
@@ -54,7 +54,7 @@ Interest Group: [@interested1], [@interested2]
[@interested1]: https://github.com/interested1 [@interested1]: https://github.com/interested1
[@interested2]: https://github.com/interested2 [@interested2]: https://github.com/interested2
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -64,7 +64,7 @@ and spec status.
### Title and Short Intro ### Title and Short Intro
Each spec begins with its title, formatted as an H1 markdown header. Each spec begins with its title, formatted as an H1 markdown header.
The title can optionally be followed by a short block-quote introducing the The title can optionally be followed by a short block-quote introducing the
spec, which serves as a subtitle and should be a maximum of one or two lines. spec, which serves as a subtitle and should be a maximum of one or two lines.
@@ -75,7 +75,7 @@ The main status information is contained in a markdown table, using the [table
syntax][gfm-tables] supported by [Github Flavored Markdown][gfm-spec]. syntax][gfm-tables] supported by [Github Flavored Markdown][gfm-spec].
The status table consists of a single row, with a header containing the field The status table consists of a single row, with a header containing the field
names. names.
Example: Example:
@@ -154,7 +154,7 @@ specs repo, an absolute URL is preferred when linking to the specs document.
Here's an example that can be copy/pasted directly: Here's an example that can be copy/pasted directly:
```markdown ```markdown
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

14
addressing/README.md
View File

@@ -13,7 +13,7 @@ Interest Group: [@mxinden, @Stebalien, @raulk, @marten-seemann, @vyzo]
[@yusefnapora]: https://github.com/yusefnapora [@yusefnapora]: https://github.com/yusefnapora
[@mxinden]: https://github.com/mxinden/ [@mxinden]: https://github.com/mxinden/
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -166,7 +166,7 @@ within](#encapsulation) another multiaddr.
For example, the above `p2p` address can be combined with the transport address For example, the above `p2p` address can be combined with the transport address
on which the node is listening: on which the node is listening:
``` ```
/ip4/7.7.7.7/tcp/1234/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N /ip4/7.7.7.7/tcp/1234/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N
``` ```
@@ -199,7 +199,7 @@ appreciated.
Most libp2p transports use the IP protocol as a foundational layer, and as a Most libp2p transports use the IP protocol as a foundational layer, and as a
result, most transport multiaddrs will begin with a component that represents an result, most transport multiaddrs will begin with a component that represents an
IPv4 or IPv6 address. IPv4 or IPv6 address.
This may be an actual address, such as `/ip4/7.7.7.7` or This may be an actual address, such as `/ip4/7.7.7.7` or
`/ip6/fe80::883:a581:fff1:833`, or it could be something that resolves to an IP `/ip6/fe80::883:a581:fff1:833`, or it could be something that resolves to an IP
@@ -219,7 +219,7 @@ resolvable or "name-based" protocols:
When the `/dns` protocol is used, the lookup may result in both IPv4 and IPv6 When the `/dns` protocol is used, the lookup may result in both IPv4 and IPv6
addresses, in which case IPv6 will be preferred. To explicitly resolve to IPv4 addresses, in which case IPv6 will be preferred. To explicitly resolve to IPv4
or IPv6 addresses, use the `/dns4` or `/dns6` protocols, respectively. or IPv6 addresses, use the `/dns4` or `/dns6` protocols, respectively.
Note that in some restricted environments, such as inside a web browser, libp2p Note that in some restricted environments, such as inside a web browser, libp2p
may not have access to the resolved IP addresses at all, in which case the may not have access to the resolved IP addresses at all, in which case the
@@ -269,7 +269,7 @@ wherever TCP/IP sockets are accessible.
Addresses for the TCP transport are of the form `<ip-multiaddr>/tcp/<tcp-port>`, Addresses for the TCP transport are of the form `<ip-multiaddr>/tcp/<tcp-port>`,
where `<ip-multiaddr>` is a multiaddr that resolves to an IP address, as where `<ip-multiaddr>` is a multiaddr that resolves to an IP address, as
described in the [IP and Name Resolution section](#ip-and-name-resolution). described in the [IP and Name Resolution section](#ip-and-name-resolution).
The `<tcp-port>` argument must be a 16-bit unsigned integer. The `<tcp-port>` argument must be a 16-bit unsigned integer.
### WebSockets ### WebSockets
@@ -288,7 +288,7 @@ multiaddr format mirrors this arrangement.
A libp2p QUIC multiaddr is of the form `<ip-multiaddr>/udp/<udp-port>/quic`, A libp2p QUIC multiaddr is of the form `<ip-multiaddr>/udp/<udp-port>/quic`,
where `<ip-multiaddr>` is a multiaddr that resolves to an IP address, as where `<ip-multiaddr>` is a multiaddr that resolves to an IP address, as
described in the [IP and Name Resolution section](#ip-and-name-resolution). described in the [IP and Name Resolution section](#ip-and-name-resolution).
The `<udp-port>` argument must be a 16-bit unsigned integer in network byte order. The `<udp-port>` argument must be a 16-bit unsigned integer in network byte order.
@@ -318,7 +318,7 @@ destination peer.
A full example would be: A full example would be:
``` ```
/ip4/127.0.0.1/tcp/5002/p2p/QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt /ip4/127.0.0.1/tcp/5002/p2p/QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt
``` ```

2
autonat/README.md
View File

@@ -17,7 +17,7 @@ Interest Group: [@mxinden], [@vyzo], [@raulk], [@stebalien], [@willscott]
[@stebalien]: https://github.com/stebalien [@stebalien]: https://github.com/stebalien
[@willscott]: https://github.com/willscott [@willscott]: https://github.com/willscott
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

8
connections/README.md
View File

@@ -14,7 +14,7 @@ Interest Group: [@JustMaier], [@vasco-santos] [@bigs], [@mgoelzer]
[@bigs]: https://github.com/bigs [@bigs]: https://github.com/bigs
[@mgoelzer]: https://github.com/mgoelzer [@mgoelzer]: https://github.com/mgoelzer
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -100,7 +100,7 @@ One of libp2p's core design goals is to be adaptable to many network
environments, including those that don't yet exist. To provide this flexibility, environments, including those that don't yet exist. To provide this flexibility,
the connection upgrade process supports multiple protocols for connection the connection upgrade process supports multiple protocols for connection
security and stream multiplexing and allows peers to select which to use for security and stream multiplexing and allows peers to select which to use for
each connection. each connection.
The process of selecting protocols is called **protocol negotiation**. In The process of selecting protocols is called **protocol negotiation**. In
addition to its role in the connection upgrade process, protocol negotiation is addition to its role in the connection upgrade process, protocol negotiation is
@@ -114,7 +114,7 @@ Each protocol supported by a peer is identified using a unique string called a
path-like structure containing a short name and a version number, separated by path-like structure containing a short name and a version number, separated by
`/` characters. For example: `/yamux/1.0.0` identifies version 1.0.0 of the `/` characters. For example: `/yamux/1.0.0` identifies version 1.0.0 of the
[`yamux` stream multiplexing protocol][yamux]. multistream-select itself has a [`yamux` stream multiplexing protocol][yamux]. multistream-select itself has a
protocol id of `/multistream/1.0.0`. protocol id of `/multistream/1.0.0`.
Including a version number in the protocol id simplifies the case where you want Including a version number in the protocol id simplifies the case where you want
to concurrently support multiple versions of a protocol, perhaps a stable version to concurrently support multiple versions of a protocol, perhaps a stable version
@@ -286,7 +286,7 @@ The recommended baseline **stream multiplexer** is [yamux][yamux], which
provides a very simple programmatic API and is supported in most libp2p provides a very simple programmatic API and is supported in most libp2p
implementations. implementations.
### State Management ### State Management
While the connection establishment process itself does not require any While the connection establishment process itself does not require any
persistent state, some state management is useful to assist bootstrapping and persistent state, some state management is useful to assist bootstrapping and

4
connections/hole-punching.md
View File

@@ -16,7 +16,7 @@ Interest Group: [@vyzo], [@vasco], [@stebalien], [@aarsh], [@raulk]
[@vasco]: https://github.com/vasco [@vasco]: https://github.com/vasco
[@vyzo]: https://github.com/vyzo [@vyzo]: https://github.com/vyzo
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -151,7 +151,7 @@ connections across the various permutations of the two dimensions.
- **Why use both [AutoNAT] and [STUN], why not settle on one for both TCP / QUIC - **Why use both [AutoNAT] and [STUN], why not settle on one for both TCP / QUIC
and WebRTC based hole punching?** and WebRTC based hole punching?**
On browser platforms libp2p implementations do not control the local WebRTC On browser platforms libp2p implementations do not control the local WebRTC
stack. This same stack can only operate with [STUN] and not [AutoNAT]. One stack. This same stack can only operate with [STUN] and not [AutoNAT]. One
could use [STUN] instead of [AutoNAT] for TCP and QUIC hole punching though. could use [STUN] instead of [AutoNAT] for TCP and QUIC hole punching though.

2
connections/simopen.md
View File

@@ -13,7 +13,7 @@ Interest Group: [@raulk], [@stebalien], [@mxinden]
[@stebalien]: https://github.com/stebalien [@stebalien]: https://github.com/stebalien
[@mxinden]: https://github.com/mxinden [@mxinden]: https://github.com/mxinden
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

10
discovery/mdns.md
View File

@@ -16,7 +16,7 @@ Interest Group: [@yusefnapora], [@raulk], [@daviddias], [@jacobheun]
[@daviddias]: https://github.com/daviddias [@daviddias]: https://github.com/daviddias
[@jacobheun]: https://github.com/jacobheun [@jacobheun]: https://github.com/jacobheun
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -59,7 +59,7 @@ Conceptually, it is very simple. When a peer starts (or detects a network change
As the this field doesn't carry any meaning, it is sufficient to ensure the uniqueness of this identifier. Peers SHOULD generate a random, lower-case alphanumeric string of least 32 characters in length when booting up their node. Peers SHOULD NOT use their Peer ID here because a future Peer ID could exceed the DNS label limit of 63 characters. As the this field doesn't carry any meaning, it is sufficient to ensure the uniqueness of this identifier. Peers SHOULD generate a random, lower-case alphanumeric string of least 32 characters in length when booting up their node. Peers SHOULD NOT use their Peer ID here because a future Peer ID could exceed the DNS label limit of 63 characters.
If a [private network](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) is in use, then the `service-name` contains the base-16 encoding of the network's fingerprint as in `_p2p-X._udp.local`. If a [private network](https://github.com/libp2p/specs/blob/master/pnet/Private-Networks-PSK-V1.md) is in use, then the `service-name` contains the base-16 encoding of the network's fingerprint as in `_p2p-X._udp.local`.
This prevents public and private networks from discovering each other's peers. This prevents public and private networks from discovering each other's peers.
## Peer Discovery ## Peer Discovery
@@ -98,8 +98,8 @@ A peer responds with the answer
``` ```
_services._dns-sd._udp.local PTR <service-name> _services._dns-sd._udp.local PTR <service-name>
``` ```
### Find All Response ### Find All Response
On receipt of a `find all peers` query, the following **additional records** should be included On receipt of a `find all peers` query, the following **additional records** should be included
@@ -122,7 +122,7 @@ Many existing tools ignore the Additional Records, and always send individual qu
## Issues ## Issues
[ ] mDNS requires link-local addresses. Loopback and "NAT busting" addresses should not sent and must be ignored on receipt? [ ] mDNS requires link-local addresses. Loopback and "NAT busting" addresses should not sent and must be ignored on receipt?
## References ## References
- [RFC 1035 - Domain Names (DNS)](https://tools.ietf.org/html/rfc1035) - [RFC 1035 - Domain Names (DNS)](https://tools.ietf.org/html/rfc1035)

14
fetch/README.md
View File

@@ -1,6 +1,6 @@
# Fetch v0.0.1 # Fetch v0.0.1
> The Fetch protocol is used for performing a direct peer-to-peer key-value lookup > The Fetch protocol is used for performing a direct peer-to-peer key-value lookup
| Lifecycle Stage | Maturity | Status | Latest Revision | | Lifecycle Stage | Maturity | Status | Latest Revision |
|-----------------|----------------|--------|-----------------| |-----------------|----------------|--------|-----------------|
@@ -12,7 +12,7 @@ Interest Group: [Insert Your Name Here]
[@aschmahmann]: https://github.com/aschmahmann [@aschmahmann]: https://github.com/aschmahmann
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -68,16 +68,16 @@ who doesn't want to use it to change anything about their current use.
3. Might be abused/overused given the simple nature of the protocol 3. Might be abused/overused given the simple nature of the protocol
### Expected Feature Set and Tentative Technical Directions ### Expected Feature Set and Tentative Technical Directions
Should support: `Fetch(key) (value, statusCode)` Should support: `Fetch(key) (value, statusCode)`
However, the level of specificity in the types of the above variables has wiggle room if people are interested. However, the level of specificity in the types of the above variables has wiggle room if people are interested.
The `go-libp2p-pubsub-router` implementation requires: The `go-libp2p-pubsub-router` implementation requires:
`key`: At least as generic as a UTF-8 string `key`: At least as generic as a UTF-8 string
`value`: At least as generic as a byte array `value`: At least as generic as a byte array
`statusCode`: Supports at least `OK`, `NOT_FOUND`, and `ERROR` `statusCode`: Supports at least `OK`, `NOT_FOUND`, and `ERROR`
## Wire protocol ## Wire protocol
@@ -117,7 +117,7 @@ message FetchResponse {
- `B` does some internal lookup and responds with a `RespondLatest` message - `B` does some internal lookup and responds with a `RespondLatest` message
- If `B` finds (and elects to send) some data `v` to `A` it sends `RespondLatest{status: SUCCESS, data: v}` - If `B` finds (and elects to send) some data `v` to `A` it sends `RespondLatest{status: SUCCESS, data: v}`
- If `B` has no data to send it responds with `RespondLatest{status: NOT_FOUND, data: null}` - If `B` has no data to send it responds with `RespondLatest{status: NOT_FOUND, data: null}`
- `A` ignores any information in the `data` field if the status is `NOT_FOUND` - `A` ignores any information in the `data` field if the status is `NOT_FOUND`
Note: If at any time `A` or `B` break from the protocol in some way, either by disconnecting/closing streams or by sending Note: If at any time `A` or `B` break from the protocol in some way, either by disconnecting/closing streams or by sending
invalid data there is no guarantee on the behavior from the other party. invalid data there is no guarantee on the behavior from the other party.

2
identify/README.md
View File

@@ -18,7 +18,7 @@ Interest Group: [@yusefnapora], [@tomaka], [@richardschneider], [@Stebalien], [@
[@Stebalien]: https://github.com/Stebalien [@Stebalien]: https://github.com/Stebalien
[@bigs]: https://github.com/bigs [@bigs]: https://github.com/bigs
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

2
kad-dht/README.md
View File

@@ -12,7 +12,7 @@ Interest Group:
[@jhiesey]: https://github.com/jhiesey [@jhiesey]: https://github.com/jhiesey
[@mxinden]: https://github.com/mxinden [@mxinden]: https://github.com/mxinden
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

2
mplex/README.md
View File

@@ -17,7 +17,7 @@ Interest Group: [@yusefnapora], [@richardschneider], [@jacobheun]
[@richardschneider]: https://github.com/richardschneider [@richardschneider]: https://github.com/richardschneider
[@jacobheun]: https://github.com/jacobheun [@jacobheun]: https://github.com/jacobheun
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

20
noise/README.md
View File

@@ -28,7 +28,7 @@ Interest Group: [@raulk], [@tomaka], [@romanb], [@shahankhatch], [@Mikerah],
[@mhchia]: https://github.com/mhchia [@mhchia]: https://github.com/mhchia
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -81,14 +81,14 @@ a component that layers security and stream multiplexing over "raw" connections
like TCP sockets. When peers connect, the upgrader uses a protocol called like TCP sockets. When peers connect, the upgrader uses a protocol called
multistream-select to negotiate which security and multiplexing protocols to multistream-select to negotiate which security and multiplexing protocols to
use. The upgrade process is described in the [connection establishment use. The upgrade process is described in the [connection establishment
spec][conn-spec]. spec][conn-spec].
The transport upgrade process is likely to evolve soon, as we are in the process The transport upgrade process is likely to evolve soon, as we are in the process
of designing multiselect 2, a successor to multistream-select. Some noise-libp2p of designing multiselect 2, a successor to multistream-select. Some noise-libp2p
features are designed to enable proposed features of multiselect 2, however features are designed to enable proposed features of multiselect 2, however
noise-libp2p is fully compatible with the current upgrade process and noise-libp2p is fully compatible with the current upgrade process and
multistream-select. See the [Negotiation section](#negotiation) for details multistream-select. See the [Negotiation section](#negotiation) for details
about protocol negotiation. about protocol negotiation.
Every Noise connection begins with a handshake between an initiating peer and a Every Noise connection begins with a handshake between an initiating peer and a
responding peer, or in libp2p terms, a dialer and a listener. Over the course of responding peer, or in libp2p terms, a dialer and a listener. Over the course of
@@ -205,10 +205,10 @@ messages. We leverage this construct to transmit:
The extensions are inserted into the first message of the handshake pattern The extensions are inserted into the first message of the handshake pattern
**that guarantees secrecy**. Specifically, this means that the initiator MUST NOT **that guarantees secrecy**. Specifically, this means that the initiator MUST NOT
send extensions in their first message. send extensions in their first message.
The initiator sends its extensions in message 3 (closing message), and the The initiator sends its extensions in message 3 (closing message), and the
responder sends theirs in message 2 (their only message). It should be stressed, responder sends theirs in message 2 (their only message). It should be stressed,
that while the second message of the handshake pattern has forward secrecy, that while the second message of the handshake pattern has forward secrecy,
the sender has not authenticated the responder yet, so this payload might be the sender has not authenticated the responder yet, so this payload might be
sent to any party, including an active attacker. sent to any party, including an active attacker.
@@ -257,7 +257,7 @@ knowledge of the other's static public key.
`noise-libp2p` supports the [XX handshake pattern](#xx), which provides mutual `noise-libp2p` supports the [XX handshake pattern](#xx), which provides mutual
authentication and encryption of static keys and handshake payloads and is authentication and encryption of static keys and handshake payloads and is
resistant to replay attacks. resistant to replay attacks.
Prior revisions of this spec included a compound protocol involving the `IK` and Prior revisions of this spec included a compound protocol involving the `IK` and
`XXfallback `patterns, but this was [removed](#why-the-xx-handshake-pattern) due `XXfallback `patterns, but this was [removed](#why-the-xx-handshake-pattern) due
@@ -265,7 +265,7 @@ to the benefits not justifying the considerable additional complexity.
#### XX #### XX
``` ```
XX: XX:
-> e -> e
<- e, ee, s, es <- e, ee, s, es
@@ -337,7 +337,7 @@ The `noise_message_len` field stores the length in bytes of the `noise_message`
field, encoded as a 16-bit big-endian unsigned integer. field, encoded as a 16-bit big-endian unsigned integer.
The `noise_message` field contains a [Noise Message as defined in the Noise The `noise_message` field contains a [Noise Message as defined in the Noise
spec][npf-message-format], which has a maximum length of 65535 bytes. spec][npf-message-format], which has a maximum length of 65535 bytes.
During the handshake phase, `noise_message` will be a Noise handshake message. During the handshake phase, `noise_message` will be a Noise handshake message.
Noise handshake messages may contain encrypted payloads. If so, they will have Noise handshake messages may contain encrypted payloads. If so, they will have
@@ -352,7 +352,7 @@ payload plus 16 bytes of authentication data.
During the handshake phase, the initiator (Alice) will initialize a Noise During the handshake phase, the initiator (Alice) will initialize a Noise
[`HandshakeState` object][npf-handshake-state] with the [Noise protocol [`HandshakeState` object][npf-handshake-state] with the [Noise protocol
name](#noise-protocol-name) `Noise_XX_25519_ChaChaPoly_SHA256`. name](#noise-protocol-name) `Noise_XX_25519_ChaChaPoly_SHA256`.
Alice and Bob exchange handshake messages, during which they [authenticate each Alice and Bob exchange handshake messages, during which they [authenticate each
other's static Noise keys](#static-key-authentication). Handshake messages are other's static Noise keys](#static-key-authentication). Handshake messages are

4
plaintext/README.md
View File

@@ -19,7 +19,7 @@ Interest Group: [@raulk], [@Warchant], [@Stebalien], [@mhchia]
[@Stebalien]: https://github.com/Stebalien [@Stebalien]: https://github.com/Stebalien
[@mhchia]: https://github.com/mhchia [@mhchia]: https://github.com/mhchia
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -55,7 +55,7 @@ process][conn-spec-conn-upgrade].
## Protocol Id and Version History ## Protocol Id and Version History
The plaintext protocol described in this document has the protocol id of The plaintext protocol described in this document has the protocol id of
`/plaintext/2.0.0`. `/plaintext/2.0.0`.
An earlier version, `/plaintext/1.0.0`, was implemented in several languages, An earlier version, `/plaintext/1.0.0`, was implemented in several languages,
but it did not include any exchange of public keys or peer ids. This led to but it did not include any exchange of public keys or peer ids. This led to

4
pnet/Private-Networks-PSK-V1.md
View File

@@ -15,7 +15,7 @@ Interest Group: [@yusefnapora], [@jacobheun], [@lgierth], [@daviddias]
[@lgierth]: https://github.com/lgierth [@lgierth]: https://github.com/lgierth
[@daviddias]: https://github.com/daviddias [@daviddias]: https://github.com/daviddias
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -40,7 +40,7 @@ In the case of an IPFS node, this key is stored inside the IPFS repo in a file n
Nodes of different private networks must not be able to connect to each other. This extends to node in private network connecting to node in public network. This means that no information exchange, apart from the handshakes required for private network authentication, should take place. Nodes of different private networks must not be able to connect to each other. This extends to node in private network connecting to node in public network. This means that no information exchange, apart from the handshakes required for private network authentication, should take place.
These guarnetee is only provided when knowledge of private key is limited to trusted party. These guarnetee is only provided when knowledge of private key is limited to trusted party.
#### Safeguard #### Safeguard

16
pubsub/README.md
View File

@@ -19,7 +19,7 @@ Interest Group: [@yusefnapora], [@raulk], [@vyzo], [@Stebalien], [@jamesray1], [
[@vasco-santos]: https://github.com/vasco-santos [@vasco-santos]: https://github.com/vasco-santos
[@protolambda]: https://github.com/protolambda [@protolambda]: https://github.com/protolambda
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -140,7 +140,7 @@ conjunction with `from` to derive a unique `message_id` (in the default
configuration). configuration).
Henceforth, we define the term **origin-stamped messaging** to refer to messages Henceforth, we define the term **origin-stamped messaging** to refer to messages
whose `from` and `seqno` fields are populated. whose `from` and `seqno` fields are populated.
The `data` (optional) field is an opaque blob of data representing the payload. The `data` (optional) field is an opaque blob of data representing the payload.
It can contain any data that the publisher wants it to. It can contain any data that the publisher wants it to.
@@ -175,7 +175,7 @@ By default, **origin-stamping** is in force. This strategy relies on the string
concatenation of the `from` and `seqno` fields, to uniquely identify a message concatenation of the `from` and `seqno` fields, to uniquely identify a message
based on the *author*. based on the *author*.
Alternatively, a user-defined `message_id_fn` may be supplied, where Alternatively, a user-defined `message_id_fn` may be supplied, where
`message_id_fn(Message) => message_id`. Such a function could compute the hash `message_id_fn(Message) => message_id`. Such a function could compute the hash
of the `data` field within the `Message`, and thus one could reify of the `data` field within the `Message`, and thus one could reify
**content-addressed messaging**. **content-addressed messaging**.
@@ -259,7 +259,7 @@ is configurable per topic.
The intersection of signing behaviours across the two axes (signature creation The intersection of signing behaviours across the two axes (signature creation
and signature verification) gives way to four signature policy options: and signature verification) gives way to four signature policy options:
* `StrictSign`, `StrictNoSign`. Deterministic, usage encouraged. * `StrictSign`, `StrictNoSign`. Deterministic, usage encouraged.
* `LaxSign`, `LaxNoSign`. Non-deterministic, legacy, usage discouraged. Mostly * `LaxSign`, `LaxNoSign`. Non-deterministic, legacy, usage discouraged. Mostly
for backwards compatibility. Will be deprecated. If the implementation decides for backwards compatibility. Will be deprecated. If the implementation decides
@@ -270,7 +270,7 @@ and signature verification) gives way to four signature policy options:
On the producing side: On the producing side:
- Build messages with the `signature`, `key` (`from` may be enough for - Build messages with the `signature`, `key` (`from` may be enough for
certain inlineable public key types), `from` and `seqno` fields. certain inlineable public key types), `from` and `seqno` fields.
On the consuming side: On the consuming side:
- Enforce the fields to be present, reject otherwise. - Enforce the fields to be present, reject otherwise.
- Propagate only if the fields are valid and signature can be verified, - Propagate only if the fields are valid and signature can be verified,
@@ -282,7 +282,7 @@ On the producing side:
- Build messages without the `signature`, `key`, `from` and `seqno` fields. - Build messages without the `signature`, `key`, `from` and `seqno` fields.
- The corresponding protobuf key-value pairs are absent from the marshalled - The corresponding protobuf key-value pairs are absent from the marshalled
message, not just empty. message, not just empty.
On the consuming side: On the consuming side:
- Enforce the fields to be absent, reject otherwise. - Enforce the fields to be absent, reject otherwise.
- Propagate only if the fields are absent, reject otherwise. - Propagate only if the fields are absent, reject otherwise.
@@ -300,7 +300,7 @@ Always sign, and verify incoming signatures, and but accept unsigned messages.
On the producing side: On the producing side:
- Build messages with the `signature`, `key` (`from` may be enough), `from` - Build messages with the `signature`, `key` (`from` may be enough), `from`
and `seqno` fields. and `seqno` fields.
On the consuming side: On the consuming side:
- `signature` may be absent, and not verified. - `signature` may be absent, and not verified.
- Verify `signature`, iff the `signature` is present, then reject if - Verify `signature`, iff the `signature` is present, then reject if
@@ -322,7 +322,7 @@ On the consuming side:
`signature` is invalid. `signature` is invalid.
> **[[ Margin note: ]]** For content-addressed messaging, `StrictNoSign` is the > **[[ Margin note: ]]** For content-addressed messaging, `StrictNoSign` is the
> most appropriate policy option, coupled with a user-defined `message_id_fn`, > most appropriate policy option, coupled with a user-defined `message_id_fn`,
> and a validator function to verify protocol-defined signatures. > and a validator function to verify protocol-defined signatures.
> >
> When publisher anonymity is being sought, `StrictNoSign` is also the most > When publisher anonymity is being sought, `StrictNoSign` is also the most

12
pubsub/gossipsub/gossipsub-v1.0-old.md
View File

@@ -19,7 +19,7 @@ Interest Group: [@yusefnapora], [@raulk], [@whyrusleeping], [@Stebalien], [@jame
[@daviddias]: https://github.com/daviddias [@daviddias]: https://github.com/daviddias
[@yiannisbot]: https://github.com/yiannisbot [@yiannisbot]: https://github.com/yiannisbot
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -251,12 +251,12 @@ Topic membership is controlled by two operations supported by the
router, as part of the pubsub api: router, as part of the pubsub api:
- On `JOIN(topic)` the router joins the topic. In order to do so, if it already has - On `JOIN(topic)` the router joins the topic. In order to do so, if it already has
`D` peers from the `fanout` peers of a topic, then it adds them to `mesh[topic]`, `D` peers from the `fanout` peers of a topic, then it adds them to `mesh[topic]`,
and notifies them with a `GRAFT(topic)` control message. Otherwise, if there are and notifies them with a `GRAFT(topic)` control message. Otherwise, if there are
less than `D` peers (let this number be `x`) in the fanout for a topic (or the less than `D` peers (let this number be `x`) in the fanout for a topic (or the
topic is not in the fanout), then it topic is not in the fanout), then it
still adds them as above (if there are any), and selects the remaining number still adds them as above (if there are any), and selects the remaining number
of peers (`D-x`) from `peers.gossipsub[topic]`, and likewise adds them to of peers (`D-x`) from `peers.gossipsub[topic]`, and likewise adds them to
`mesh[topic]` and notifies them with a `GRAFT(topic)` control message. `mesh[topic]` and notifies them with a `GRAFT(topic)` control message.
- On `LEAVE(topic)` the router leaves the topic. It notifies the peers in - On `LEAVE(topic)` the router leaves the topic. It notifies the peers in
`mesh[topic]` with a `PRUNE(topic)` message and forgets `mesh[topic]`. `mesh[topic]` with a `PRUNE(topic)` message and forgets `mesh[topic]`.

2
relay/circuit-v1.md
View File

@@ -15,7 +15,7 @@ Interest Group: [@lgierth], [@hsanjuan], [@jamesray1], [@vyzo], [@yusefnapora]
[@vyzo]: https://github.com/vyzo [@vyzo]: https://github.com/vyzo
[@yusefnapora]: https://github.com/yusefnapora [@yusefnapora]: https://github.com/yusefnapora
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

2
relay/circuit-v2.md
View File

@@ -15,7 +15,7 @@ Interest Group: [@mxinden], [@stebalien], [@raulk]
[@stebalien]: https://github.com/stebalien [@stebalien]: https://github.com/stebalien
[@raulk]: https://github.com/raulk [@raulk]: https://github.com/raulk
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

2
rendezvous/README.md
View File

@@ -16,7 +16,7 @@ Interest Group: [@daviddias], [@whyrusleeping], [@Stebalien], [@jacobheun], [@yu
[@yusefnapora]: https://github.com/yusefnapora [@yusefnapora]: https://github.com/yusefnapora
[@vasco-santos]: https://github.com/vasco-santos [@vasco-santos]: https://github.com/vasco-santos
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

4
tls/tls.md
View File

@@ -16,7 +16,7 @@ Interest Group: [@Stebalien], [@jacobheun], [@raulk], [@Kubuxu], [@yusefnapora]
[@yusefnapora]: https://github.com/yusefnapora [@yusefnapora]: https://github.com/yusefnapora
See the [lifecycle document][lifecycle-spec] for context about maturity level See the [lifecycle document][lifecycle-spec] for context about the maturity level
and spec status. and spec status.
[lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md
@@ -97,7 +97,7 @@ The public host key and the signature are ANS.1-encoded into the SignedKey data
```asn1 ```asn1
SignedKey ::= SEQUENCE { SignedKey ::= SEQUENCE {
publicKey OCTET STRING, publicKey OCTET STRING,
signature OCTET STRING signature OCTET STRING
} }
``` ```