Struct GroupOperations 

pub struct GroupOperations {
    pub group_secret_params: GroupSecretParams,
}

Fields

group_secret_params: GroupSecretParams

Implementations

impl GroupOperations

pub fn encrypt_title<R: Rng + CryptoRng>( &self, title: &str, rng: &mut R, ) -> Vec<u8>

pub fn encrypt_description<R: Rng + CryptoRng>( &self, description: Option<&str>, rng: &mut R, ) -> Vec<u8>

pub fn encrypt_disappearing_messages_timer<R: Rng + CryptoRng>( &self, timer: Option<&Timer>, rng: &mut R, ) -> Vec<u8>

pub fn new(group_secret_params: GroupSecretParams) -> Self

pub fn decrypt_group(&self, group: Group) -> Result<Group, GroupDecodingError>

pub fn decrypt_group_change( &self, group_change: GroupChange, ) -> Result<GroupChanges, GroupDecodingError>

pub fn decrypt_avatar(&self, ciphertext: &[u8]) -> Option<Vec<u8>>

pub fn build_add_member_action( &self, aci: Aci, profile_key: ProfileKey, role: Role, ) -> Result<AddMemberAction, GroupDecodingError>

Build an AddMemberAction for a GroupChange.

Role Parameter

The role parameter is accepted for API consistency, but note that Signal-Android only ever adds members with Role::Default. Adding a member with Role::Administrator is an illegal operation that the server will reject. Promotion to administrator requires a separate ModifyMemberRoleAction after the member has been added.

See Signal-Android’s GroupsV2Operations.GroupOperations.createModifyGroupMembershipChange() which hardcodes Member.Role newMemberRole = Member.Role.DEFAULT.

pub fn build_remove_member_action( &self, aci: Aci, ) -> Result<DeleteMemberAction, GroupDecodingError>

Build a DeleteMemberAction for a GroupChange

pub fn build_remove_pending_member_action( &self, invitee: ServiceId, ) -> Result<DeleteMemberPendingProfileKeyAction, GroupDecodingError>

Build a DeletePendingMemberAction to retract an outstanding invitation.

Used when a pending member (invite not yet accepted) is to be removed. The invitee may be ACI or PNI — whichever service ID was used when the invite was originally created. The Signal server stores and matches on the encrypted user_id field of PendingMember, which may be either kind of ServiceId.

pub fn create_member_presentation( &self, server_public_params: &ServerPublicParams, credential: &ExpiringProfileKeyCredential, ) -> Vec<u8>

Create a presentation from a credential for adding a member to a group.

This creates a ZK proof (ExpiringProfileKeyCredentialPresentation) that the Signal server can verify to validate the member’s identity and profile key.

pub fn encrypt_group_with_credentials<R: Rng + CryptoRng>( &self, title: &str, description: Option<&str>, disappearing_messages_timer: Option<&Timer>, access_control: Option<&AccessControl>, self_credential: &ExpiringProfileKeyCredential, member_candidates: &[GroupMemberCandidate], server_public_params: &ServerPublicParams, avatar_url: String, rng: &mut R, ) -> Result<Group, GroupDecodingError>

Encrypt a group for creation, using credentials for member presentations.

This method properly populates the presentation field for members with credentials, which is required by the Signal server for group creation.

Members with credentials get added with presentations (full members). Members without credentials get added as pending invites.

Arguments

• title - The group title
• description - Optional group description
• disappearing_messages_timer - Optional disappearing messages timer
• access_control - Optional access control settings
• self_credential - The creator’s own credential (required)
• avatar_url - The group avatar URL
• member_candidates - Other members to add, with optional credentials
• server_public_params - Server public params for creating presentations
• rng - Random number generator

pub fn build_add_member_action_with_credential( &self, credential: &ExpiringProfileKeyCredential, role: Role, server_public_params: &ServerPublicParams, ) -> AddMemberAction

Build an AddMemberAction with a credential presentation for a GroupChange.

This is used when adding members to an existing group with proper ZK proofs.

Role Parameter

The role parameter is accepted for API consistency, but note that Signal-Android only ever adds members with Role::Default. Adding a member with Role::Administrator is an illegal operation that the server will reject. Promotion to administrator requires a separate ModifyMemberRoleAction after the member has been added.

pub fn build_add_pending_member_action( &self, invitee: ServiceId, added_by_aci: Aci, role: Role, ) -> Result<AddMemberPendingProfileKeyAction, GroupDecodingError>

Build an AddPendingMemberAction to invite a member without their profile key.

This adds the member as a pending invite. They will receive a group invite notification and must accept to become a full member. No profile key is needed.

The invitee may be either an ACI or a PNI. When only a PNI is known (e.g. the invitee has ACI disclosure disabled in CDSI), passing ServiceId::Pni allows the pending-invite path to proceed without an ACI. The Signal server stores whichever service ID is provided in the encrypted user_id field of the PendingMember proto. The added_by_aci must always be an ACI.

Role Parameter

The role parameter is accepted for API consistency, but note that Signal-Android only ever adds pending members with Role::Default.