feat: lift contentTopics and make shardInfo mandatory for createLight… #1959
Conversation
size-limit report 📦
|
…ku into weboko/content-topic-node
| * If not provided pubsubTopics will be determined based on shardInfo | ||
| * See [Waku v2 Topic Usage Recommendations](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md) for details. | ||
| */ | ||
| contentTopics?: string[]; |
There was a problem hiding this comment.
A follow up to this PR will be:
- deprecate or find better way of handling
pubsubTopicsparameter; - refine public API of it;
- set default values to TWN fleet;
- drop custom pubsubTopic support (also remove
DefaultPubsubTopicfrom codebase and useDefaultShardInfo);
Will decouple into an issue.
packages/sdk/src/light-node/index.ts
Outdated
| @@ -41,6 +16,10 @@ export async function createNode( | |||
| export async function createLightNode( | |||
| options: CreateWakuNodeOptions = {} | |||
| ): Promise<LightNode> { | |||
| if (!options.shardInfo || !options.contentTopics) { | |||
| throw new Error("Shard info must be set"); | |||
There was a problem hiding this comment.
What if I am running on non-TWN network/pubsub? Does it mean that I need to provide contentTopics on the node creation time?
What I do in Qaku is I accept lightNode as a parameter for waku-dispatcher and only re-create the dispatcher instance (which needs to know the contentTopic to create encoder/decoder), but keep the node to speed up switching between Q&As
The need to provide contentTopic on node creation completely breaks this and I'd have to either provide some dummy contentTopic or re-create node on each Q&A switch, which would slow down the loading.
I understand this is necessary to be able to discover the right nodes supporting the right shards, but not sure if it will be practical for the apps.
There was a problem hiding this comment.
@vpavlin are all the content topics for qwaku known beforehand or are they created dynamically? Either way, if you use the same application and version for all of them, then you shouldn't need to recreate the the node each time so long as you provide a dummy content topic at node creation.
There was a problem hiding this comment.
What if I am running on non-TWN network/pubsub
js-waku is moving towards dropping custom pubsub topics
if non-TWN can be described with ShardInfo - then it can passed just as is and should work, otherwise it won't be supported
note that not in this PR - I returned ability to run node with array of pubsubTopics but it will be removed next release
let's discuss if you think that we should handle it differently
as @adklempner mentioned you can pass different content topics that will resolve to the same shard - this can be ensured as per spec
weboko
changed the title
Problem
End consumers might not want to understand the concept of sharding and wouldn't want to read the types.
Solution
Lift
contentTopicsoption so that consumers just care about supplying a bunch of strings.Notes
Additionally resolved #1980