vacp2p
/
rfc
mirror of https://github.com/vacp2p/rfc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
rfc/content/docs/rfcs/55
History
Aaryamann Challani d79f3f7ade
fix(55/STATUS-1TO1-CHAT): describe events field (#592) 		2023-04-17 15:53:37 +05:30
..
README.md fix(55/STATUS-1TO1-CHAT): describe events field (#592) 2023-04-17 15:53:37 +05:30

README.md

slug title name status category tags editor contributors
55 55/STATUS-1TO1-CHAT Status 1-to-1 Chat draft Standards Track waku-application Aaryamann Challani <aaryamann@status.im>
Andrea Piana <andreap@status.im>
Pedro Pombeiro <pedro@status.im>
Corey Petty <corey@status.im>
Oskar Thorén <oskar@status.im>
Dean Eigenmann <dean@status.im>

Abstract

This specification describes how the Status 1-to-1 chat protocol is implemented on top of the Waku v2 protocol. This protocol can be used to send messages to a single recipient.

Terminology

  • Participant: A participant is a user that is able to send and receive messages.
  • 1-to-1 chat: A chat between two participants.
  • Public chat: A chat where any participant can join and read messages.
  • Private chat: A chat where only invited participants can join and read messages.
  • Group chat: A chat where multiple select participants can join and read messages.
  • Group admin: A participant that is able to add/remove participants from a group chat.

Background

This document describes how 2 peers communicate with each other to send messages in a 1-to-1 chat, with privacy and authenticity guarantees.

Specification

Overview

This protocol MAY use any key-exchange mechanism previously discussed -

  1. 53/WAKU2-X3DH
  2. 35/WAKU2-NOISE

This protocol can provide end-to-end encryption to give peers a strong degree of privacy and security. Public chat messages are publicly readable by anyone since there's no permission model for who is participating in a public chat.

Flow

Negotiation of a 1:1 chat

There are two phases in the initial negotiation of a 1:1 chat:

  1. Identity verification (e.g., face-to-face contact exchange through QR code, Identicon matching). A QR code serves two purposes simultaneously - identity verification and initial key material retrieval;
  2. Asynchronous initial key exchange

For more information on account generation and trust establishment, see 2/ACCOUNT

Post Negotiation

After the peers have shared their public key material, a 1:1 chat can be established using the methods described in the key-exchange protocols mentioned above.

Session management

The 1:1 chat is made robust by having sessions between peers. It is handled by the key-exchange protocol used. For example,

  1. 53/WAKU2-X3DH, the session management is described in 54/WAKU2-X3DH-SESSIONS

  2. 35/WAKU2-NOISE, the session management is described in 37/WAKU2-NOISE-SESSIONS

Negotiation of a 1:1 chat amongst multiple participants (group chat)

A small, private group chat can be constructed by having multiple participants negotiate a 1:1 chat amongst each other. Each participant MUST maintain a session with all other participants in the group chat. This allows for a group chat to be created with a small number of participants.

However, this method does not scale as the number of participants increases, for the following reasons -

  1. The number of messages sent over the network increases with the number of participants.
  2. Handling the X3DH key exchange for each participant is computationally expensive.

The above issues are addressed in 56/STATUS-COMMUNITIES, with other trade-offs.

Flow

The following flow describes how a group chat is created and maintained.

Membership Update Flow

Membership updates have the following wire format:

message MembershipUpdateMessage {
  // The chat id of the private group chat
  // derived in the following way:
  // chat_id = hex(chat_creator_public_key) + "-" + random_uuid
  // This chat_id MUST be validated by all participants
  string chat_id = 1;
  // A list of events for this group chat, first 65 bytes are the signature, then is a 
  // protobuf encoded MembershipUpdateEvent
  repeated bytes events = 2;
  oneof chat_entity {
    // An optional chat message
    ChatMessage message = 3;
    // An optional reaction to a message
    EmojiReaction emoji_reaction = 4; 
  }
}

Note that in events, the first element is the signature, and all other elements after are encoded MembershipUpdateEvent's.

where MembershipUpdateEvent is defined as follows:

message MembershipUpdateEvent {
  // Lamport timestamp of the event
  uint64 clock = 1;
  // Optional list of public keys of the targets of the action
  repeated string members = 2;
  // Name of the chat for the CHAT_CREATED/NAME_CHANGED event types
  string name = 3;
  // The type of the event
  EventType type = 4;
  // Color of the chat for the CHAT_CREATED/COLOR_CHANGED event types
  string color = 5;
  // Chat image
  bytes image = 6;

  enum EventType {
    UNKNOWN = 0;
    CHAT_CREATED = 1; // See [CHAT_CREATED](#chat-created)
    NAME_CHANGED = 2; // See [NAME_CHANGED](#name-changed)
    MEMBERS_ADDED = 3; // See [MEMBERS_ADDED](#members-added)
    MEMBER_JOINED = 4; // See [MEMBER_JOINED](#member-joined)
    MEMBER_REMOVED = 5; // See [MEMBER_REMOVED](#member-removed)
    ADMINS_ADDED = 6; // See [ADMINS_ADDED](#admins-added)
    ADMIN_REMOVED = 7; // See [ADMIN_REMOVED](#admin-removed)
    COLOR_CHANGED = 8; // See [COLOR_CHANGED](#color-changed)
    IMAGE_CHANGED = 9; // See [IMAGE_CHANGED](#image-changed)
  }
}

Note that the definitions for ChatMessage and EmojiReaction can be found in chat_message.proto and emoji_reaction.proto.

Chat Created

When creating a group chat, this is the first event that MUST be sent. Any event with a clock value lower than this MUST be discarded. Upon receiving this event a client MUST validate the chat_id provided with the update and create a chat with identified by chat_id.

By default, the creator of the group chat is the only group admin.

Name Changed

To change the name of the group chat, group admins MUST use a NAME_CHANGED event. Upon receiving this event a client MUST validate the chat_id provided with the updates and MUST ensure the author of the event is an admin of the chat, otherwise the event MUST be ignored. If the event is valid the chat name SHOULD be changed according to the provided message.

Members Added

To add members to the chat, group admins MUST use a MEMBERS_ADDED event. Upon receiving this event a participant MUST validate the chat_id provided with the updates and MUST ensure the author of the event is an admin of the chat, otherwise the event MUST be ignored. If the event is valid, a participant MUST update the list of members of the chat who have not joined, adding the members received.

Member Joined

To signal the intent to start receiving messages from a given chat, new participants MUST use a MEMBER_JOINED event. Upon receiving this event a participant MUST validate the chat_id provided with the updates. If the event is valid a participant MUST add the new participant to the list of participants stored locally. Any message sent to the group chat MUST now include the new participant.

Member Removed

There are two ways in which a member MAY be removed from a group chat:

  • A member MAY leave the chat by sending a MEMBER_REMOVED event, with the members field containing their own public key.
  • An admin MAY remove a member by sending a MEMBER_REMOVED event, with the members field containing the public key of the member to be removed.

Each participant MUST validate the chat_id provided with the updates and MUST ensure the author of the event is an admin of the chat, otherwise the event MUST be ignored. If the event is valid, a participant MUST update the local list of members accordingly.

Admins Added

To promote participants to group admin, group admins MUST use an ADMINS_ADDED event. Upon receiving this event, a participant MUST validate the chat_id provided with the updates, MUST ensure the author of the event is an admin of the chat, otherwise the event MUST be ignored. If the event is valid, a participant MUST update the list of admins of the chat accordingly.

Admin Removed

Group admins MUST NOT be able to remove other group admins. An admin MAY remove themselves by sending an ADMIN_REMOVED event, with the members field containing their own public key. Each participant MUST validate the chat_id provided with the updates and MUST ensure the author of the event is an admin of the chat, otherwise the event MUST be ignored. If the event is valid, a participant MUST update the list of admins of the chat accordingly.

Color Changed

To change the text color of the group chat name, group admins MUST use a COLOR_CHANGED event.

Image Changed

To change the display image of the group chat, group admins MUST use an IMAGE_CHANGED event.

Security Considerations

  1. Inherits the security considerations of the key-exchange mechanism used, e.g., 53/WAKU2-X3DH or 35/WAKU2-NOISE

Copyright

Copyright and related rights waived via CC0.

References

  1. 2/ACCOUNT
  2. 53/WAKU2-X3DH
  3. 35/WAKU2-NOISE
  4. 10/WAKU2
  5. 7/GROUP-CHAT