minor tweak to lifestyle doc phrase (#494)

00-framework-02-document-header.md

@@ -17,7 +17,7 @@ Interest Group: [@raulk], [@vyzo], [@mgoelzer], [@jacobheun], [@tomaka]
 [@jacobheun]: https://github.com/jacobheun
 [@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.
 
 [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
 an easy-to-read manner.
 
-## Example 
+## Example
 
 ```markdown
 # Spec title
@@ -54,7 +54,7 @@ Interest Group: [@interested1], [@interested2]
 [@interested1]: https://github.com/interested1
 [@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.
 
 [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
 
-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
 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].
 
 The status table consists of a single row, with a header containing the field
-names. 
+names.
 
 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:
 
 ```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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

addressing/README.md

@@ -13,7 +13,7 @@ Interest Group: [@mxinden, @Stebalien, @raulk, @marten-seemann, @vyzo]
 [@yusefnapora]: https://github.com/yusefnapora
 [@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.
 
 [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
 on which the node is listening:
 
-``` 
+```
 /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
 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
 `/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
 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
 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>`,
 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.
 
 ### WebSockets
@@ -288,7 +288,7 @@ multiaddr format mirrors this arrangement.
 
 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
-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.
 
 
@@ -318,7 +318,7 @@ destination peer.
 
 A full example would be:
 
-``` 
+```
 /ip4/127.0.0.1/tcp/5002/p2p/QmdPU7PfRyKehdrP5A3WqmjyD6bhVpU1mLGKppa2FjGDjZ/p2p-circuit/p2p/QmVT6GYwjeeAF5TR485Yc58S3xRF5EFsZ5YAF4VcP3URHt
 ```
 

autonat/README.md

@@ -17,7 +17,7 @@ Interest Group: [@mxinden], [@vyzo], [@raulk], [@stebalien], [@willscott]
 [@stebalien]: https://github.com/stebalien
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

connections/README.md

@@ -14,7 +14,7 @@ Interest Group: [@JustMaier], [@vasco-santos] [@bigs], [@mgoelzer]
 [@bigs]: https://github.com/bigs
 [@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.
 
 [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,
 the connection upgrade process supports multiple protocols for connection
 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
 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
 `/` characters. For example: `/yamux/1.0.0` identifies version 1.0.0 of the
 [`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
 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
 implementations.
 
-### State Management 
+### State Management
 
 While the connection establishment process itself does not require any
 persistent state, some state management is useful to assist bootstrapping and

connections/hole-punching.md

@@ -16,7 +16,7 @@ Interest Group: [@vyzo], [@vasco], [@stebalien], [@aarsh], [@raulk]
 [@vasco]: https://github.com/vasco
 [@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.
 
 [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
   and WebRTC based hole punching?**
-  
+
   On browser platforms libp2p implementations do not control the local WebRTC
   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.

connections/simopen.md

@@ -13,7 +13,7 @@ Interest Group: [@raulk], [@stebalien], [@mxinden]
 [@stebalien]: https://github.com/stebalien
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

discovery/mdns.md

@@ -16,7 +16,7 @@ Interest Group: [@yusefnapora], [@raulk], [@daviddias], [@jacobheun]
 [@daviddias]: https://github.com/daviddias
 [@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.
 
 [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.
 
-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.
 
 ## Peer Discovery
@@ -98,8 +98,8 @@ A peer responds with the answer
 
 ```
     _services._dns-sd._udp.local PTR <service-name>
-```   
-   
+```
+
 ### Find All Response
 
 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
 
 [ ] mDNS requires link-local addresses. Loopback and "NAT busting" addresses should not sent and must be ignored on receipt?
- 
+
 ## References
 
 - [RFC 1035 - Domain Names (DNS)](https://tools.ietf.org/html/rfc1035)

fetch/README.md

@@ -1,6 +1,6 @@
 # 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 |
 |-----------------|----------------|--------|-----------------|
@@ -12,7 +12,7 @@ Interest Group: [Insert Your Name Here]
 
 [@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.
 
 [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
 
 ### Expected Feature Set and Tentative Technical Directions
- 
+
 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.
 The `go-libp2p-pubsub-router` implementation requires:
- 
+
  `key`: At least as generic as a UTF-8 string
- 
+
  `value`: At least as generic as a byte array
- 
+
  `statusCode`: Supports at least `OK`, `NOT_FOUND`, and `ERROR`
 
 ## Wire protocol
@@ -117,7 +117,7 @@ message FetchResponse {
 - `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` 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
 invalid data there is no guarantee on the behavior from the other party.

identify/README.md

@@ -18,7 +18,7 @@ Interest Group: [@yusefnapora], [@tomaka], [@richardschneider], [@Stebalien], [@
 [@Stebalien]: https://github.com/Stebalien
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

kad-dht/README.md

@@ -12,7 +12,7 @@ Interest Group:
 [@jhiesey]: https://github.com/jhiesey
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

mplex/README.md

@@ -17,7 +17,7 @@ Interest Group: [@yusefnapora], [@richardschneider], [@jacobheun]
 [@richardschneider]: https://github.com/richardschneider
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

noise/README.md

@@ -28,7 +28,7 @@ Interest Group: [@raulk], [@tomaka], [@romanb], [@shahankhatch], [@Mikerah],
 [@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.
 
 [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
 multistream-select to negotiate which security and multiplexing protocols to
 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
 of designing multiselect 2, a successor to multistream-select. Some noise-libp2p
 features are designed to enable proposed features of multiselect 2, however
 noise-libp2p is fully compatible with the current upgrade process and
 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
 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
 **that guarantees secrecy**. Specifically, this means that the initiator MUST NOT
-send extensions in their first message. 
-The initiator sends its extensions in message 3 (closing message), and the 
+send extensions in their first message.
+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,
-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
 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
 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
 `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:
   -> e
   <- 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.
 
 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.
 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
 [`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
 other's static Noise keys](#static-key-authentication). Handshake messages are

plaintext/README.md

@@ -19,7 +19,7 @@ Interest Group: [@raulk], [@Warchant], [@Stebalien], [@mhchia]
 [@Stebalien]: https://github.com/Stebalien
 [@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.
 
 [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
 
 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,
 but it did not include any exchange of public keys or peer ids. This led to

pnet/Private-Networks-PSK-V1.md

@@ -15,7 +15,7 @@ Interest Group: [@yusefnapora], [@jacobheun], [@lgierth], [@daviddias]
 [@lgierth]: https://github.com/lgierth
 [@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.
 
 [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.
 
-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
 

pubsub/README.md

@@ -19,7 +19,7 @@ Interest Group: [@yusefnapora], [@raulk], [@vyzo], [@Stebalien], [@jamesray1], [
 [@vasco-santos]: https://github.com/vasco-santos
 [@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.
 
 [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).
 
 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.
 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
 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
 of the `data` field within the `Message`, and thus one could reify
 **content-addressed messaging**.
@@ -259,7 +259,7 @@ is configurable per topic.
 
 The intersection of signing behaviours across the two axes (signature creation
 and signature verification) gives way to four signature policy options:
- 
+
 * `StrictSign`, `StrictNoSign`. Deterministic, usage encouraged.
 * `LaxSign`, `LaxNoSign`. Non-deterministic, legacy, usage discouraged. Mostly
   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:
   - Build messages with the `signature`, `key` (`from` may be enough for
     certain inlineable public key types), `from` and `seqno` fields.
-  
+
 On the consuming side:
   - Enforce the fields to be present, reject otherwise.
   - 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.
   - The corresponding protobuf key-value pairs are absent from the marshalled
     message, not just empty.
-  
+
 On the consuming side:
   - Enforce the fields to be 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:
   - Build messages with the `signature`, `key` (`from` may be enough), `from`
     and `seqno` fields.
-  
+
 On the consuming side:
   - `signature` may be absent, and not verified.
   - Verify `signature`, iff the `signature` is present, then reject if
@@ -322,7 +322,7 @@ On the consuming side:
     `signature` is invalid.
 
 > **[[ 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.
 >
 > When publisher anonymity is being sought, `StrictNoSign` is also the most

pubsub/gossipsub/gossipsub-v1.0-old.md

@@ -19,7 +19,7 @@ Interest Group: [@yusefnapora], [@raulk], [@whyrusleeping], [@Stebalien], [@jame
 [@daviddias]: https://github.com/daviddias
 [@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.
 
 [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:
 - 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]`,
-  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 
-  topic is not in the fanout), then it 
+  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
+  topic is not in the fanout), then it
   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 
-  `mesh[topic]` and notifies them with a `GRAFT(topic)` control message. 
+  of peers (`D-x`) from `peers.gossipsub[topic]`, and likewise adds them to
+  `mesh[topic]` and notifies them with a `GRAFT(topic)` control message.
 - On `LEAVE(topic)` the router leaves the topic. It notifies the peers in
   `mesh[topic]` with a `PRUNE(topic)` message and forgets `mesh[topic]`.
 

relay/circuit-v1.md

@@ -15,7 +15,7 @@ Interest Group: [@lgierth], [@hsanjuan], [@jamesray1], [@vyzo], [@yusefnapora]
 [@vyzo]: https://github.com/vyzo
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

relay/circuit-v2.md

@@ -15,7 +15,7 @@ Interest Group: [@mxinden], [@stebalien], [@raulk]
 [@stebalien]: https://github.com/stebalien
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

rendezvous/README.md

@@ -16,7 +16,7 @@ Interest Group: [@daviddias], [@whyrusleeping], [@Stebalien], [@jacobheun], [@yu
 [@yusefnapora]: https://github.com/yusefnapora
 [@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.
 
 [lifecycle-spec]: https://github.com/libp2p/specs/blob/master/00-framework-01-spec-lifecycle.md

tls/tls.md

@@ -16,7 +16,7 @@ Interest Group: [@Stebalien], [@jacobheun], [@raulk], [@Kubuxu], [@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.
 
 [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
 SignedKey ::= SEQUENCE {
   publicKey OCTET STRING,
-  signature OCTET STRING 
+  signature OCTET STRING
 }
 ```