Skip to main content
LibXMTP provides flexible group messaging with configurable permissions, metadata, and member management.

Group Types

Standard Groups

Multi-member conversations supporting 1 to MAX_GROUP_SIZE inboxes:
Characteristics:
  • Creator becomes sole super admin
  • Configurable permission policies
  • Custom metadata (name, description, image)
  • Member management (add/remove)

Direct Messages (DMs)

Two-person conversations with special handling:
Characteristics:
  • Uses PolicySet::new_dm() (fixed permissions)
  • Cannot leave (prevented by validation)
  • Automatically created on first message
  • Deduplicated by participant pair
DMs are deduplicated using a dm_id composed of both inbox IDs. Multiple DM groups may exist temporarily, but they get “stitched” together based on the last active one.

Group Creation

Creating a Group

Initial State:
  • Group ID: Random bytes from OpenMLS
  • Members: Just the creator’s installation
  • Creator’s inbox ID mapped to sequence_id=0 in GroupMembership
  • Creator marked as only super admin
First Action: On the first group operation (send message, add member), the client:
  1. Updates creator’s sequence_id to current value
  2. Automatically adds creator’s other installations

Creating with Members

Add members during creation:
This creates the group then immediately adds the specified members.

Member Management

Adding Members

By inbox ID:
By wallet address:
Process:
  1. Validate member count doesn’t exceed MAX_GROUP_SIZE
  2. Fetch current key packages for all installations of each inbox
  3. Create MLS commit with Add proposals
  4. Update GroupMembership extension
  5. Send welcome messages to new members
Adding members also triggers an installations update for existing members, ensuring their latest installations are added and revoked ones removed.

Removing Members

Process:
  1. Create MLS commit with Remove proposals for all installations of the inbox
  2. Update GroupMembership extension
  3. Publish commit to network
Removing an inbox removes all of its installations from the group.

Updating Installations

Check for identity changes and sync group membership:
When this runs:
  • Automatically before sending messages (if > 5 minutes since last update)
  • Manually via update_installations()
  • During member add operations
What it does:
  1. Fetch latest association state for all group members
  2. Compute diff: new installations and revoked installations
  3. Create commit adding new installations and removing revoked ones

Group Metadata

Mutable Metadata

User-facing properties stored in GroupMutableMetadata:
Standard attributes:
  • group_name: Display name (max 100 chars)
  • description: Group description (max 1000 chars)
  • group_image_url_square: Avatar URL (max 2048 chars)
  • group_pinned_frame_url: Pinned frame URL
  • Custom attributes for app-specific data
Constraints:

Protected Metadata

Immutable properties in GroupMetadata:
Set at creation and never modified.

Querying Metadata

Updating Metadata

Each update:
  1. Validates against update_metadata_policy for that field
  2. Creates MLS commit updating GroupMutableMetadata extension
  3. Publishes to network

Permission Policies

Each group has a PolicySet controlling restricted actions:

Permission Levels

Preconfigured Policies

AllMembers: Everyone can modify
AdminsOnly: Only admins and super admins
Default: Balanced permissions

Managing Admins

Super admins cannot remove other super admins. To leave a group, a super admin must first be demoted to regular admin.

Updating Policies

The second policy parameter specifies who can make this permission change (meta-permissions).

Messaging

Sending Messages

Process:
  1. Check group is active (not inactive)
  2. Update installations if needed (periodic check)
  3. Store message locally with Unpublished status
  4. Create SendMessageIntent
  5. Process intent queue
  6. Publish MLS application message
  7. Update message to Published status
Optimistic Sending:

Querying Messages

Query options:
  • Time range (sent_after_ns, sent_before_ns)
  • Message kind (application vs. membership changes)
  • Delivery status (published, unpublished, failed)
  • Limit and direction

Enriched Messages

Get messages with reactions, replies, and deletion status:

Message Deletion

Delete your own messages or (if super admin) others:
Validation:
  • Message must belong to this group
  • Caller must be original sender OR super admin
  • Message type must be deletable
  • Message not already deleted
Deletion creates a new message of type DeleteMessage which clients use to hide the original.

Syncing

Sync Messages

Pull new messages from network:
Process:
  1. Fetch group messages since last cursor
  2. Decrypt and validate each message
  3. Store in local database
  4. Process any intents (commits to apply)
  5. Update cursor

Sync Welcomes

Discover new groups you’ve been added to:

Sync All

Sync welcomes then sync all groups:

Group Queries

Finding Groups

Conversation List

Get groups with last message preview:
States:
  • Allowed: Accepted contact
  • Denied: Blocked contact
  • Unknown: No preference set
Entity types:
  • InboxId: Block an entire inbox
  • Address: Block a wallet address
  • ConversationId: Block a specific group
Blocking happens at the application level; blocked members can still send messages but they’re hidden by the client.

Leaving Groups

Validation:
  • Must be a group member
  • Group must have > 1 member
  • Cannot be a DM (DMs can’t be left)
  • Cannot be a super admin (must be demoted first)
Process:
  1. Send LeaveRequest message to group
  2. Client is added to “pending removal” list
  3. Admins can remove pending members via remove_members_pending_removal()
Leaving does not immediately remove you. An admin must process pending removals. This prevents users from removing themselves and circumventing group policies.

Message Disappearing

Ephemeral messages that auto-delete:
Settings:
  • in_ns: Time until message expires (from send time)
  • from_ns: Timestamp when disappearing starts (0 = now)
The DisappearingMessagesWorker periodically deletes expired messages.

Advanced Features

Streaming Updates

Recovery and Forking

If group state diverges (fork detected):
This removes and re-adds installations to synchronize state.

Pending Removal Management

Process members who have requested to leave: