logos-messaging/docs.waku.org
1
0
Fork 0
mirror of https://github.com/logos-messaging/docs.waku.org.git synced 2026-01-03 21:33:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

overhaul content topics

Browse Source
This commit is contained in:
LordGhostX 2023-05-14 14:23:15 +01:00
parent d117ca5375
commit 66c8a05e7b
No known key found for this signature in database
GPG Key ID: 520CC5DC4F94FCC7
3 changed files with 15 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/overview/concepts/content-topics.md
View File

@ -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, 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.
both when receiving live messages (Relay or Filter) or retrieving historical messages (Store).
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. `/{application-name}/{version}/{content-topic-name}/{encoding}`
- `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`.
For example: Your dApp's name is SuperCrypto, - `application-name`: This is the unique name of your decentralized application (dApp) to prevent conflicts with other dApps.
it enables users to receive notifications and send private messages. - `version`: Typically starting at 1, this field helps track breaking changes in your messages.
You may want to use the following content topics: - `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/notification/proto`
- `/supercrypto/1/private-message/proto` - `/supercrypto/1/private-message/proto`

2
docs/overview/concepts/network-domains.md
View File

@ -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. 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. 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. 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. 4. Node D, upon receiving `msg1`, stores the message in its store for possible later retrieval by other nodes.

4
docs/overview/concepts/transports.md
View File

@ -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. - 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. - 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.
:::