This document describes the design of Status Communities over Waku v2, allowing for multiple users to communicate in a discussion space. This is a key feature for the Status messaging app.
The purpose of Status communities, as specified in this document, is allowing for large group chats. Communities can have further substructure, e.g. specific channels.
Smaller group chats, on the other hand, are out of scope for this document and can be built over 55/STATUS-1TO1-CHAT. We refer to these smaller group chats simply as "group chats", to differentiate them from Communities.
For group chats based on 55/STATUS-1TO1-CHAT, the key exchange mechanism MUST be X3DH, as described in 53/WAKU2-X3DH.
However, this method does not scale as the number of participants increases, for the following reasons -
- 1The number of messages sent over the network increases with the number of participants.
- 2Handling the X3DH key exchange for each participant is computationally expensive.
Having multicast channels reduces the overhead of a group chat based on 1:1 chat. Additionally, if all the participants of the group chat have a shared key, then the number of messages sent over the network is reduced to one per message.
- Community: A group of peers that can communicate with each other.
- Member: A peer that is part of a community.
- Admin: A member that has administrative privileges. Used interchangeably with "owner".
- Channel: A designated subtopic for a community. Used interchangeably with "chat".
Due to the nature of communities, the following requirements are necessary for the design of communities -
- 1The creator of the Community is the owner of the Community.
- 2The Community owner is trusted.
- 3The Community owner can add or remove members from the Community. This extends to banning and kicking members.
- 4The Community owner can add, edit and remove channels.
- 5Community members can send/receive messages to the channels which they have access to.
- 6Communities may be encrypted (private) or unencrypted (public).
- 7A Community is uniquely identified by a public key.
- 8The public key of the Community is shared out of band.
- 9The metadata of the Community can be found by listening on a content topic derived from the public key of the Community.
- 10Community members run their own Waku nodes, with the configuration described in Waku-Protocols. Light nodes solely implementing 19/WAKU2-LIGHTPUSH may not be able to run their own Waku node with the configuration described.
The following cryptographic primitives are used in the design -
- X3DH
- Single Ratchet
- The single ratchet is used to encrypt the messages sent to the Community.
- The single ratchet is re-keyed when a member is added/removed from the Community.
Note: The usage of the clock is described in the Clock section.
"Content topic" refers to the field in 14/WAKU2-MESSAGE, further elaborated in 10/WAKU2.
The content topic that the community is advertised on MUST be derived from the public key of the community. The content topic MUST be the first four bytes of the keccak-256 hash of the compressed (33 bytes) public key of the community encoded into a hex string.
The unique identifier for a community channel/chat is the chat id.
The content topic that Community channels/chats use MUST be the hex-encoded keccak-256 hash of the public key of the community concatenated with the chat id.
Requests to leave, join, kick and ban, as well as key exchange messages, MUST be sent to the content topic derived from the public key of the community. The content topic MUST be the hex-encoded keccak-256 hash of the public key of the community.
The flows for Community management are as described below.
- 1The Community owner generates a public/private key pair.
- 2The Community owner configures the Community metadata, according to the wire format "CommunityDescription".
- 3The Community owner publishes the Community metadata on a content topic derived from the public key of the Community. the Community metadata SHOULD be encrypted with the public key of the Community. The Community metadata MAY be sent during fixed intervals, to ensure that the Community metadata is available to members. The Community metadata SHOULD be sent every time the Community metadata is updated.
- 4The Community owner MAY advertise the Community out of band, by sharing the public key of the Community on other mediums of communication.
- 1
- 2The peer requests to join a Community by sending a "CommunityRequestToJoin" message to the Community. At this point, the peer MAY send a "CommunityCancelRequestToJoin" message to cancel the request.
- 3The Community owner MAY accept or reject the request.
- 4If the request is accepted, the Community owner sends a "CommunityRequestToJoinResponse" message to the peer.
- 5The Community owner then adds the member to the Community metadata, and publishes the updated Community metadata.
- 1
- 2The peer is invited to join a Community by the Community owner, by sending a "CommunityInvitation" message.
- 3The peer decrypts the "CommunityInvitation" message, and verifies the signature.
- 4The peer requests to join a Community by sending a "CommunityRequestToJoin" message to the Community.
- 5The Community owner MAY accept or reject the request.
- 6If the request is accepted, the Community owner sends a "CommunityRequestToJoinResponse" message to the peer.
- 7The Community owner then adds the member to the Community metadata, and publishes the updated Community metadata.
- 1A member requests to leave a Community by sending a "CommunityRequestToLeave" message to the Community.
- 2The Community owner MAY accept or reject the request.
- 3If the request is accepted, the Community owner removes the member from the Community metadata, and publishes the updated Community metadata.
- 1The Community owner adds a member to the ban list, revokes their grants, and publishes the updated Community metadata.
- 2If the Community is Private, Re-keying is performed between the members of the Community, to ensure that the banned member is unable to decrypt any messages.
The following Waku protocols SHOULD be used to implement Status Communities -
- 111/WAKU2-RELAY - To send and receive messages
- 253/WAKU2-X3DH - To encrypt and decrypt messages
- 354/WAKU2-X3DH-SESSIONS - To handle session keys
- 414/WAKU2-MESSAGE - To wrap community messages in a Waku message
- 513/WAKU2-STORE - To store and retrieve messages for offline devices
The following Waku protocols MAY be used to implement Status Communities -
- 112/WAKU2-FILTER - Content filtering for resource restricted devices
- 219/WAKU2-LIGHTPUSH - Allows Light clients to participate in the network
The member MAY back up their local settings, by encrypting it with their public key, and sending it to a given content topic. The member MAY then rely on this backup to restore their local settings, in case of a data loss. This feature relies on 13/WAKU2-STORE for storing and retrieving messages.
The clock used in the wire format refers to the Lamport timestamp of the message. The Lamport timestamp is a logical clock that is used to determine the order of events in a distributed system. This allows ordering of messages in an asynchronous network where messages may be received out of order.
- 1The Community owner is a single point of failure. If the Community owner is compromised, the Community is compromised.
- 2
- 1To scale and optimize the Community management, the Community metadata should be stored on a decentralized storage system, and only the references to the Community metadata should be broadcasted. The following document describes this method in more detail - Optimizing the
CommunityDescription
dissemination - 2Token gating for communities
- 3Sharding the content topic used for #Community Event Messages, since members of the community don't need to receive all the control messages.
Copyright and related rights waived via CC0.