chore: understand how to map dns fleets for custom pubsub topics

[danisharora099]

This is a change request

Problem

We currently either use the wakuv2.test fleet which runs DefaultPubsubTopic or the waku.sandbox fleet which runs TWN nodes.

We have no way to default bootstrap into the network for a custom pubsub topic.

Proposed Solutions

Understand if this is even needed.

If not, remove ability to defaultBootstrap on a custom pubsub topic that isn't either:

• DefaultPubsubTopic
• TWN

Notes

• related to https://github.com/waku-org/js-waku/compare/feat/map-correct-fleet?expand=1

[weboko]

Let's approach it from user flows that we can anticipate:

• basic flow: user provides contentTopics and uses TWN;
• basic flow(old but supported): usage of defaultPubsubTopic and any contentTopic;
• sophisticated user: custom pubsubTopics with provided discovery nodes;

Based on that currently we support custom pubsub topics or default pubsub topics.
To me it seems that if a consumer wants to use custom - then there is no reason for them to use our default.

I propose to close this issue as there is no clear deliverable on it. @danisharora099

@LordGhostX can you, please, help understand if we have documented a way for user to uses custom pubsub topics?

@vpavlin do you have more insight into this? Precisely, if someone would need to use custom and default pubsub topics at the same time?

[LordGhostX]

@weboko there's a PR for the docs showing how to use custom shard info with @waku/sdk: waku-org/docs.waku.org#193

[vpavlin]

Let me ask this - what is the difference between custom and default pubsub topics? Apart from "until js-waku works with TWN, we need to fallback to something else (particula default topic which has a fleet backing it).

Speaking of defaultBootstrap though - a user using custom pubsub might still want to leverage the default bootstrap for discovery (@jm-clius or not?) as the Metadata protocol and cluster-id is what should distinguish actual "clusters", but the discovery might be common across all/multiple clusters.

Althought I am also not sure this applies fully to js-waku since the peer discovery is limited to DNS (i.e. would be better for custom cluster to have their own enrtree) and peer-exchange (will TWN nodes give me non-TWN peers over peer-exchange?)

[jm-clius]

might still want to leverage the default bootstrap for discovery (@jm-clius or not?)

In theory, yes, although often bootstrap nodes themselves would filter entries from their discv5 routing table for pubsub topics that they do not subscribe to themselves. However, this is a configuration not a principle - the discovery network is independent from the pubsub topic networks and can be shared.

[danisharora099]

what is the difference between custom and default pubsub topics? Apart from "until js-waku works with TWN, we need to fallback to something else (particula default topic which has a fleet backing it).

difference I see is: we have a way to bootstrap into the network because we run nodes on DefaultPubsubTopic. Doing defaultBootstrap on a random pubsub topic won't find any nodes. But perhaps that's expected then.

[danisharora099]

Based on that currently we support custom pubsub topics or default pubsub topics.
To me it seems that if a consumer wants to use custom - then there is no reason for them to use our default.

I propose to close this issue as there is no clear deliverable on it.

Sounds good to me!