Group API for MLS
This module contains the API to interact with groups.
MLS group errors
Group epoch. Internally this is stored as a
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.
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.
Builder for an
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.
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.
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
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.