@libp2p/peer-record 8.0.20-e7e01f58f → 8.0.20-f465c5473

package/README.md

@@ -126,9 +126,9 @@ When a libp2p node changes its listen addresses, the identify service will be in
 
 ### Subsystem receiving a record
 
-Considering that a node can discover other peers' addresses from a variety of sources, Libp2p Peerstore can differentiate the addresses that were obtained through a signed peer record.
+Considering that a node can discover other peers' addresses from a variety of sources, Libp2p PeerStore can differentiate the addresses that were obtained through a signed peer record.
 
-Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshalled so that we can quickly compare it against incoming records to determine the most recent record.
+Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshaled so that we can quickly compare it against incoming records to determine the most recent record.
 
 The AddressBook Addresses will be updated with the content of the envelope with a certified property. This allows other subsystems to identify the known certified addresses of a peer.
 
@@ -146,7 +146,7 @@ When a subsystem wants to provide a record, it will get it from the AddressBook,
 - Some addresses may be ambiguous. For example, addresses on a private subnet are valid within that subnet but are useless on the public internet.
 - Once all these pieces are in place, we will also need a way to prioritize addresses based on their authenticity, that is, the dialer can prioritize self-certified addresses over addresses from an unknown origin.
 - Modular dialer? (taken from go PR notes)
-  - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritise dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
+  - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritize dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
   - Multiple parallel dials. We already have the issue where new addresses aren't added to existing dials.
 
 # Install

package/dist/src/envelope/index.d.ts

@@ -17,8 +17,8 @@ export declare class RecordEnvelope implements Envelope {
      */
     static seal: (record: Record, privateKey: PrivateKey) => Promise<RecordEnvelope>;
     /**
-     * Open and certify a given marshalled envelope.
-     * Data is unmarshalled and the signature validated for the given domain.
+     * Open and certify a given marshaled envelope.
+     * Data is unmarshaled and the signature validated for the given domain.
      */
     static openAndCertify: (data: Uint8Array | Uint8ArrayList, domain: string) => Promise<RecordEnvelope>;
     publicKey: PublicKey;

package/dist/src/envelope/index.js

@@ -40,8 +40,8 @@ export class RecordEnvelope {
         });
     };
     /**
-     * Open and certify a given marshalled envelope.
-     * Data is unmarshalled and the signature validated for the given domain.
+     * Open and certify a given marshaled envelope.
+     * Data is unmarshaled and the signature validated for the given domain.
      */
     static openAndCertify = async (data, domain) => {
         const envelope = await RecordEnvelope.createFromProtobuf(data);

package/dist/src/index.d.ts

@@ -103,9 +103,9 @@ import { generateKeyPair } from '@libp2p/crypto/keys'
  *
  * ### Subsystem receiving a record
  *
- * Considering that a node can discover other peers' addresses from a variety of sources, Libp2p Peerstore can differentiate the addresses that were obtained through a signed peer record.
+ * Considering that a node can discover other peers' addresses from a variety of sources, Libp2p PeerStore can differentiate the addresses that were obtained through a signed peer record.
  *
- * Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshalled so that we can quickly compare it against incoming records to determine the most recent record.
+ * Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshaled so that we can quickly compare it against incoming records to determine the most recent record.
  *
  * The AddressBook Addresses will be updated with the content of the envelope with a certified property. This allows other subsystems to identify the known certified addresses of a peer.
  *
@@ -123,7 +123,7 @@ import { generateKeyPair } from '@libp2p/crypto/keys'
  * - Some addresses may be ambiguous. For example, addresses on a private subnet are valid within that subnet but are useless on the public internet.
  * - Once all these pieces are in place, we will also need a way to prioritize addresses based on their authenticity, that is, the dialer can prioritize self-certified addresses over addresses from an unknown origin.
  * - Modular dialer? (taken from go PR notes)
- *     - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritise dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
+ *     - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritize dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
  *     - Multiple parallel dials. We already have the issue where new addresses aren't added to existing dials.
  */
 export { RecordEnvelope } from './envelope/index.js';

package/dist/src/index.js

@@ -103,9 +103,9 @@ import { generateKeyPair } from '@libp2p/crypto/keys'
  *
  * ### Subsystem receiving a record
  *
- * Considering that a node can discover other peers' addresses from a variety of sources, Libp2p Peerstore can differentiate the addresses that were obtained through a signed peer record.
+ * Considering that a node can discover other peers' addresses from a variety of sources, Libp2p PeerStore can differentiate the addresses that were obtained through a signed peer record.
  *
- * Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshalled so that we can quickly compare it against incoming records to determine the most recent record.
+ * Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshaled so that we can quickly compare it against incoming records to determine the most recent record.
  *
  * The AddressBook Addresses will be updated with the content of the envelope with a certified property. This allows other subsystems to identify the known certified addresses of a peer.
  *
@@ -123,7 +123,7 @@ import { generateKeyPair } from '@libp2p/crypto/keys'
  * - Some addresses may be ambiguous. For example, addresses on a private subnet are valid within that subnet but are useless on the public internet.
  * - Once all these pieces are in place, we will also need a way to prioritize addresses based on their authenticity, that is, the dialer can prioritize self-certified addresses over addresses from an unknown origin.
  * - Modular dialer? (taken from go PR notes)
- *     - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritise dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
+ *     - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritize dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
  *     - Multiple parallel dials. We already have the issue where new addresses aren't added to existing dials.
  */
 export { RecordEnvelope } from './envelope/index.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@libp2p/peer-record",
-  "version": "8.0.20-e7e01f58f",
+  "version": "8.0.20-f465c5473",
   "description": "Used to transfer signed peer data across the network",
   "license": "Apache-2.0 OR MIT",
   "homepage": "https://github.com/libp2p/js-libp2p/tree/main/packages/peer-record#readme",
@@ -61,10 +61,10 @@
     "test:electron-main": "aegir test -t electron-main"
   },
   "dependencies": {
-    "@libp2p/crypto": "5.0.12-e7e01f58f",
-    "@libp2p/interface": "2.6.0-e7e01f58f",
-    "@libp2p/peer-id": "5.0.13-e7e01f58f",
-    "@libp2p/utils": "6.5.4-e7e01f58f",
+    "@libp2p/crypto": "5.0.12-f465c5473",
+    "@libp2p/interface": "2.6.0-f465c5473",
+    "@libp2p/peer-id": "5.0.13-f465c5473",
+    "@libp2p/utils": "6.5.4-f465c5473",
     "@multiformats/multiaddr": "^12.3.3",
     "multiformats": "^13.3.1",
     "protons-runtime": "^5.5.0",

package/src/envelope/index.ts

@@ -54,8 +54,8 @@ export class RecordEnvelope implements Envelope {
   }
 
   /**
-   * Open and certify a given marshalled envelope.
-   * Data is unmarshalled and the signature validated for the given domain.
+   * Open and certify a given marshaled envelope.
+   * Data is unmarshaled and the signature validated for the given domain.
    */
   static openAndCertify = async (data: Uint8Array | Uint8ArrayList, domain: string): Promise<RecordEnvelope> => {
     const envelope = await RecordEnvelope.createFromProtobuf(data)

package/src/index.ts

@@ -103,9 +103,9 @@ import { generateKeyPair } from '@libp2p/crypto/keys'
  *
  * ### Subsystem receiving a record
  *
- * Considering that a node can discover other peers' addresses from a variety of sources, Libp2p Peerstore can differentiate the addresses that were obtained through a signed peer record.
+ * Considering that a node can discover other peers' addresses from a variety of sources, Libp2p PeerStore can differentiate the addresses that were obtained through a signed peer record.
  *
- * Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshalled so that we can quickly compare it against incoming records to determine the most recent record.
+ * Once a record is received and its signature properly validated, its envelope is stored in the AddressBook in its byte representation. The `seqNumber` remains unmarshaled so that we can quickly compare it against incoming records to determine the most recent record.
  *
  * The AddressBook Addresses will be updated with the content of the envelope with a certified property. This allows other subsystems to identify the known certified addresses of a peer.
  *
@@ -123,7 +123,7 @@ import { generateKeyPair } from '@libp2p/crypto/keys'
  * - Some addresses may be ambiguous. For example, addresses on a private subnet are valid within that subnet but are useless on the public internet.
  * - Once all these pieces are in place, we will also need a way to prioritize addresses based on their authenticity, that is, the dialer can prioritize self-certified addresses over addresses from an unknown origin.
  * - Modular dialer? (taken from go PR notes)
- *     - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritise dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
+ *     - With the modular dialer, users should easily be able to configure precedence. With dialer v1, anything we do to prioritize dials is gonna be spaghetti and adhoc. With the modular dialer, you’d be able to specify the order of dials when instantiating the pipeline.
  *     - Multiple parallel dials. We already have the issue where new addresses aren't added to existing dials.
  */