Skip to content

Commit

Permalink
Update status-app-protocols.md
Browse files Browse the repository at this point in the history
  • Loading branch information
jimstir authored Nov 6, 2024
1 parent 9ba2a0b commit 4608aec
Showing 1 changed file with 23 additions and 23 deletions.
46 changes: 23 additions & 23 deletions status/raw/status-app-protocols.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,8 +58,8 @@ Status currently defines functionality to support three main application feature
Each application-level function, regardless which feature set it supports, has the following properties:

Check failure on line 58 in status/raw/status-app-protocols.md

View workflow job for this annotation

GitHub Actions / lint

Line length

status/raw/status-app-protocols.md:58:81 MD013/line-length Line length [Expected: 80; Actual: 104] https://github.com/DavidAnson/markdownlint/blob/v0.33.0/doc/md013.md

Check failure on line 58 in status/raw/status-app-protocols.md

View workflow job for this annotation

GitHub Actions / lint

Line length

status/raw/status-app-protocols.md:58:81 MD013/line-length Line length [Expected: 80; Actual: 104] https://github.com/DavidAnson/markdownlint/blob/v0.33.0/doc/md013.md

1. Functional scope
1. Content topic
1. Ephemerality
2. Content topic
3. Ephemerality

### Functional Scope

Expand Down Expand Up @@ -141,7 +141,7 @@ App-level messages that are considered ephemeral, MUST set the `ephemeral` field
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))
2. 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.
Expand Down Expand Up @@ -244,8 +244,8 @@ 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
2. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) allows decentralized discovery of Waku peers.
3. [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
Expand All @@ -264,14 +264,14 @@ 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.
2. 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
2. Global content
3. Community control, for each community of which the app user is a member
4. 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.

Expand All @@ -291,14 +291,14 @@ The application MUST publish user and app generated messages via the Waku transp
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.
2. 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
2. Global content
3. Community control, for each community of which the app user is a member
4. 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.

Expand Down Expand Up @@ -398,13 +398,13 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## 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)
2. [56/STATUS-COMMUNITIES](../56/communities.md)
3. [10/WAKU2](../../waku/standards/core/10/waku2.md)
4. [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
5. [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)
6. [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md)
7. [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)
8. [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md)
9. [Scalable distributed log reliability](https://forum.vac.dev/t/end-to-end-reliability-for-scalable-distributed-logs/293/16)
10. [STATUS-MVDS-USAGE](./status-mvds.md)
11. [WAKU2-STORE](https://github.com/waku-org/specs/blob/8fea97c36c7bbdb8ddc284fa32aee8d00a2b4467/standards/core/store.md)

0 comments on commit 4608aec

Please sign in to comment.