overhaul content topics
This commit is contained in:
parent
d117ca5375
commit
66c8a05e7b
|
@ -1,24 +1,21 @@
|
|||
---
|
||||
title: Content Topic and How to Choose One
|
||||
title: Content Topics
|
||||
---
|
||||
|
||||
A content topic is used for content based filtering and allows you to filter out the messages that your dApp processes,
|
||||
both when receiving live messages (Relay or Filter) or retrieving historical messages (Store).
|
||||
Content topics optimize node bandwidth usage by filtering messages based on specific topics of interest. They enable dApps to selectively process incoming live messages (`Relay` or `Filter`) and retrieve historical messages (`Store`) that match their filtering criteria. For more information, please refer to the [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23/#content-topics) specification.
|
||||
|
||||
The recommended format for content topics is as follows:
|
||||
## Content Topic Format
|
||||
|
||||
`/{dapp-name}/{version}/{content-topic-name}/{encoding}`
|
||||
Here is the recommended format for content topics:
|
||||
|
||||
- `dapp-name`: The name of your dApp, it must be unique to avoid conflict with other dApps.
|
||||
- `version`: We usually start at `1`, useful when introducing breaking changes in your messages.
|
||||
- `content-topic-name`: The actual content topic name to use for filtering.
|
||||
If your dApp uses Waku for several features,
|
||||
you should use a content topic per feature.
|
||||
- `encoding`: The encoding format of the message, [Protobuf](https://developers.google.com/protocol-buffers) is most often used: `proto`.
|
||||
`/{application-name}/{version}/{content-topic-name}/{encoding}`
|
||||
|
||||
For example: Your dApp's name is SuperCrypto,
|
||||
it enables users to receive notifications and send private messages.
|
||||
You may want to use the following content topics:
|
||||
- `application-name`: This is the unique name of your decentralized application (dApp) to prevent conflicts with other dApps.
|
||||
- `version`: Typically starting at 1, this field helps track breaking changes in your messages.
|
||||
- `content-topic-name`: The specific name of the content topic used for filtering. If your dApp utilizes Waku for multiple features, it is advisable to have a separate content topic for each feature.
|
||||
- `encoding`: The message encoding format, with [Protobuf](https://developers.google.com/protocol-buffers) (`proto`) being the commonly used choice.
|
||||
|
||||
For instance, if your dApp is called `SuperCrypto` and it allows users to receive notifications and send private messages, you can consider utilizing the following content topics:
|
||||
|
||||
- `/supercrypto/1/notification/proto`
|
||||
- `/supercrypto/1/private-message/proto`
|
||||
|
|
|
@ -47,7 +47,7 @@ D ->> E: HistoryResponse(msg1, ...) (6)
|
|||
|
||||
The Publish/Subscribe topic `pubtopic1` serves as a means of routing messages (the network employs a default pub-sub topic) and indicates that it is subscribed to messages on that topic for a relay. In the context of Waku Store, Node D is responsible for persisting these messages.
|
||||
|
||||
1. Node A creates a WakuMessage `msg1` with a ContentTopic `contentTopic1`.
|
||||
1. Node A creates a WakuMessage `msg1` with a [ContentTopic](/overview/concepts/content-topics) `contentTopic1`.
|
||||
2. Node F requests to get messages filtered by Pub/Sub topic `pubtopic1` and ContentTopic `contentTopic1`. Node D subscribes F to this filter and will forward messages that match that filter in the future.
|
||||
3. Node A publishes `msg1` on `pubtopic1`. The message is sent from Node A to Node B and then forwarded to Node D.
|
||||
4. Node D, upon receiving `msg1`, stores the message in its store for possible later retrieval by other nodes.
|
||||
|
|
|
@ -10,4 +10,6 @@ The recommended transports for Waku nodes are as follows:
|
|||
- Secure WebSocket: In browser environments, secure WebSocket is used. Service nodes are encouraged to set up SSL certificates to enable incoming connections from browsers and serve them securely.
|
||||
- Other protocols like [WebRTC](https://github.com/waku-org/js-waku/issues/20), [WebTransport](https://github.com/waku-org/js-waku/issues/697), and QUIC have been investigated and studied for potential integration.
|
||||
|
||||
Waku ensures compatibility and enhanced communication capabilities among nodes by adhering to these recommended transports.
|
||||
:::note
|
||||
Waku ensures compatibility and enhanced communication capabilities among nodes by adhering to these recommended transports.
|
||||
:::
|
Loading…
Reference in New Issue