-
Notifications
You must be signed in to change notification settings - Fork 3
chore: waku sync full topic support #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
jm-clius
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Comment to address before merging below - we have to be explicit about "topic" as being pubsub topic, content topic or both. Suggestion is to limit spec only to behaviour for pubsub topic, which will allow it to undergo full testing and QA separately to reach draft status while we experiment with content topics in parallel (which IIUC may necessitate more comprehensive storage changes).
Ivansete-status
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for it!
I think we should avoid using the term pubsub outside the nwaku codebase.
From API pov, I'd only use these terms:
- timestamp
- cluster-id
- shard
- content-topic
Co-authored-by: Ivan FB <[email protected]>
I don't have strong opinions here we can either;
I think @jm-clius want the spec to be agnostic to network definitions? |
Most of our core level specs use |
I'm lazy and I don't want to change it back to shard again so I'll leave it like this. |
|
I removed cluster and left only pubsub and content topics |
update to the Waku sync spec to include full topic support.