You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 26, 2023. It is now read-only.
@@ -49,7 +52,7 @@ You can check the following implementations as examples for building your own pu
49
52
50
53
## Interface usage
51
54
52
-
`interface-pubsub` abstracts the implementation protocol registration within `libp2p` and takes care of all the protocol connections and streams, as well as the subscription management. This way, a pubsub implementation can focus on its message routing algorithm, instead of also needing to create the setup for it.
55
+
`interface-pubsub` abstracts the implementation protocol registration within `libp2p` and takes care of all the protocol connections and streams, as well as the subscription management and the features describe in the libp2p [pubsub specs](https://github.com/libp2p/specs/tree/master/pubsub). This way, a pubsub implementation can focus on its message routing algorithm, instead of also needing to create the setup for it.
53
56
54
57
### Extend interface
55
58
@@ -74,16 +77,15 @@ All the remaining functions **MUST NOT** be overwritten.
74
77
The following example aims to show how to create your pubsub implementation extending this base protocol. The pubsub implementation will handle the subscriptions logic.
@@ -98,6 +100,23 @@ class PubsubImplementation extends Pubsub {
98
100
99
101
The interface aims to specify a common interface that all pubsub router implementation should follow. A pubsub router implementation should extend the [EventEmitter](https://nodejs.org/api/events.html#events_class_eventemitter). When peers receive pubsub messages, these messages will be emitted by the event emitter where the `eventName` will be the `topic` associated with the message.
100
102
103
+
### Constructor
104
+
105
+
The base class constructor configures the pubsub instance for use with a libp2p instance. It includes settings for logging, signature policies, etc.
106
+
107
+
#### `new Pubsub({options})`
108
+
109
+
##### Parameters
110
+
111
+
| Name | Type | Description | Default |
112
+
|------|------|-------------|---------|
113
+
| options.libp2p |`Libp2p`| libp2p instance | required, no default |
114
+
| options.debugName |`string`| log namespace | required, no default |
| options.globalSignaturePolicy |`'StrictSign' \| 'StrictNoSign'`| signature policy to be globally applied |`'StrictSign'`|
117
+
| options.canRelayMessage |`boolean`| if can relay messages if not subscribed |`false`|
118
+
| options.emitSelf |`boolean`| if `publish` should emit to self, if subscribed |`false`|
119
+
101
120
### Start
102
121
103
122
Starts the pubsub subsystem. The protocol will be registered to `libp2p`, which will result in pubsub being notified when peers who support the protocol connect/disconnect to `libp2p`.
@@ -185,7 +204,7 @@ Get a list of the [PeerId](https://github.com/libp2p/js-peer-id) strings that ar
185
204
186
205
### Validate
187
206
188
-
Validates the signature of a message.
207
+
Validates a message according to the signature policy and topic-specific validation function.
* Details how message signatures are produced/consumed
6
+
*/
7
+
exports.SignaturePolicy={
8
+
/**
9
+
* On the producing side:
10
+
* * Build messages with the signature, key (from may be enough for certain inlineable public key types), from and seqno fields.
11
+
*
12
+
* On the consuming side:
13
+
* * Enforce the fields to be present, reject otherwise.
14
+
* * Propagate only if the fields are valid and signature can be verified, reject otherwise.
15
+
*/
16
+
StrictSign: 'StrictSign',
17
+
/**
18
+
* On the producing side:
19
+
* * Build messages without the signature, key, from and seqno fields.
20
+
* * The corresponding protobuf key-value pairs are absent from the marshalled message, not just empty.
21
+
*
22
+
* On the consuming side:
23
+
* * Enforce the fields to be absent, reject otherwise.
24
+
* * Propagate only if the fields are absent, reject otherwise.
25
+
* * A message_id function will not be able to use the above fields, and should instead rely on the data field. A commonplace strategy is to calculate a hash.
0 commit comments