diff --git a/status/raw/status-app-protocols.md b/status/raw/status-app-protocols.md new file mode 100644 index 00000000..14d09d22 --- /dev/null +++ b/status/raw/status-app-protocols.md @@ -0,0 +1,409 @@ +--- +title: STATUS-PROTOCOLS +name: Status Protocol Stack +status: raw +category: Standards Track +description: Specifies the Status application protocol stack. +editor: Hanno Cornelius +contributors: +- Jimmy Debe +- Aaryamann Challani + +--- + +## Abstract + +This specification describes the Status Application protocol stack. +It focuses on elements and features in the protocol stack for all application-level functions: + +- functional scope (also _broadcast audience_) +- content topic +- ephemerality +- end-to-end reliability layer +- encryption layer +- transport layer (Waku) + +It also introduces strategies to restrict resource usage, distribute large messages, etc. +Application-level functions are out of scope and specified separately. See: + +- [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) +- [56/STATUS-COMMUNITIES](../56/communities.md) + +## Status protocol stack + +The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, +“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and +“OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt). +See the simplified diagram of the Status application protocol stack: + +| | +|---| +| Status application layer | +| End-to-end reliability layer | +| Encryption layer | +| Transport layer (Waku) | +| | + +## Status application layer + +Application level functions are defined in the _application_ layer. +Status currently defines functionality to support three main application features: + +- Status Communities, as specified in [56/STATUS-COMMUNITIES](../56/communities.md) +- Status 1:1 Chat, as specified in [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) +- Status Private Group Chat, as specified in a subsection of [55/STATUS-1TO1-CHAT](../55/1to1-chat.md#negotiation-of-a-11-chat-amongst-multiple-participants-group-chat) + + + +Each application-level function, regardless which feature set it supports, has the following properties: + +1. Functional scope +1. Content topic +1. Ephemerality + +### Functional Scope + +Each Status app-level message MUST define a functional scope. +The functional scope MUST define the _minimum_ scope of the audience that should _participate_ in the app function the message is related to. +In other words, it determines the minimum subset of Status app participants +that should have access to messages related to that function. + +Note that the functional scope is distinct from the number of participants that is _addressed_ by a specific message. +For example, a participant will address a 1:1 chat to only one other participant. +However, since all users of the Status app MUST be able to participate in 1:1 chats, +the functional scope of messages enabling 1:1 chats MUST be a global scope. +Similarly, since private group chats can be set up between any subset of Status app users, +the functional scope for messages related to private group chats MUST be global. +As a counter-example, messages that originate within a community (and are _addressed_ to members of that community) +are only of interest to participants that are also members of that community. +Such messages MUST have a community-wide functional scope. +A third group of messages are addressed only to the participant that generated those messages itself. +These _self-addressed_ messages MUST have a local functional scope. + +If we further make a distinction between "control" and "content" messages, +we can distinguish five distinct functional scopes. + +All Status messages MUST have one of these functional scopes: + +#### Global scope + +1. _Global control_: messages enabling the basic functioning of the app to control features that all app users should be able to participate in. Examples include Contact Requests, Community Invites, global Status Updates, Group Chat Invites, etc. +2. _Global content_: messages carrying user-generated content for global functions. Examples include 1:1 chat messages, images shared over private group chats, etc. + +#### Community scope + +3. _Community control_: messages enabling the basic functioning of the app to control features _only relevant to members of a specific community_. Examples include Community Membership Updates, community Status Updates, etc. +4. _Community content_: messages carrying user-generated content _only for members of a specific community_. + +#### Local scope + +5. _Local_: messages related to functions that are only relevant to a single user. Also known as _self-addressed messages_. Examples include messages used to exchange information between app installations, such as User Backup and Sync messages. + +Note that the functional scope is a logical property of Status messages. +It SHOULD however inform the underlying [transport layer sharding](#pubsub-topics-and-sharding) and [transport layer subscriptions](#subscribing). +In general a Status client SHOULD subscribe to participate in: +- all global functions, +- (only) the community functions for communities of which it is a member, and +- its own local functions. + +### Content topics + +Each Status app-level message MUST define a content topic that links messages in related app-level functions and sub-functions together. +This MUST be based on the filter use cases for [transport layer subscriptions](#subscribing) +and [retrieving historical messages](#retrieving-historical-messages). +A content topic SHOULD be identical across all messages that are always part of the same filter use case (or always form part of the same content-filtered query criteria). +In other words, the number of content topics defined in the app SHOULD match the number of filter use cases. +For the sake of illustration, consider the following common content topic and filter use cases: + +- if all messages belonging to the same 1:1 chat are always filtered together, they SHOULD use the same content topic (see [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)) +- if all messages belonging to the same Community are always filtered together, they SHOULD use the same content topic (see [56/STATUS-COMMUNITIES](../56/communities.md)). + +The app-level content topic MUST be populated in the `content_topic` field in the encapsulating Waku message (see [Waku messages](#waku-messages)). + +### Ephemerality + +Each Status app-level message MUST define its _ephemerality_. +Ephemerality is a boolean value, set to `true` if a message is considered ephemeral. +Ephemeral messages are messages emitted by the app that are transient in nature. +They only have temporary "real-time" value +and SHOULD NOT be stored and retrievable from historical message stores and sync caches. +Similarly, ephemeral message delivery is best-effort in nature and SHOULD NOT be considered in message reliability mechanisms (see [End-to-end reliability layer](#end-to-end-reliability-layer)). + +An example of ephemeral messages would be periodic status update messages, indicating a particular user's online status. +Since only a user's current online status is of value, there is no need to store historical status update messages. +Since status updates are periodic, there is no strong need for end-to-end reliability as subsequent updates are always to follow. + +App-level messages that are considered ephemeral, MUST set the `ephemeral` field in the encapsulating Waku message to `true` (see [Waku messages](#waku-messages)) + +## End-to-end reliability layer + +The end-to-end reliability layer contains the functions related to one of the two end-to-end reliability schemes defined for Status app messages: + +1. Minimum Viable protocol for Data Synchronisation, or MVDS (see [STATUS-MVDS-USAGE](./status-mvds.md)) +1. Scalable distributed log reliability (spec and a punchier name TBD, see the [original forum post announcement](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16)) + +Ephemeral messages SHOULD omit this layer. +Non-ephemeral 1:1 chat messages SHOULD make use of MVDS to achieve reliable data synchronisation between the two parties involved in the communication. +Non-ephemeral private group chat messages build on a set of 1:1 chat links +and consequently SHOULD also make use of MVDS to achieve reliable data synchronisation between all parties involved in the communication. +Non-ephemeral 1:1 and private group chat messages MAY make use of of [scalable distributed log reliability](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16) in future. +Since MVDS does not scale for large number of participants in the communication, +non-ephemeral community messages MUST use scalable distributed log reliability as defined in this [original forum post announcement](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16). +The app MUST use a single channel ID per community. + +## Encryption layer + +The encryption layer wraps the Status App and Reliability layers in an encrypted payload. + + + +## Waku transport layer + +The Waku transport layer contains the functions allowing Status protocols to use [10/WAKU2](../../waku/standards/core/10/waku2.md) infrastructure as transport. + +### Waku messages + +Each Status application message MUST be transformed to a [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md) with the following structure: + +```protobuf +syntax = "proto3"; + +message WakuMessage { + bytes payload = 1; + string content_topic = 2; + optional uint32 version = 3; + optional sint64 timestamp = 10; + optional bytes meta = 11; + optional bool ephemeral = 31; +} +``` + +- `payload` MUST be set to the full encrypted payload received from the higher layers +- `version` MUST be set to `1` +- `ephemeral` MUST be set to `true` if the app-level message is ephemeral +- `content_topic` MUST be set to the app-level content topic +- `timestamp` MUST be set to the current Unix epoch timestamp (in nanosecond precision) + +### Pubsub topics and sharding + +All Waku messages are published to pubsub topics as defined in [23/WAKU2-TOPICS](../../waku/informational/23/topics.md). +Since pubsub topics define a routing layer for messages, +they can be used to shard traffic. +The pubsub topic used for publishing a message depends on the app-level [functional scope](#functional-scope). + +#### Self-addressed messages + +The application MUST define at least one distinct pubsub topic for self-addressed messages. +The application MAY define a set of more than one pubsub topic for self-addressed messages to allow traffic sharding for scalability. + +#### Global messages + +The application MUST define at least one distinct pubsub topic for global control messages and global content messages. +The application MAY defined a set of more than one pubsub topic for global messages to allow traffic sharding for scalability. +It is RECOMMENDED that separate pubsub topics be used for global control messages and global content messages. + +#### Community messages + +The application SHOULD define at least one separate pubsub topic for each separate community's control and content messages. +The application MAY define a set of more than one pubsub topic per community to allow traffic sharding for scalability. +It is RECOMMENDED that separate pubsub topics be used for community control messages and community content messages. + +#### Large messages + +The application MAY define separate pubsub topics for large messages. +These pubsub topics for large messages MAY be distinct for each functional scope. + +### Resource usage + +The application SHOULD use a range of Waku protocols to interact with the Waku transport layer. +The specific set of Waku protocols used depend on desired functionality and resource usage profile for the specific client. +Resources can be restricted in terms of bandwidth and computing resources. + +Waku protocols that are more appropriate for resource-restricted environments are often termed "light protocols". +Waku protocols that consume more resources, but simultaneously contribute more to Waku infrastructure, are often termed "full protocols". +The terms "full" and "light" is just a useful abstraction than a strict binary, though, +and Status clients can operate along a continuum of resource usage profiles, +each using the combination of "full" and "light" protocols most appropriate to match its environment and motivations. + +To simplify interaction with the selection of "full" and "light" protocols, +Status clients MUST define a "full mode" and "light mode" +to allow users to select whether their client would prefer "full protocols" or "light protocols" by default. +Status Desktop clients are assumed to have more resources available and SHOULD use full mode by default. +Status Mobile clients are assumed to operate with more resource restrictions and SHOULD use light mode by default. + +For the purposes of the rest of this document, +clients in full mode will be referred to as "full clients" and +clients in light mode will be referred to as "light clients". + +### Discovery + +The application MUST make use of at least one discovery method to discover and connect to Waku peers +useful for the user functions specific to that instance of the application. + +The specific Waku discovery protocol used for discovery depends on the use case and resource-availability of the client. + +1. [EIP-1459: DNS-based discovery](https://eips.ethereum.org/EIPS/eip-1459) is useful for initial connection to bootstrap peers. +1. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) allows decentralized discovery of Waku peers. +1. [34/WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md) allows requesting peers from a service node +and is appropriate for resource-restricted discovery. + +All clients SHOULD use DNS-based discovery on startup +to discover a set of bootstrap peers for initial connection. + +Full clients SHOULD use [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) for continuous ambient peer discovery. + +Light clients SHOULD use [34/WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md) to discover a set of service peers +used by that instance of the application. + +### Subscribing + +The application MUST subscribe to receive the traffic necessary for minimal app operation +and to enable the user functions specific to that instance of the application. + +The specific Waku protocol used for subscription depends on the resource-availability of the client: + +1. Filter client protocol, as specified in [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md), allows subscribing for traffic with content topic granularity and is appropriate for resource-restricted subscriptions. +1. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows subscribing to traffic only with pubsub topic granularity and therefore is more resource-intensive. Relay subscription also allows the application instance to contribute to the overall routing infrastructure, which adds to its overall higher resource usage but benefits the ecosystem. + +Full clients SHOULD use relay protocol as preferred method to subscribe to pubsub topics matching the scopes: + +1. Global control +1. Global content +1. Community control, for each community of which the app user is a member +1. Community content, for each community of which the app user is a member + +Light clients SHOULD use filter protocol to subscribe only to the content topics relevant to the user. + +#### Self-addressed messages + +Status clients (full or light) MUST NOT subscribe to topics for messages with self-addressed scopes. +See [Self-addressed messages](#self-addressed-messages-4). + +#### Large messages + +Status clients (full or light) SHOULD NOT subscribe to topics set aside for large messages. +See [Large messages](#large-messages-4). + +### Publishing + +The application MUST publish user and app generated messages via the Waku transport layer. +The specific Waku protocol used for publishing depends on the resource-availability of the client: + +1. Lightpush protocol, as specified in [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) allows publishing to a pubsub topic via an intermediate "full node" and is more appropriate for resource-restricted publishing. +1. Relay protocol, as specified in [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md), allows publishing directly into the relay routing network and is therefore more resource-intensive. + +Full clients SHOULD use relay protocol to publish to pubsub topics matching the scopes: + +1. Global control +1. Global content +1. Community control, for each community of which the app user is a member +1. Community content, for each community of which the app user is a member + +Light clients SHOULD use lightpush protocol to publish control and content messages. + +#### Self-addressed messages + +Status clients (full or light) MUST use lightpush protocol to publish self-addressed messages. +See [Self-addressed messages](#self-addressed-messages-4). + +#### Large messages + +Status clients (full or light) SHOULD use lightpush protocols to publish to pubsub topics set aside for large messages. +See [Large messages](#large-messages-4). + +### Retrieving historical messages + +Status clients SHOULD use the store query protocol, as specified in [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md), to retrieve historical messages relevant to the client from store service nodes in the network. + +Status clients SHOULD use [content filtered queries](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md#content-filtered-queries) with `include_data` set to `true`, +to retrieve the full contents of historical messages that the client may have missed during offline periods, +or to populate the local message database when the client starts up for the first time. + +#### Store queries for reliability + +Status clients MAY use periodic content filtered queries with `include_data` set to `false`, +to retrieve only the message hashes of past messages on content topics relevant to the client. +This can be used to compare the hashes available in the local message database with the hashes in the query response +in order to identify possible missing messages. +Once the Status client has identified a set of missing message hashes +it SHOULD use [message hash lookup queries](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md#message-hash-lookup-queries) with `include_data` set to `true` +to retrieve the full contents of the missing messages based on the hash. + +Status clients MAY use [presence queries](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md#presence-queries) +to determine if one or more message hashes known to the client is present in the store service node. +Clients MAY use this method to determine if a message that originated from the client +has been successfully stored. + +#### Self-addressed messages + +Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve self-addressed messages relevant to that client. +See [Self-addressed messages](#self-addressed-messages-4). + +#### Large messages + +Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve large messages relevant to that client. +See [Large messages](#large-messages-4). + +### Providing services + +Status clients MAY provide service-side protocols to other clients. + +Full clients SHOULD mount +the filter service protocol (see [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)) +and lightpush service protocol (see [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md)) +in order to provide light subscription and publishing services to other clients +for each pubsub topic to which they have a relay subscription. + +Full clients SHOULD mount +the peer exchange service protocol (see [34/WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/315264c202e0973476e2f1e2d0b01bea4fe1ad31/standards/core/peer-exchange.md)) +to provide light discovery services to other clients. + +Status clients MAY mount the store query protocol as service node (see [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md)) +to store historical messages and +provide store services to other clients +for each pubsub topic to which they have a relay subscription + +### Self-addressed messages + +Messages with a _local_ functional scope (see [Functional scope](#functional-scope)), +also known as _self-addressed_ messages, +MUST be published to a distinct pubsub topic or a distinct _set_ of pubsub topics +used exclusively for messages with local scope (see [Pubsub topics and sharding](#pubsub-topics-and-sharding)). +Status clients (full or light) MUST use lightpush protocol to publish self-addressed messages (see [Publishing](#publishing)). +Status clients (full or light) MUST NOT subscribe to topics for messages with self-addressed scopes (see [Subscribing](#subscribing)). +Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve self-addressed messages relevant to that client (see [Retrieving historical messages](#retrieving-historical-messages)). + +### Large messages + +The application MAY define separate pubsub topics for large messages. +These pubsub topics for large messages MAY be distinct for each functional scope (see [Pubsub topics and sharding](#pubsub-topics-and-sharding)). +Status clients (full or light) SHOULD use lightpush protocols to publish to pubsub topics set aside for large messages (see [Publishing](#publishing)). +Status clients (full or light) SHOULD NOT subscribe to topics set aside for large messages (see [Subscribing](#subscribing)). +Status clients (full or light) SHOULD use store queries (rather than subscriptions) to retrieve large messages relevant to that client (see [Retrieving historical messages](#retrieving-historical-messages)). + +#### Chunking + +The Status application MAY use a chunking mechanism to break down large payloads +into smaller segments for individual Waku transport. +The definition of a large message is up to the application. +However, the maximum size for a [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md) payload is 150KB. +Status application payloads that exceed this size MUST be chunked into smaller pieces +and MUST be considered a "large message". + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References + +1. [55/STATUS-1TO1-CHAT](../55/1to1-chat.md) +1. [56/STATUS-COMMUNITIES](../56/communities.md) +1. [10/WAKU2](../../waku/standards/core/10/waku2.md) +1. [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md) +1. [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md) +1. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md) +1. [23/WAKU2-TOPICS](../../waku/informational/23/topics.md) +1. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) +1. [Scalable distributed log reliability](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16) +1. [STATUS-MVDS-USAGE](./status-mvds.md) +1. [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md) diff --git a/status/raw/status-waku-usage.md b/status/raw/status-waku-usage.md deleted file mode 100644 index 77fad169..00000000 --- a/status/raw/status-waku-usage.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -title: STATUS-WAKU2-USAGE -name: Status Waku2 Usage -status: raw -category: Best Current Practice -description: Defines how the Status application uses the Waku protocols. -editor: Aaryamann Challani -contributors: -- Jimmy Debe - ---- - -## Abstract - -Status is a chat application which has several features, -including, but not limited to - - -- Private 1:1 chats, described by [55/STATUS-1TO1-CHAT](/spec/55) -- Large scale group chats, described by [56/STATUS-COMMUNITIES](/spec/56) - -This specification describes how a Status implementation will make use of -the underlying infrastructure, Waku, -which is described in [10/WAKU2](/spec/10). - -## Background - -The Status application aspires to achieve censorship resistance and -incorporates specific privacy features, -leveraging the comprehensive set of protocols offered by Waku to enhance these attributes. -Waku protocols provide secure communication capabilities over decentralized networks. -Once integrated, an application will benefit from privacy-preserving, -censorship resistance and spam protected communcation. - -Since Status uses a large set of Waku protocols, -it is imperative to describe how each are used. - -## Terminology - -| Name | Description | -| --------------- | --------- | -| `RELAY`| This refers to the Waku Relay protocol, described in [11/WAKU2-RELAY](/spec/11) | -| `FILTER` | This refers to the Waku Filter protocol, described in [12/WAKU2-FILTER](/spec/12) | -| `STORE` | This refers to the Waku Store protocol, described in [13/WAKU2-STORE](/spec/13) | -| `MESSAGE` | This refers to the Waku Message format, described in [14/WAKU2-MESSAGE](/spec/14) | -| `LIGHTPUSH` | This refers to the Waku Lightpush protocol, described in [19/WAKU2-LIGHTPUSH](/spec/19) | -| Discovery | This refers to a peer discovery method used by a Waku node. | -| `Pubsub Topic` / `Content Topic` | This refers to the routing of messages within the Waku network, described in [23/WAKU2-TOPICS](/spec/23/) | - -### Waku Node - -Software that is configured with a set of Waku protocols. -A Status client comprises of a Waku node that is a `RELAY` node or a non-relay node. - -### Light Client - -A Status client that operates within resource constrained environments -is a node configured as light client. -Light clients do not run a `RELAY`. -Instead, Status light clients, -can request services from other `RELAY` node that provide `LIGHTPUSH` service. - -## Protocol Usage - -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, -“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and -“OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). - -The following is a list of Waku Protocols used by a Status application. - -### 1. `RELAY` - -The `RELAY` MUST NOT be used by Status light clients. -The `RELAY` is used to broadcast messages between Status clients. -All Status messages are transformed into [14/WAKU2-MESSAGE](/spec/14), -which are sent over the wire. - -All Status message types are described in [62/STATUS-PAYLOAD](/spec/62). -Status Clients MUST transform the following object into a `MESSAGE` -as described below - - -```go - -type StatusMessage struct { - SymKey[] []byte // [optional] The symmetric key used to encrypt the message - PublicKey []byte // [optional] The public key to use for asymmetric encryption - Sig string // [optional] The private key used to sign the message - PubsubTopic string // The Pubsub topic to publish the message to - ContentTopic string // The Content topic to publish the message to - Payload []byte // A serialized representation of a Status message to be sent - Padding []byte // Padding that must be applied to the Payload - TargetPeer string // [optional] The target recipient of the message - Ephemeral bool // If the message is not to be stored, this is set to `true` -} - -``` - -1. A user MUST only provide either a Symmetric key OR -an Asymmetric keypair to encrypt the message. -If both are received, the implementation MUST throw an error. -2. `WakuMessage.Payload` MUST be set to `StatusMessage.Payload` -3. `WakuMessage.Key` MUST be set to `StatusMessage.SymKey` -4. `WakuMessage.Version` MUST be set to `1` -5. `WakuMessage.Ephemeral` MUST be set to `StatusMessage.Ephemeral` -6. `WakuMessage.ContentTopic` MUST be set to `StatusMessage.ContentTopic` -7. `WakuMessage.Timestamp` MUST be set to the current Unix epoch timestamp -(in nanosecond precision) - -### 2. `STORE` - -This protocol MUST remain optional according to the user's preferences, -it MAY be enabled on Light clients as well. - -Messages received via [11/WAKU2-RELAY](/spec/11), are stored in a database. -When Waku node running this protocol is service node, -it MUST provide the complete list of network messages. -Status clients SHOULD request historical messages from this service node. - -The messages that have the `WakuMessage.Ephemeral` flag set to true will not be stored. - -The Status client MAY provide a method to prune the database of -older records to save storage. - -### 3. `FILTER` - -This protocol SHOULD be enabled on Light clients. - -This protocol SHOULD be used to filter messages based on a given criteria, -such as the `Content Topic` of a `MESSAGE`. -This allows a reduction in bandwidth consumption by the Status client. - -#### Content filtering protocol identifers - -The `filter-subcribe` SHOULD be implemented on `RELAY` nodes -to provide `FILTER` services. - -`filter-subscribe`: - -> /vac/waku/filter-subscribe/2.0.0-beta1 - -The `filter-push` SHOULD be implemented on light clients to receive messages. - -`filter-push`: - -> /vac/waku/filter-push/2.0.0-beta1 - -Status clients SHOULD apply a filter for all the `Content Topic` -they are interested in, such as `Content Topic` derived from - - -1. 1:1 chats with other users, described in [55/STATUS-1TO1-CHAT](/spec/55) -2. Group chats -3. Community Channels, described in [56/STATUS-COMMUNITIES](/spec/56) - -### 4. `LIGHTPUSH` - -The `LIGHTPUSH` protocol MUST be enabled on Status light clients. -A Status `RELAY` node MAY implement `LIGHTPUSH` to support light clients. -Peers will be able to publish messages, -without running a full-fledged [11/WAKU2-RELAY](/spec/11) protocol. - -When a Status client is publishing a message, -it MUST check if Light mode is enabled, -and if so, it MUST publish the message via this protocol. - -### 5. Discovery - -A discovery method MUST be supported by Light clients and Full clients - -Status clients SHOULD make use of the following peer discovery methods -that are provided by Waku, such as - - -1. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459) -2. [33/WAKU2-DISCV5](/spec/33): A node discovery protocol to -create decentralized network of interconnected Waku nodes. -3. [34/WAKU2-PEER-EXCHANGE](/spec/34): -A peer discovery protocol for resource restricted devices. - -Status clients MAY use any combination of the above peer discovery methods, -which is suited best for their implementation. - -## Security/Privacy Considerations - -This specification inherits the security and -privacy considerations from the following specifications - - -1. [10/WAKU2](/spec/10) -2. [11/WAKU2-RELAY](/spec/11) -3. [12/WAKU2-FILTER](/spec/12) -4. [13/WAKU2-STORE](/spec/13) -5. [14/WAKU2-MESSAGE](/spec/14) -6. [23/WAKU2-TOPICS](/spec/23) -7. [19/WAKU2-LIGHTPUSH](/spec/19) -8. [55/STATUS-1TO1-CHAT](/spec/55) -9. [56/STATUS-COMMUNITIES](/spec/56) -10. [62/STATUS-PAYLOAD](/spec/62) -11. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459) -12. [33/WAKU2-DISCV5](/spec/33) -13. [34/WAKU2-PEER-EXCHANGE](/spec/34) - -## Copyright - -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - -## References - -1. [55/STATUS-1TO1-CHAT](/spec/55) -2. [56/STATUS-COMMUNITIES](/spec/56) -3. [10/WAKU2](/spec/10) -4. [11/WAKU2-RELAY](/spec/11) -5. [12/WAKU2-FILTER](/spec/12) -6. [13/WAKU2-STORE](/spec/13) -7. [14/WAKU2-MESSAGE](/spec/14) -8. [23/WAKU2-TOPICS](/spec/23) -9. [19/WAKU2-LIGHTPUSH](/spec/19) -10. [64/WAKU2-NETWORK](/spec/64) -11. [62/STATUS-PAYLOAD](/spec/62) -12. [EIP-1459: DNS-Based Discovery](https://eips.ethereum.org/EIPS/eip-1459) -13. [33/WAKU2-DISCV5](/spec/33) -14. [34/WAKU2-PEER-EXCHANGE](/spec/34)