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
To maintain adherence to the sharded format, the lightpush client API should be updated.
New proposed format: lightPublish(WakuMessage, ClusterID, ShardNumber)
For legacy requests on named topics, the API could use a trial and error process to send the request to random service nodes.
This can be done using the format: lightPublish(WakuMessage, PubsubTopic)
A request format that bypasses our peer management/selection: lightPublish(WakuMessage, PubsubTopic, ServiceNodeMultiaddr)
Acceptance criteria
Introduce the new lightpush client API as mentioned above.
Update documentation to reflect these changes and guide users accordingly.
The text was updated successfully, but these errors were encountered:
feat: Deprecate Named Sharding and Update Lightpush Client API #2163
Ooh, thank you! Not sure if this is still relevant, I just separated the 3 points in #2163 into 3 different issues. I agree this should be considered as part of waku-org/pm#93 , whether applied or discarded.
@NagyZoltanPeter@gabrielmer - I 💯 agree with you both. Given that we are starting to decommission the pubsub topic concept, I think is great to stick only to the cluster+shards terms :)
Background
To maintain adherence to the sharded format, the lightpush client API should be updated.
New proposed format:
lightPublish(WakuMessage, ClusterID, ShardNumber)
For legacy requests on named topics, the API could use a trial and error process to send the request to random service nodes.
This can be done using the format:
lightPublish(WakuMessage, PubsubTopic)
A request format that bypasses our peer management/selection:
lightPublish(WakuMessage, PubsubTopic, ServiceNodeMultiaddr)
Acceptance criteria
The text was updated successfully, but these errors were encountered: