Expand description

Group API for MLS

This module contains the API to interact with groups.

Modules

MLS group errors

Structs

Group epoch. Internally this is stored as a u64. The group epoch is incremented with every valid Commit that is merged into the group state.

A group ID. The group ID is chosen by the creator of the group and should be globally unique.

A MlsGroup represents an MLS group with a high-level API. The API exposes high level functions to manage a group by adding/removing members, get the current member list, etc.

Specifies the configuration parameters for a MlsGroup. Refer to the User Manual for more information about the different configuration values.

A ProposalStore can store the standalone proposals that are received from the DS in between two commit messages.

A queued Add proposal

Alternative representation of a Proposal, where the sender is extracted from the encapsulating MlsPlaintext and the ProposalRef is attached.

A queued PresharedKey proposal

A queued Remove proposal

A queued Update proposal

Contains the changes from a commit to the group state.

Defines what wire format is desired for outgoing handshake messages. Note that application messages must always be encrypted.

Enums

Defines what wire format is acceptable for incoming handshake messages. Note that application messages must always be encrypted.

Enum that indicates whether the inner group state has been modified since the last time it was persisted. InnerState::Changed indicates that the state has changed and that [.save()] should be called. InnerState::Persisted indicates that the state has not been modified and therefore doesn’t need to be persisted.

MlsGroupState determines the state of an MlsGroup. The different states and their transitions are as follows:

Defines what wire format should be used for outgoing handshake messages. Note that application messages must always be encrypted.

Pending Commit state. Differentiates between Commits issued by group members and External Commits.

Helper enum that classifies the kind of remove operation. This can be used to better interpret the semantic value of a remove proposal that is covered in a Commit message.

Constants

Incoming wire formats can be mixed while outgoing wire formats are always ciphertext.

Incoming wire formats can be mixed while outgoing wire formats are always plaintext.

Incoming and outgoing wire formats are always ciphertext.

Incoming and outgoing wire formats are always plaintext.

All valid wire format policy combinations.