feat: lightpush & filter send requests to multiple peers #1779
Conversation
| ): Subscription | undefined { | ||
| return this.activeSubscriptions.get(`${pubsubTopic}_${peerIdStr}`); | ||
| return this.activeSubscriptions.get(pubsubTopic); |
There was a problem hiding this comment.
peerIdStr isn't required to be maintained as each Subscription object already corresponds to only one pubsub topic
There was a problem hiding this comment.
information about the peers used for that protocol exist within the Subscription object, which, if necessary, can be accessed as a readonly property.
size-limit report 📦
|
danisharora099
force-pushed
the
feat/redundant-sdk
branch
from
931ef57
to
00e6703
Compare
…aku into feat/redundant-sdk
…e node and message collector with redundancy accounted for
danisharora099
force-pushed
the
feat/redundant-sdk
branch
from
60d676b
to
f2e66a6
Compare
danisharora099
force-pushed
the
feat/redundant-sdk
branch
from
dbb551c
to
c0b89ac
Compare
| @@ -24,6 +24,7 @@ import { StreamManager } from "./stream_manager.js"; | |||
| export class BaseProtocol implements IBaseProtocol { | |||
| public readonly addLibp2pEventListener: Libp2p["addEventListener"]; | |||
| public readonly removeLibp2pEventListener: Libp2p["removeEventListener"]; | |||
| readonly NUM_PEERS_TO_USE = 3; | |||
There was a problem hiding this comment.
Why is it not configurable?
There was a problem hiding this comment.
good point. made it configurable!
| @@ -27,3 +27,12 @@ export function messageHash( | |||
| } | |||
| return sha256(bytes); | |||
| } | |||
|
|
|||
| export function messageHashStr( | |||
There was a problem hiding this comment.
I don't remember why this package was created but as I see it contains only one function.
Considering how it is used it can be safely moved to core and re-exported from sdk.
@waku-org/js-waku-developers wdyt?
There was a problem hiding this comment.
Maybe because it depends on @noble/hashes. But @waku/core already relies on the same as well. So perhaps a good idea to move it into @waku/core.
PR here to move this: #1810 where we can also continue this discussion if required.
Problem
Currently for LightPush & Filter, we send requests only to 1 peer. This is not ideal as we want to increase decentralisation & reliability for our SDK. Reference issue: #1463
Solution
This PR, addressing #1463 partly, sends LightPush & Filter requests to multiple peers, defined as a constant in
BaseProtocol.Notes
ServiceNodeswrapper class forServiceNodeandMessageCollectorand provides helpers to account for redundancy in the latter