2026-06-15 13:15:18 -07:00
|
|
|
// This Implementation is a Quick and Dirty Integration of DeMLS into libchat.
|
|
|
|
|
// DeMLS and Libchat have different execution models, trait definitions and ownership/lifetimes of objects.
|
|
|
|
|
// The easies path is to do a Spike to see what it would take, gather the friction points and then iterate.
|
|
|
|
|
|
|
|
|
|
use crate::types::AddressedEncryptedPayload;
|
|
|
|
|
use crate::{Content, WakeupService};
|
|
|
|
|
use alloy::signers::local::PrivateKeySigner;
|
|
|
|
|
use blake2::{Blake2b, Digest, digest::consts::U6};
|
|
|
|
|
use chat_proto::logoschat::encryption::{EncryptedPayload, Plaintext, encrypted_payload};
|
|
|
|
|
use de_mls::protos::de_mls::messages::v1::{
|
|
|
|
|
AppMessage as AppMessageProto, MemberWelcome, app_message,
|
|
|
|
|
};
|
2026-06-23 18:08:25 +03:00
|
|
|
use de_mls::{
|
feat: GroupV2 through the threaded client, group roster, registry retry (#167)
* feat: expose GroupV2 through the threaded client
GroupV2 (de-mls) conversations were reachable only from Core, and every
conversation ran the hardcoded millisecond timer profile in group_v2.rs
(20-150 ms freeze/consensus windows), which cannot survive real network
latency. Make them reachable through ChatClient (as DirectV1 already is), with
timing that holds up over a real network.
- ChatClient::create_group_conversation(accounts) and
add_group_members(convo_id, accounts): resolve each account address to
its endorsed signer ids through the client-held directory, the same
resolution create_direct_conversation uses, and drive
Core::create_group_convo / group_add_member.
- GroupV2 timing/policy is injectable: ServiceContext carries a
de_mls::ConversationConfig (re-exported as GroupV2Config) defaulting
to the de-mls library defaults; Core::set_group_v2_config and the
builder's group_v2_config setter override it. The creator's phase
durations reach joiners inside the welcome's ConversationSync, so the
group runs the creator's phase timing.
- GroupV2Convo::add_member validates every member's key package before
proposing any add, skips members de-mls would silently not propose
(self, already in the group) instead of stranding a pending invite,
and flushes opened proposals even on a mid-batch failure, so a failed
batch cannot invite members behind the caller's back.
- The millisecond test profile moves into the test harnesses
(integration_tests_core's TestHarness, crates/client/tests/group_v2.rs).
- New client-level tests: three accounts on the in-process transport
create a group, a non-creator adds the third member, and messages fan
out with directory-verified senders; a batch containing a member with
no key package fails without inviting anyone.
* fix: class inbound DirectV1 joins as Private, not Group
The joiner of a DirectV1 (pairwise) conversation received it classed as
Group, because dispatch_to_inbox2 hardcoded ConversationClass::Group for
every InboxV2 join. DirectV1 welcomes (InviteType::GroupV1) and GroupV2
welcomes (InviteType::GroupV2) both arrive over InboxV2, so a plain 1:1
invite surfaced to the display layer as a group. ConversationClass is
documented as stable across protocol versions of the same conversation
shape, and DirectV1 is the pairwise shape, so its joiner must see Private.
- InboxV2::handle_frame returns the class alongside the convo:
InviteType::GroupV1 (the DirectV1 welcome carrier) yields Private,
InviteType::GroupV2 yields Group.
- dispatch_to_inbox2 propagates that class instead of hardcoding Group.
- direct_v1_by_account_address asserts the joiner sees Private.
* feat: expose a group's roster, deduped to one entry per account
The display layer needs a group's membership, but nothing exposed it:
de-mls holds the authoritative roster (MLS group state) with no public
accessor, and members added by other members stay invisible until they
send a message. Rebuilding the roster from observed messages would fork
state the crypto layer owns and be wrong exactly when a group grows.
- GroupConvo::members() returns each member's hex-encoded MLS
leaf-credential content, self included. GroupV2Convo delegates to
de-mls and guarantees self-inclusion; GroupV1Convo reads its openmls
leaves.
- Core::group_members(convo_id) mirrors group_add_member's dispatch: a
cached group yields its members, a direct conversation is an
UnsupportedFunction, otherwise the group is loaded.
- ChatClient::group_members returns Vec<GroupMember>, resolving each
member's account claim through the directory. A member whose account
claim is unconfirmable is listed by device with account None rather
than dropped: it is cryptographically in the group, only the account
claim is unproven. The credential parsing decode_sender did is
factored into parse_credential and shared by both, leaving
decode_sender's stricter drop semantics for message senders unchanged.
- Because resolve_device_ids fans an account out to every endorsed
device, an account whose devices all join surfaced once per device;
group_members dedups by account, keeping the first-seen device as the
account's representative. Members with no confirmed account stay
individual, keyed by their unique device key.
- Unit tests cover the tolerant-vs-drop split and the per-account dedup;
the three-member group integration test asserts the roster converges
after create and after each add, and a solo group lists only its
creator.
* feat: retry the registry on transient 5xx with backoff and jitter
The keypackage/account registry is reliable request-by-request but sheds concurrent bursts with a 5xx, so several instances registering at once each hard-failed on init. HttpRegistry's four calls now retry network errors and 5xx/429 with exponential backoff and full jitter (the jitter decorrelates concurrent publishers so their retries don't re-collide); 4xx and success return immediately. The total retry window is bounded to a few seconds.
* fix: mark InboxV2 key package last-resort so members can join multiple groups
A key package's init key is one-time-use: openmls deletes it after the first
welcome that consumes it. Each installation registers a single key package, so a
second group inviting the same member found no matching key package and rejected
the welcome with "welcome not addressed to this member", the flaky group add.
Mark the InboxV2 key package as last-resort (and advertise the extension in the
leaf capabilities, which key-package validation requires) so openmls retains the
init key, letting one key package admit an installation to any number of groups.
This reuses one init key for every join, trading per-join forward secrecy for
membership that just works. A TODO at the publish site tracks the intended
one-time key-package pool (the registry pops one per fetch, the client
replenishes) with last-resort as the exhaustion fallback (#169).
Add regression tests: a member joining two groups (core harness) and two peers
invited to several groups over the threaded client.
* fix: dedup list_conversations across the store and the in-memory cache
A DirectV1 join persists its conversation to the store and also caches it in
memory, so list_conversations saw it twice. It deduped with Vec::dedup, which
only drops consecutive repeats, over cached_convos' nondeterministic HashMap
order, so the duplicate survived whenever another cached conversation fell
between the two copies. list_conversations then intermittently returned a
conversation twice, and a consumer counting conversations (e.g. checking that a
peer joined a group while a direct chat already existed) saw a flaky count.
Dedup through a set so a conversation held in both stores is listed once
regardless of iteration order.
Add a DirectV1-then-GroupV2 regression test, which also covers key-package reuse
across conversation types.
* fix: dedup the GroupV2 add batch to avoid redundant fetches and duplicate invites
Both create_group_convo_v2 and group_add_member funnel through
GroupV2Convo::add_member, so a duplicate signer (an account that resolves
to the same signer twice, or a repeated account) cost a redundant
key-package fetch and a second Add proposal. The existing guard skipped
only self and already-committed members, which a within-batch duplicate
escapes because add_member opens a proposal the committed roster does not
yet reflect, stranding a pending_invite that can later fire a spurious
duplicate welcome.
Dedup the requested signers before fetching, and guard the add loop with a
membership set seeded from the roster and self, hoisting the per-iteration
members() call out of the loop.
* docs: correct the retry-budget and group-add doc comments
The retry-budget comment claimed the ~20s init IPC budget held even at the
worst-case sum, but that only holds on the load-shed path where each retry
returns fast; a fully unreachable registry costs up to MAX_RETRIES times
the reqwest timeout, which no retry budget can rescue. State both.
Reword add_group_members to name the proposal, commit, and welcome flow
rather than the unexplained "once the add commits".
* chore: allow clippy::question_mark in LocalBroadcaster::poll (Rust 1.97 FP)
Stable rolled to 1.97, whose clippy question_mark flags poll()'s match on
`self.shared.borrow().read(next)`. Its suggested `read(next)?` would drop the
RefCell Ref guard and dangle the returned reference, so the lint is a false
positive here. CI tracks floating stable (`rustup update stable`), so this is
pre-existing code newly flagged; suppress it to keep the branch green.
2026-07-09 20:02:04 +02:00
|
|
|
Conversation, ConversationEvent, PeerScoringService, ScoringConfig, default_score_deltas,
|
2026-06-29 15:54:26 +03:00
|
|
|
defaults::{DefaultConsensusPlugin, DefaultPeerScoring, InMemoryPeerScoreStorage},
|
2026-06-23 18:08:25 +03:00
|
|
|
};
|
2026-06-15 13:15:18 -07:00
|
|
|
use hashgraph_like_consensus::signing::EthereumConsensusSigner;
|
2026-07-01 15:45:40 -07:00
|
|
|
use openmls::group::MlsGroupCreateConfig;
|
2026-07-03 23:18:10 +02:00
|
|
|
use openmls::prelude::tls_codec::Deserialize as _;
|
|
|
|
|
use openmls::prelude::{KeyPackageIn, OpenMlsProvider as _, ProtocolVersion};
|
2026-06-15 13:15:18 -07:00
|
|
|
use prost::Message;
|
|
|
|
|
use shared_traits::{IdentId, IdentIdRef};
|
|
|
|
|
use std::sync::Arc;
|
|
|
|
|
use tracing::{info, instrument, warn};
|
|
|
|
|
|
|
|
|
|
use crate::IdentityProvider;
|
|
|
|
|
use crate::conversation::{ConversationIdRef, ExternalServices, ServiceContext};
|
|
|
|
|
use crate::{
|
|
|
|
|
ConvoOutcome, DeliveryService, RegistrationService,
|
2026-06-19 08:43:55 -07:00
|
|
|
conversation::{ChatError, Convo, GroupConvo, Identified},
|
2026-06-15 13:15:18 -07:00
|
|
|
};
|
|
|
|
|
|
2026-06-23 18:08:25 +03:00
|
|
|
/// Local member id bytes — the account identity the protocol matches on,
|
|
|
|
|
/// shared with the MLS credential and the consensus member.
|
|
|
|
|
fn member_id<S: ExternalServices>(service_ctx: &ServiceContext<S>) -> Vec<u8> {
|
|
|
|
|
service_ctx.mls_identity.id().as_str().as_bytes().to_vec()
|
2026-06-15 13:15:18 -07:00
|
|
|
}
|
|
|
|
|
|
2026-06-23 18:08:25 +03:00
|
|
|
/// `app_id` for outbound packets / echo-dedup — random per conversation.
|
|
|
|
|
fn rand_app_id() -> Arc<[u8]> {
|
|
|
|
|
Arc::from(rand_string(5).as_bytes())
|
|
|
|
|
}
|
2026-06-15 13:15:18 -07:00
|
|
|
|
2026-06-23 18:08:25 +03:00
|
|
|
/// Peer-scoring plug-in: the library default over in-memory storage.
|
|
|
|
|
fn make_scoring() -> DefaultPeerScoring {
|
|
|
|
|
PeerScoringService::new(
|
2026-06-29 15:54:26 +03:00
|
|
|
InMemoryPeerScoreStorage::default(),
|
2026-06-23 18:08:25 +03:00
|
|
|
default_score_deltas(),
|
|
|
|
|
ScoringConfig::default(),
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Consensus service: the library default over a fresh in-memory store and a
|
|
|
|
|
/// random Ethereum consensus signer.
|
2026-06-29 15:54:26 +03:00
|
|
|
fn make_consensus() -> DefaultConsensusPlugin {
|
|
|
|
|
DefaultConsensusPlugin::new(EthereumConsensusSigner::new(PrivateKeySigner::random()))
|
2026-06-23 18:08:25 +03:00
|
|
|
}
|
|
|
|
|
|
2026-06-15 13:15:18 -07:00
|
|
|
pub struct GroupV2Convo {
|
|
|
|
|
convo_id: String,
|
2026-06-29 15:54:26 +03:00
|
|
|
conversation: Conversation<DefaultConsensusPlugin, InMemoryPeerScoreStorage>,
|
2026-07-03 23:18:10 +02:00
|
|
|
/// Joiners WE invited, as `(member_id, signer_id)`: the de-mls member id
|
|
|
|
|
/// (the joiner's leaf credential content, read from its key package) paired
|
|
|
|
|
/// with the signer id its welcome is delivered to.
|
|
|
|
|
pending_invites: Vec<(Vec<u8>, String)>,
|
2026-06-15 13:15:18 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl std::fmt::Debug for GroupV2Convo {
|
|
|
|
|
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
|
|
|
|
|
f.debug_struct("GroupV2Convo")
|
|
|
|
|
.field("convo_id", &self.convo_id)
|
|
|
|
|
.finish_non_exhaustive()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn rand_string(n: usize) -> String {
|
|
|
|
|
let bytes: Vec<u8> = (0..n).map(|_| rand::random::<u8>()).collect();
|
|
|
|
|
hex::encode(bytes)
|
|
|
|
|
}
|
|
|
|
|
|
2026-07-01 15:45:40 -07:00
|
|
|
fn group_config() -> MlsGroupCreateConfig {
|
|
|
|
|
MlsGroupCreateConfig::builder()
|
|
|
|
|
.use_ratchet_tree_extension(true)
|
|
|
|
|
.build()
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-15 13:15:18 -07:00
|
|
|
impl GroupV2Convo {
|
|
|
|
|
pub fn new<S: ExternalServices>(
|
|
|
|
|
service_ctx: &mut ServiceContext<S>,
|
|
|
|
|
) -> Result<Self, ChatError> {
|
|
|
|
|
let convo_id = rand_string(5);
|
2026-06-23 18:08:25 +03:00
|
|
|
let conversation = Conversation::create(
|
|
|
|
|
&convo_id,
|
2026-06-29 15:54:26 +03:00
|
|
|
&member_id(service_ctx),
|
2026-06-23 18:08:25 +03:00
|
|
|
&service_ctx.mls_provider,
|
|
|
|
|
service_ctx.mls_identity.get_credential(),
|
2026-07-01 15:45:40 -07:00
|
|
|
&group_config(),
|
2026-06-23 18:08:25 +03:00
|
|
|
&service_ctx.mls_identity,
|
2026-06-29 15:54:26 +03:00
|
|
|
&make_consensus(),
|
2026-06-23 18:08:25 +03:00
|
|
|
make_scoring(),
|
|
|
|
|
rand_app_id(),
|
feat: GroupV2 through the threaded client, group roster, registry retry (#167)
* feat: expose GroupV2 through the threaded client
GroupV2 (de-mls) conversations were reachable only from Core, and every
conversation ran the hardcoded millisecond timer profile in group_v2.rs
(20-150 ms freeze/consensus windows), which cannot survive real network
latency. Make them reachable through ChatClient (as DirectV1 already is), with
timing that holds up over a real network.
- ChatClient::create_group_conversation(accounts) and
add_group_members(convo_id, accounts): resolve each account address to
its endorsed signer ids through the client-held directory, the same
resolution create_direct_conversation uses, and drive
Core::create_group_convo / group_add_member.
- GroupV2 timing/policy is injectable: ServiceContext carries a
de_mls::ConversationConfig (re-exported as GroupV2Config) defaulting
to the de-mls library defaults; Core::set_group_v2_config and the
builder's group_v2_config setter override it. The creator's phase
durations reach joiners inside the welcome's ConversationSync, so the
group runs the creator's phase timing.
- GroupV2Convo::add_member validates every member's key package before
proposing any add, skips members de-mls would silently not propose
(self, already in the group) instead of stranding a pending invite,
and flushes opened proposals even on a mid-batch failure, so a failed
batch cannot invite members behind the caller's back.
- The millisecond test profile moves into the test harnesses
(integration_tests_core's TestHarness, crates/client/tests/group_v2.rs).
- New client-level tests: three accounts on the in-process transport
create a group, a non-creator adds the third member, and messages fan
out with directory-verified senders; a batch containing a member with
no key package fails without inviting anyone.
* fix: class inbound DirectV1 joins as Private, not Group
The joiner of a DirectV1 (pairwise) conversation received it classed as
Group, because dispatch_to_inbox2 hardcoded ConversationClass::Group for
every InboxV2 join. DirectV1 welcomes (InviteType::GroupV1) and GroupV2
welcomes (InviteType::GroupV2) both arrive over InboxV2, so a plain 1:1
invite surfaced to the display layer as a group. ConversationClass is
documented as stable across protocol versions of the same conversation
shape, and DirectV1 is the pairwise shape, so its joiner must see Private.
- InboxV2::handle_frame returns the class alongside the convo:
InviteType::GroupV1 (the DirectV1 welcome carrier) yields Private,
InviteType::GroupV2 yields Group.
- dispatch_to_inbox2 propagates that class instead of hardcoding Group.
- direct_v1_by_account_address asserts the joiner sees Private.
* feat: expose a group's roster, deduped to one entry per account
The display layer needs a group's membership, but nothing exposed it:
de-mls holds the authoritative roster (MLS group state) with no public
accessor, and members added by other members stay invisible until they
send a message. Rebuilding the roster from observed messages would fork
state the crypto layer owns and be wrong exactly when a group grows.
- GroupConvo::members() returns each member's hex-encoded MLS
leaf-credential content, self included. GroupV2Convo delegates to
de-mls and guarantees self-inclusion; GroupV1Convo reads its openmls
leaves.
- Core::group_members(convo_id) mirrors group_add_member's dispatch: a
cached group yields its members, a direct conversation is an
UnsupportedFunction, otherwise the group is loaded.
- ChatClient::group_members returns Vec<GroupMember>, resolving each
member's account claim through the directory. A member whose account
claim is unconfirmable is listed by device with account None rather
than dropped: it is cryptographically in the group, only the account
claim is unproven. The credential parsing decode_sender did is
factored into parse_credential and shared by both, leaving
decode_sender's stricter drop semantics for message senders unchanged.
- Because resolve_device_ids fans an account out to every endorsed
device, an account whose devices all join surfaced once per device;
group_members dedups by account, keeping the first-seen device as the
account's representative. Members with no confirmed account stay
individual, keyed by their unique device key.
- Unit tests cover the tolerant-vs-drop split and the per-account dedup;
the three-member group integration test asserts the roster converges
after create and after each add, and a solo group lists only its
creator.
* feat: retry the registry on transient 5xx with backoff and jitter
The keypackage/account registry is reliable request-by-request but sheds concurrent bursts with a 5xx, so several instances registering at once each hard-failed on init. HttpRegistry's four calls now retry network errors and 5xx/429 with exponential backoff and full jitter (the jitter decorrelates concurrent publishers so their retries don't re-collide); 4xx and success return immediately. The total retry window is bounded to a few seconds.
* fix: mark InboxV2 key package last-resort so members can join multiple groups
A key package's init key is one-time-use: openmls deletes it after the first
welcome that consumes it. Each installation registers a single key package, so a
second group inviting the same member found no matching key package and rejected
the welcome with "welcome not addressed to this member", the flaky group add.
Mark the InboxV2 key package as last-resort (and advertise the extension in the
leaf capabilities, which key-package validation requires) so openmls retains the
init key, letting one key package admit an installation to any number of groups.
This reuses one init key for every join, trading per-join forward secrecy for
membership that just works. A TODO at the publish site tracks the intended
one-time key-package pool (the registry pops one per fetch, the client
replenishes) with last-resort as the exhaustion fallback (#169).
Add regression tests: a member joining two groups (core harness) and two peers
invited to several groups over the threaded client.
* fix: dedup list_conversations across the store and the in-memory cache
A DirectV1 join persists its conversation to the store and also caches it in
memory, so list_conversations saw it twice. It deduped with Vec::dedup, which
only drops consecutive repeats, over cached_convos' nondeterministic HashMap
order, so the duplicate survived whenever another cached conversation fell
between the two copies. list_conversations then intermittently returned a
conversation twice, and a consumer counting conversations (e.g. checking that a
peer joined a group while a direct chat already existed) saw a flaky count.
Dedup through a set so a conversation held in both stores is listed once
regardless of iteration order.
Add a DirectV1-then-GroupV2 regression test, which also covers key-package reuse
across conversation types.
* fix: dedup the GroupV2 add batch to avoid redundant fetches and duplicate invites
Both create_group_convo_v2 and group_add_member funnel through
GroupV2Convo::add_member, so a duplicate signer (an account that resolves
to the same signer twice, or a repeated account) cost a redundant
key-package fetch and a second Add proposal. The existing guard skipped
only self and already-committed members, which a within-batch duplicate
escapes because add_member opens a proposal the committed roster does not
yet reflect, stranding a pending_invite that can later fire a spurious
duplicate welcome.
Dedup the requested signers before fetching, and guard the add loop with a
membership set seeded from the roster and self, hoisting the per-iteration
members() call out of the loop.
* docs: correct the retry-budget and group-add doc comments
The retry-budget comment claimed the ~20s init IPC budget held even at the
worst-case sum, but that only holds on the load-shed path where each retry
returns fast; a fully unreachable registry costs up to MAX_RETRIES times
the reqwest timeout, which no retry budget can rescue. State both.
Reword add_group_members to name the proposal, commit, and welcome flow
rather than the unexplained "once the add commits".
* chore: allow clippy::question_mark in LocalBroadcaster::poll (Rust 1.97 FP)
Stable rolled to 1.97, whose clippy question_mark flags poll()'s match on
`self.shared.borrow().read(next)`. Its suggested `read(next)?` would drop the
RefCell Ref guard and dangle the returned reference, so the lint is a false
positive here. CI tracks floating stable (`rustup update stable`), so this is
pre-existing code newly flagged; suppress it to keep the branch green.
2026-07-09 20:02:04 +02:00
|
|
|
service_ctx.group_v2_config.clone(),
|
2026-06-23 18:08:25 +03:00
|
|
|
)?;
|
2026-06-15 13:15:18 -07:00
|
|
|
let convo = GroupV2Convo {
|
|
|
|
|
convo_id,
|
2026-06-24 07:34:52 -07:00
|
|
|
conversation,
|
2026-06-15 13:15:18 -07:00
|
|
|
pending_invites: vec![],
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
convo.init(service_ctx)?;
|
|
|
|
|
|
|
|
|
|
Ok(convo)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Joiner side: ingest a de-mls welcome handed over the InboxV2 1-1
|
|
|
|
|
/// channel. `from_welcome` attaches MLS and applies the bundled
|
|
|
|
|
/// `ConversationSync` in one call; we then subscribe to the
|
|
|
|
|
/// conversation address and flush the join broadcast.
|
2026-06-24 07:34:52 -07:00
|
|
|
#[instrument(name = "groupv2.new_from_welcome", skip_all, fields(user_id = %service_ctx.mls_identity.display_name()))]
|
|
|
|
|
pub fn new_from_welcome<S: ExternalServices>(
|
2026-06-15 13:15:18 -07:00
|
|
|
service_ctx: &mut ServiceContext<S>,
|
|
|
|
|
welcome: &MemberWelcome,
|
2026-06-24 07:34:52 -07:00
|
|
|
) -> Result<Self, ChatError> {
|
2026-06-23 18:08:25 +03:00
|
|
|
let Some(conv) = Conversation::join(
|
2026-06-29 15:54:26 +03:00
|
|
|
&member_id(service_ctx),
|
2026-06-23 18:08:25 +03:00
|
|
|
&service_ctx.mls_provider,
|
2026-06-29 15:54:26 +03:00
|
|
|
&service_ctx.mls_identity,
|
2026-06-23 18:08:25 +03:00
|
|
|
&welcome.welcome_bytes,
|
|
|
|
|
&welcome.conversation_sync_bytes,
|
2026-06-29 15:54:26 +03:00
|
|
|
&make_consensus(),
|
2026-06-23 18:08:25 +03:00
|
|
|
make_scoring(),
|
|
|
|
|
rand_app_id(),
|
feat: GroupV2 through the threaded client, group roster, registry retry (#167)
* feat: expose GroupV2 through the threaded client
GroupV2 (de-mls) conversations were reachable only from Core, and every
conversation ran the hardcoded millisecond timer profile in group_v2.rs
(20-150 ms freeze/consensus windows), which cannot survive real network
latency. Make them reachable through ChatClient (as DirectV1 already is), with
timing that holds up over a real network.
- ChatClient::create_group_conversation(accounts) and
add_group_members(convo_id, accounts): resolve each account address to
its endorsed signer ids through the client-held directory, the same
resolution create_direct_conversation uses, and drive
Core::create_group_convo / group_add_member.
- GroupV2 timing/policy is injectable: ServiceContext carries a
de_mls::ConversationConfig (re-exported as GroupV2Config) defaulting
to the de-mls library defaults; Core::set_group_v2_config and the
builder's group_v2_config setter override it. The creator's phase
durations reach joiners inside the welcome's ConversationSync, so the
group runs the creator's phase timing.
- GroupV2Convo::add_member validates every member's key package before
proposing any add, skips members de-mls would silently not propose
(self, already in the group) instead of stranding a pending invite,
and flushes opened proposals even on a mid-batch failure, so a failed
batch cannot invite members behind the caller's back.
- The millisecond test profile moves into the test harnesses
(integration_tests_core's TestHarness, crates/client/tests/group_v2.rs).
- New client-level tests: three accounts on the in-process transport
create a group, a non-creator adds the third member, and messages fan
out with directory-verified senders; a batch containing a member with
no key package fails without inviting anyone.
* fix: class inbound DirectV1 joins as Private, not Group
The joiner of a DirectV1 (pairwise) conversation received it classed as
Group, because dispatch_to_inbox2 hardcoded ConversationClass::Group for
every InboxV2 join. DirectV1 welcomes (InviteType::GroupV1) and GroupV2
welcomes (InviteType::GroupV2) both arrive over InboxV2, so a plain 1:1
invite surfaced to the display layer as a group. ConversationClass is
documented as stable across protocol versions of the same conversation
shape, and DirectV1 is the pairwise shape, so its joiner must see Private.
- InboxV2::handle_frame returns the class alongside the convo:
InviteType::GroupV1 (the DirectV1 welcome carrier) yields Private,
InviteType::GroupV2 yields Group.
- dispatch_to_inbox2 propagates that class instead of hardcoding Group.
- direct_v1_by_account_address asserts the joiner sees Private.
* feat: expose a group's roster, deduped to one entry per account
The display layer needs a group's membership, but nothing exposed it:
de-mls holds the authoritative roster (MLS group state) with no public
accessor, and members added by other members stay invisible until they
send a message. Rebuilding the roster from observed messages would fork
state the crypto layer owns and be wrong exactly when a group grows.
- GroupConvo::members() returns each member's hex-encoded MLS
leaf-credential content, self included. GroupV2Convo delegates to
de-mls and guarantees self-inclusion; GroupV1Convo reads its openmls
leaves.
- Core::group_members(convo_id) mirrors group_add_member's dispatch: a
cached group yields its members, a direct conversation is an
UnsupportedFunction, otherwise the group is loaded.
- ChatClient::group_members returns Vec<GroupMember>, resolving each
member's account claim through the directory. A member whose account
claim is unconfirmable is listed by device with account None rather
than dropped: it is cryptographically in the group, only the account
claim is unproven. The credential parsing decode_sender did is
factored into parse_credential and shared by both, leaving
decode_sender's stricter drop semantics for message senders unchanged.
- Because resolve_device_ids fans an account out to every endorsed
device, an account whose devices all join surfaced once per device;
group_members dedups by account, keeping the first-seen device as the
account's representative. Members with no confirmed account stay
individual, keyed by their unique device key.
- Unit tests cover the tolerant-vs-drop split and the per-account dedup;
the three-member group integration test asserts the roster converges
after create and after each add, and a solo group lists only its
creator.
* feat: retry the registry on transient 5xx with backoff and jitter
The keypackage/account registry is reliable request-by-request but sheds concurrent bursts with a 5xx, so several instances registering at once each hard-failed on init. HttpRegistry's four calls now retry network errors and 5xx/429 with exponential backoff and full jitter (the jitter decorrelates concurrent publishers so their retries don't re-collide); 4xx and success return immediately. The total retry window is bounded to a few seconds.
* fix: mark InboxV2 key package last-resort so members can join multiple groups
A key package's init key is one-time-use: openmls deletes it after the first
welcome that consumes it. Each installation registers a single key package, so a
second group inviting the same member found no matching key package and rejected
the welcome with "welcome not addressed to this member", the flaky group add.
Mark the InboxV2 key package as last-resort (and advertise the extension in the
leaf capabilities, which key-package validation requires) so openmls retains the
init key, letting one key package admit an installation to any number of groups.
This reuses one init key for every join, trading per-join forward secrecy for
membership that just works. A TODO at the publish site tracks the intended
one-time key-package pool (the registry pops one per fetch, the client
replenishes) with last-resort as the exhaustion fallback (#169).
Add regression tests: a member joining two groups (core harness) and two peers
invited to several groups over the threaded client.
* fix: dedup list_conversations across the store and the in-memory cache
A DirectV1 join persists its conversation to the store and also caches it in
memory, so list_conversations saw it twice. It deduped with Vec::dedup, which
only drops consecutive repeats, over cached_convos' nondeterministic HashMap
order, so the duplicate survived whenever another cached conversation fell
between the two copies. list_conversations then intermittently returned a
conversation twice, and a consumer counting conversations (e.g. checking that a
peer joined a group while a direct chat already existed) saw a flaky count.
Dedup through a set so a conversation held in both stores is listed once
regardless of iteration order.
Add a DirectV1-then-GroupV2 regression test, which also covers key-package reuse
across conversation types.
* fix: dedup the GroupV2 add batch to avoid redundant fetches and duplicate invites
Both create_group_convo_v2 and group_add_member funnel through
GroupV2Convo::add_member, so a duplicate signer (an account that resolves
to the same signer twice, or a repeated account) cost a redundant
key-package fetch and a second Add proposal. The existing guard skipped
only self and already-committed members, which a within-batch duplicate
escapes because add_member opens a proposal the committed roster does not
yet reflect, stranding a pending_invite that can later fire a spurious
duplicate welcome.
Dedup the requested signers before fetching, and guard the add loop with a
membership set seeded from the roster and self, hoisting the per-iteration
members() call out of the loop.
* docs: correct the retry-budget and group-add doc comments
The retry-budget comment claimed the ~20s init IPC budget held even at the
worst-case sum, but that only holds on the load-shed path where each retry
returns fast; a fully unreachable registry costs up to MAX_RETRIES times
the reqwest timeout, which no retry budget can rescue. State both.
Reword add_group_members to name the proposal, commit, and welcome flow
rather than the unexplained "once the add commits".
* chore: allow clippy::question_mark in LocalBroadcaster::poll (Rust 1.97 FP)
Stable rolled to 1.97, whose clippy question_mark flags poll()'s match on
`self.shared.borrow().read(next)`. Its suggested `read(next)?` would drop the
RefCell Ref guard and dangle the returned reference, so the lint is a false
positive here. CI tracks floating stable (`rustup update stable`), so this is
pre-existing code newly flagged; suppress it to keep the branch green.
2026-07-09 20:02:04 +02:00
|
|
|
service_ctx.group_v2_config.clone(),
|
2026-06-23 18:08:25 +03:00
|
|
|
)?
|
|
|
|
|
else {
|
|
|
|
|
return Err(ChatError::generic("welcome not addressed to this member"));
|
|
|
|
|
};
|
2026-06-24 07:34:52 -07:00
|
|
|
|
|
|
|
|
let mut convo = GroupV2Convo {
|
|
|
|
|
convo_id: conv.id().to_string(),
|
|
|
|
|
conversation: conv,
|
|
|
|
|
pending_invites: vec![],
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
convo.init(service_ctx)?; // subscribe
|
|
|
|
|
convo.after_op(service_ctx)?; // flush join broadcast + schedule wakeup
|
|
|
|
|
|
|
|
|
|
Ok(convo)
|
2026-06-15 13:15:18 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn delivery_address_from_id(convo_id: &str) -> String {
|
|
|
|
|
let hash = Blake2b::<U6>::new()
|
|
|
|
|
.chain_update("delivery_addr|")
|
|
|
|
|
.chain_update(convo_id)
|
|
|
|
|
.finalize();
|
|
|
|
|
hex::encode(hash)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn init<S: ExternalServices>(
|
|
|
|
|
&self,
|
|
|
|
|
service_ctx: &mut ServiceContext<S>,
|
|
|
|
|
) -> Result<(), ChatError> {
|
|
|
|
|
// Configure the delivery service to listen for the required delivery addresses.
|
|
|
|
|
service_ctx
|
|
|
|
|
.ds
|
|
|
|
|
.subscribe(&Self::delivery_address_from_id(&self.convo_id))
|
|
|
|
|
.map_err(ChatError::generic)?;
|
|
|
|
|
Ok(())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub fn id(&self) -> ConversationIdRef<'_> {
|
|
|
|
|
&self.convo_id
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-19 08:43:55 -07:00
|
|
|
impl Identified for GroupV2Convo {
|
|
|
|
|
fn id(&self) -> ConversationIdRef<'_> {
|
|
|
|
|
&self.convo_id
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2026-06-15 13:15:18 -07:00
|
|
|
impl<S> Convo<S> for GroupV2Convo
|
|
|
|
|
where
|
|
|
|
|
S: ExternalServices,
|
|
|
|
|
{
|
|
|
|
|
#[instrument(name = "groupv2.send_content", skip_all, fields(user_id = %service_ctx.mls_identity.display_name(), content))]
|
|
|
|
|
fn send_content(
|
|
|
|
|
&mut self,
|
|
|
|
|
service_ctx: &mut super::ServiceContext<S>,
|
|
|
|
|
content: &[u8],
|
|
|
|
|
) -> Result<(), ChatError> {
|
2026-06-24 07:34:52 -07:00
|
|
|
self.conversation.send_message(
|
2026-06-23 18:08:25 +03:00
|
|
|
&service_ctx.mls_provider,
|
|
|
|
|
&service_ctx.mls_identity,
|
2026-06-29 15:54:26 +03:00
|
|
|
content.to_vec(),
|
2026-06-23 18:08:25 +03:00
|
|
|
)?;
|
2026-06-15 13:15:18 -07:00
|
|
|
self.after_op(service_ctx)?;
|
|
|
|
|
Ok(())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[instrument(name = "groupv2.handle_frame", skip_all, fields(user_id = %service_ctx.mls_identity.display_name()))]
|
|
|
|
|
fn handle_frame(
|
|
|
|
|
&mut self,
|
|
|
|
|
service_ctx: &mut super::ServiceContext<S>,
|
|
|
|
|
encoded_payload: EncryptedPayload,
|
|
|
|
|
) -> Result<ConvoOutcome, ChatError> {
|
|
|
|
|
let bytes = match encoded_payload.encryption {
|
|
|
|
|
Some(encrypted_payload::Encryption::Plaintext(pt)) => pt.payload,
|
|
|
|
|
_ => {
|
|
|
|
|
return Err(ChatError::generic("Expected plaintext"));
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
let frame = GroupV2Frame::decode(bytes.as_ref()).map_err(ChatError::generic)?;
|
|
|
|
|
let inner = match frame.payload {
|
|
|
|
|
Some(GroupV2Payload::DeMlsWrapper(b)) => b.to_vec(),
|
|
|
|
|
_ => return Ok(ConvoOutcome::empty(self.convo_id.clone())),
|
|
|
|
|
};
|
|
|
|
|
|
2026-06-24 07:34:52 -07:00
|
|
|
self.conversation.process_inbound(
|
2026-06-23 18:08:25 +03:00
|
|
|
&service_ctx.mls_provider,
|
2026-06-29 15:54:26 +03:00
|
|
|
&service_ctx.mls_identity,
|
2026-06-23 18:08:25 +03:00
|
|
|
&frame.sender_app_id,
|
|
|
|
|
&inner,
|
|
|
|
|
)?;
|
2026-06-24 07:34:52 -07:00
|
|
|
self.conversation
|
|
|
|
|
.poll(&service_ctx.mls_provider, &service_ctx.mls_identity);
|
2026-06-15 13:15:18 -07:00
|
|
|
let events = self.after_op(service_ctx)?; // route + publish + re-arm, returns events
|
|
|
|
|
|
|
|
|
|
match self.events_to_content(&events) {
|
|
|
|
|
Some(o) => Ok(o),
|
|
|
|
|
None => {
|
|
|
|
|
warn!("returning None as ConvoOutcome");
|
|
|
|
|
Ok(ConvoOutcome::empty(self.convo_id.to_string()))
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[instrument(name = "groupv2.wakeup", skip_all, fields(user_id = %ctx.mls_identity.display_name()))]
|
|
|
|
|
fn wakeup(&mut self, ctx: &mut ServiceContext<S>) -> Result<(), ChatError> {
|
|
|
|
|
info!(convo = %self.convo_id, "Wakeup");
|
2026-06-24 07:34:52 -07:00
|
|
|
|
|
|
|
|
let outcome = self.conversation.poll(&ctx.mls_provider, &ctx.mls_identity);
|
2026-06-15 13:15:18 -07:00
|
|
|
if outcome.leave_requested {
|
|
|
|
|
// Commit ejected us (or join expired). Real handling - drops
|
|
|
|
|
// this convo from its map;
|
|
|
|
|
tracing::warn!(convo = %self.convo_id, "conversation requested teardown");
|
|
|
|
|
}
|
|
|
|
|
self.after_op(ctx)?; // publish what poll produced + re-arm alarm
|
|
|
|
|
Ok(())
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl<S> GroupConvo<S> for GroupV2Convo
|
|
|
|
|
where
|
|
|
|
|
S: ExternalServices,
|
|
|
|
|
{
|
|
|
|
|
#[instrument(name = "groupv2.add_member", skip_all, fields(user_id = %service_ctx.mls_identity.display_name()))]
|
|
|
|
|
fn add_member(
|
|
|
|
|
&mut self,
|
|
|
|
|
service_ctx: &mut ServiceContext<S>,
|
|
|
|
|
members: &[IdentIdRef],
|
|
|
|
|
) -> Result<(), ChatError> {
|
feat: GroupV2 through the threaded client, group roster, registry retry (#167)
* feat: expose GroupV2 through the threaded client
GroupV2 (de-mls) conversations were reachable only from Core, and every
conversation ran the hardcoded millisecond timer profile in group_v2.rs
(20-150 ms freeze/consensus windows), which cannot survive real network
latency. Make them reachable through ChatClient (as DirectV1 already is), with
timing that holds up over a real network.
- ChatClient::create_group_conversation(accounts) and
add_group_members(convo_id, accounts): resolve each account address to
its endorsed signer ids through the client-held directory, the same
resolution create_direct_conversation uses, and drive
Core::create_group_convo / group_add_member.
- GroupV2 timing/policy is injectable: ServiceContext carries a
de_mls::ConversationConfig (re-exported as GroupV2Config) defaulting
to the de-mls library defaults; Core::set_group_v2_config and the
builder's group_v2_config setter override it. The creator's phase
durations reach joiners inside the welcome's ConversationSync, so the
group runs the creator's phase timing.
- GroupV2Convo::add_member validates every member's key package before
proposing any add, skips members de-mls would silently not propose
(self, already in the group) instead of stranding a pending invite,
and flushes opened proposals even on a mid-batch failure, so a failed
batch cannot invite members behind the caller's back.
- The millisecond test profile moves into the test harnesses
(integration_tests_core's TestHarness, crates/client/tests/group_v2.rs).
- New client-level tests: three accounts on the in-process transport
create a group, a non-creator adds the third member, and messages fan
out with directory-verified senders; a batch containing a member with
no key package fails without inviting anyone.
* fix: class inbound DirectV1 joins as Private, not Group
The joiner of a DirectV1 (pairwise) conversation received it classed as
Group, because dispatch_to_inbox2 hardcoded ConversationClass::Group for
every InboxV2 join. DirectV1 welcomes (InviteType::GroupV1) and GroupV2
welcomes (InviteType::GroupV2) both arrive over InboxV2, so a plain 1:1
invite surfaced to the display layer as a group. ConversationClass is
documented as stable across protocol versions of the same conversation
shape, and DirectV1 is the pairwise shape, so its joiner must see Private.
- InboxV2::handle_frame returns the class alongside the convo:
InviteType::GroupV1 (the DirectV1 welcome carrier) yields Private,
InviteType::GroupV2 yields Group.
- dispatch_to_inbox2 propagates that class instead of hardcoding Group.
- direct_v1_by_account_address asserts the joiner sees Private.
* feat: expose a group's roster, deduped to one entry per account
The display layer needs a group's membership, but nothing exposed it:
de-mls holds the authoritative roster (MLS group state) with no public
accessor, and members added by other members stay invisible until they
send a message. Rebuilding the roster from observed messages would fork
state the crypto layer owns and be wrong exactly when a group grows.
- GroupConvo::members() returns each member's hex-encoded MLS
leaf-credential content, self included. GroupV2Convo delegates to
de-mls and guarantees self-inclusion; GroupV1Convo reads its openmls
leaves.
- Core::group_members(convo_id) mirrors group_add_member's dispatch: a
cached group yields its members, a direct conversation is an
UnsupportedFunction, otherwise the group is loaded.
- ChatClient::group_members returns Vec<GroupMember>, resolving each
member's account claim through the directory. A member whose account
claim is unconfirmable is listed by device with account None rather
than dropped: it is cryptographically in the group, only the account
claim is unproven. The credential parsing decode_sender did is
factored into parse_credential and shared by both, leaving
decode_sender's stricter drop semantics for message senders unchanged.
- Because resolve_device_ids fans an account out to every endorsed
device, an account whose devices all join surfaced once per device;
group_members dedups by account, keeping the first-seen device as the
account's representative. Members with no confirmed account stay
individual, keyed by their unique device key.
- Unit tests cover the tolerant-vs-drop split and the per-account dedup;
the three-member group integration test asserts the roster converges
after create and after each add, and a solo group lists only its
creator.
* feat: retry the registry on transient 5xx with backoff and jitter
The keypackage/account registry is reliable request-by-request but sheds concurrent bursts with a 5xx, so several instances registering at once each hard-failed on init. HttpRegistry's four calls now retry network errors and 5xx/429 with exponential backoff and full jitter (the jitter decorrelates concurrent publishers so their retries don't re-collide); 4xx and success return immediately. The total retry window is bounded to a few seconds.
* fix: mark InboxV2 key package last-resort so members can join multiple groups
A key package's init key is one-time-use: openmls deletes it after the first
welcome that consumes it. Each installation registers a single key package, so a
second group inviting the same member found no matching key package and rejected
the welcome with "welcome not addressed to this member", the flaky group add.
Mark the InboxV2 key package as last-resort (and advertise the extension in the
leaf capabilities, which key-package validation requires) so openmls retains the
init key, letting one key package admit an installation to any number of groups.
This reuses one init key for every join, trading per-join forward secrecy for
membership that just works. A TODO at the publish site tracks the intended
one-time key-package pool (the registry pops one per fetch, the client
replenishes) with last-resort as the exhaustion fallback (#169).
Add regression tests: a member joining two groups (core harness) and two peers
invited to several groups over the threaded client.
* fix: dedup list_conversations across the store and the in-memory cache
A DirectV1 join persists its conversation to the store and also caches it in
memory, so list_conversations saw it twice. It deduped with Vec::dedup, which
only drops consecutive repeats, over cached_convos' nondeterministic HashMap
order, so the duplicate survived whenever another cached conversation fell
between the two copies. list_conversations then intermittently returned a
conversation twice, and a consumer counting conversations (e.g. checking that a
peer joined a group while a direct chat already existed) saw a flaky count.
Dedup through a set so a conversation held in both stores is listed once
regardless of iteration order.
Add a DirectV1-then-GroupV2 regression test, which also covers key-package reuse
across conversation types.
* fix: dedup the GroupV2 add batch to avoid redundant fetches and duplicate invites
Both create_group_convo_v2 and group_add_member funnel through
GroupV2Convo::add_member, so a duplicate signer (an account that resolves
to the same signer twice, or a repeated account) cost a redundant
key-package fetch and a second Add proposal. The existing guard skipped
only self and already-committed members, which a within-batch duplicate
escapes because add_member opens a proposal the committed roster does not
yet reflect, stranding a pending_invite that can later fire a spurious
duplicate welcome.
Dedup the requested signers before fetching, and guard the add loop with a
membership set seeded from the roster and self, hoisting the per-iteration
members() call out of the loop.
* docs: correct the retry-budget and group-add doc comments
The retry-budget comment claimed the ~20s init IPC budget held even at the
worst-case sum, but that only holds on the load-shed path where each retry
returns fast; a fully unreachable registry costs up to MAX_RETRIES times
the reqwest timeout, which no retry budget can rescue. State both.
Reword add_group_members to name the proposal, commit, and welcome flow
rather than the unexplained "once the add commits".
* chore: allow clippy::question_mark in LocalBroadcaster::poll (Rust 1.97 FP)
Stable rolled to 1.97, whose clippy question_mark flags poll()'s match on
`self.shared.borrow().read(next)`. Its suggested `read(next)?` would drop the
RefCell Ref guard and dangle the returned reference, so the lint is a false
positive here. CI tracks floating stable (`rustup update stable`), so this is
pre-existing code newly flagged; suppress it to keep the branch green.
2026-07-09 20:02:04 +02:00
|
|
|
// Dedup the requested signers up front: an account can resolve to the
|
|
|
|
|
// same signer twice, or a caller can repeat one, and a duplicate would
|
|
|
|
|
// otherwise cost a redundant key-package fetch here and a second Add
|
|
|
|
|
// proposal for a member already being added in this batch.
|
|
|
|
|
let mut seen = std::collections::HashSet::new();
|
|
|
|
|
let members: Vec<IdentIdRef> = members
|
|
|
|
|
.iter()
|
|
|
|
|
.copied()
|
|
|
|
|
.filter(|m| seen.insert(m.as_str().to_string()))
|
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
|
|
// Fetch and validate every key package before proposing any add, so a
|
|
|
|
|
// member with no key package fails the call before it opens proposals
|
|
|
|
|
// for the others. Members are signer ids; the de-mls member id must
|
|
|
|
|
// match the id of the IdentityProvider that generated the key package
|
|
|
|
|
// (its MLS leaf credential content — de-mls matches members by
|
|
|
|
|
// credential), so it is read from the fetched key package rather than
|
|
|
|
|
// assumed equal to the signer id.
|
|
|
|
|
let mut invites = Vec::with_capacity(members.len());
|
|
|
|
|
for member in &members {
|
2026-06-15 13:15:18 -07:00
|
|
|
let kp_bytes = service_ctx
|
|
|
|
|
.registry
|
2026-06-24 07:34:52 -07:00
|
|
|
.retrieve(member.as_str())
|
2026-06-15 13:15:18 -07:00
|
|
|
.map_err(ChatError::generic)?
|
|
|
|
|
.ok_or_else(|| ChatError::generic("No key package"))?;
|
2026-07-03 23:18:10 +02:00
|
|
|
let key_package_in = KeyPackageIn::tls_deserialize(&mut kp_bytes.as_slice())?;
|
|
|
|
|
let keypkg = key_package_in
|
|
|
|
|
.validate(service_ctx.mls_provider.crypto(), ProtocolVersion::Mls10)?;
|
|
|
|
|
let member_id = keypkg
|
|
|
|
|
.leaf_node()
|
|
|
|
|
.credential()
|
|
|
|
|
.serialized_content()
|
|
|
|
|
.to_vec();
|
feat: GroupV2 through the threaded client, group roster, registry retry (#167)
* feat: expose GroupV2 through the threaded client
GroupV2 (de-mls) conversations were reachable only from Core, and every
conversation ran the hardcoded millisecond timer profile in group_v2.rs
(20-150 ms freeze/consensus windows), which cannot survive real network
latency. Make them reachable through ChatClient (as DirectV1 already is), with
timing that holds up over a real network.
- ChatClient::create_group_conversation(accounts) and
add_group_members(convo_id, accounts): resolve each account address to
its endorsed signer ids through the client-held directory, the same
resolution create_direct_conversation uses, and drive
Core::create_group_convo / group_add_member.
- GroupV2 timing/policy is injectable: ServiceContext carries a
de_mls::ConversationConfig (re-exported as GroupV2Config) defaulting
to the de-mls library defaults; Core::set_group_v2_config and the
builder's group_v2_config setter override it. The creator's phase
durations reach joiners inside the welcome's ConversationSync, so the
group runs the creator's phase timing.
- GroupV2Convo::add_member validates every member's key package before
proposing any add, skips members de-mls would silently not propose
(self, already in the group) instead of stranding a pending invite,
and flushes opened proposals even on a mid-batch failure, so a failed
batch cannot invite members behind the caller's back.
- The millisecond test profile moves into the test harnesses
(integration_tests_core's TestHarness, crates/client/tests/group_v2.rs).
- New client-level tests: three accounts on the in-process transport
create a group, a non-creator adds the third member, and messages fan
out with directory-verified senders; a batch containing a member with
no key package fails without inviting anyone.
* fix: class inbound DirectV1 joins as Private, not Group
The joiner of a DirectV1 (pairwise) conversation received it classed as
Group, because dispatch_to_inbox2 hardcoded ConversationClass::Group for
every InboxV2 join. DirectV1 welcomes (InviteType::GroupV1) and GroupV2
welcomes (InviteType::GroupV2) both arrive over InboxV2, so a plain 1:1
invite surfaced to the display layer as a group. ConversationClass is
documented as stable across protocol versions of the same conversation
shape, and DirectV1 is the pairwise shape, so its joiner must see Private.
- InboxV2::handle_frame returns the class alongside the convo:
InviteType::GroupV1 (the DirectV1 welcome carrier) yields Private,
InviteType::GroupV2 yields Group.
- dispatch_to_inbox2 propagates that class instead of hardcoding Group.
- direct_v1_by_account_address asserts the joiner sees Private.
* feat: expose a group's roster, deduped to one entry per account
The display layer needs a group's membership, but nothing exposed it:
de-mls holds the authoritative roster (MLS group state) with no public
accessor, and members added by other members stay invisible until they
send a message. Rebuilding the roster from observed messages would fork
state the crypto layer owns and be wrong exactly when a group grows.
- GroupConvo::members() returns each member's hex-encoded MLS
leaf-credential content, self included. GroupV2Convo delegates to
de-mls and guarantees self-inclusion; GroupV1Convo reads its openmls
leaves.
- Core::group_members(convo_id) mirrors group_add_member's dispatch: a
cached group yields its members, a direct conversation is an
UnsupportedFunction, otherwise the group is loaded.
- ChatClient::group_members returns Vec<GroupMember>, resolving each
member's account claim through the directory. A member whose account
claim is unconfirmable is listed by device with account None rather
than dropped: it is cryptographically in the group, only the account
claim is unproven. The credential parsing decode_sender did is
factored into parse_credential and shared by both, leaving
decode_sender's stricter drop semantics for message senders unchanged.
- Because resolve_device_ids fans an account out to every endorsed
device, an account whose devices all join surfaced once per device;
group_members dedups by account, keeping the first-seen device as the
account's representative. Members with no confirmed account stay
individual, keyed by their unique device key.
- Unit tests cover the tolerant-vs-drop split and the per-account dedup;
the three-member group integration test asserts the roster converges
after create and after each add, and a solo group lists only its
creator.
* feat: retry the registry on transient 5xx with backoff and jitter
The keypackage/account registry is reliable request-by-request but sheds concurrent bursts with a 5xx, so several instances registering at once each hard-failed on init. HttpRegistry's four calls now retry network errors and 5xx/429 with exponential backoff and full jitter (the jitter decorrelates concurrent publishers so their retries don't re-collide); 4xx and success return immediately. The total retry window is bounded to a few seconds.
* fix: mark InboxV2 key package last-resort so members can join multiple groups
A key package's init key is one-time-use: openmls deletes it after the first
welcome that consumes it. Each installation registers a single key package, so a
second group inviting the same member found no matching key package and rejected
the welcome with "welcome not addressed to this member", the flaky group add.
Mark the InboxV2 key package as last-resort (and advertise the extension in the
leaf capabilities, which key-package validation requires) so openmls retains the
init key, letting one key package admit an installation to any number of groups.
This reuses one init key for every join, trading per-join forward secrecy for
membership that just works. A TODO at the publish site tracks the intended
one-time key-package pool (the registry pops one per fetch, the client
replenishes) with last-resort as the exhaustion fallback (#169).
Add regression tests: a member joining two groups (core harness) and two peers
invited to several groups over the threaded client.
* fix: dedup list_conversations across the store and the in-memory cache
A DirectV1 join persists its conversation to the store and also caches it in
memory, so list_conversations saw it twice. It deduped with Vec::dedup, which
only drops consecutive repeats, over cached_convos' nondeterministic HashMap
order, so the duplicate survived whenever another cached conversation fell
between the two copies. list_conversations then intermittently returned a
conversation twice, and a consumer counting conversations (e.g. checking that a
peer joined a group while a direct chat already existed) saw a flaky count.
Dedup through a set so a conversation held in both stores is listed once
regardless of iteration order.
Add a DirectV1-then-GroupV2 regression test, which also covers key-package reuse
across conversation types.
* fix: dedup the GroupV2 add batch to avoid redundant fetches and duplicate invites
Both create_group_convo_v2 and group_add_member funnel through
GroupV2Convo::add_member, so a duplicate signer (an account that resolves
to the same signer twice, or a repeated account) cost a redundant
key-package fetch and a second Add proposal. The existing guard skipped
only self and already-committed members, which a within-batch duplicate
escapes because add_member opens a proposal the committed roster does not
yet reflect, stranding a pending_invite that can later fire a spurious
duplicate welcome.
Dedup the requested signers before fetching, and guard the add loop with a
membership set seeded from the roster and self, hoisting the per-iteration
members() call out of the loop.
* docs: correct the retry-budget and group-add doc comments
The retry-budget comment claimed the ~20s init IPC budget held even at the
worst-case sum, but that only holds on the load-shed path where each retry
returns fast; a fully unreachable registry costs up to MAX_RETRIES times
the reqwest timeout, which no retry budget can rescue. State both.
Reword add_group_members to name the proposal, commit, and welcome flow
rather than the unexplained "once the add commits".
* chore: allow clippy::question_mark in LocalBroadcaster::poll (Rust 1.97 FP)
Stable rolled to 1.97, whose clippy question_mark flags poll()'s match on
`self.shared.borrow().read(next)`. Its suggested `read(next)?` would drop the
RefCell Ref guard and dangle the returned reference, so the lint is a false
positive here. CI tracks floating stable (`rustup update stable`), so this is
pre-existing code newly flagged; suppress it to keep the branch green.
2026-07-09 20:02:04 +02:00
|
|
|
invites.push((member_id, member.to_string(), kp_bytes));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// pending_invites drives welcome delivery: after_op forwards a welcome
|
|
|
|
|
// only to a joiner recorded here. Record a member only if de-mls will
|
|
|
|
|
// actually propose its add — recording one it silently drops strands an
|
|
|
|
|
// entry that a later re-join can match, firing a spurious duplicate
|
|
|
|
|
// welcome. de-mls drops self and members already in the group; and since
|
|
|
|
|
// add_member only opens a proposal, the committed roster won't reflect a
|
|
|
|
|
// member added earlier in this same loop, so the set tracks those too.
|
|
|
|
|
// Seed it with the roster and self, insert as we go, and one check
|
|
|
|
|
// covers all three.
|
|
|
|
|
let mut roster: std::collections::HashSet<Vec<u8>> =
|
|
|
|
|
self.conversation.members()?.into_iter().collect();
|
|
|
|
|
roster.insert(self.conversation.member_id_bytes().to_vec());
|
|
|
|
|
|
|
|
|
|
let mut result = Ok(());
|
|
|
|
|
for (member_id, signer_id, kp_bytes) in invites {
|
|
|
|
|
if !roster.insert(member_id.clone()) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
self.pending_invites.push((member_id.clone(), signer_id));
|
|
|
|
|
if let Err(e) = self.conversation.add_member(
|
2026-06-23 18:08:25 +03:00
|
|
|
&service_ctx.mls_provider,
|
|
|
|
|
&service_ctx.mls_identity,
|
2026-07-03 23:18:10 +02:00
|
|
|
&member_id,
|
2026-06-29 15:54:26 +03:00
|
|
|
&kp_bytes,
|
feat: GroupV2 through the threaded client, group roster, registry retry (#167)
* feat: expose GroupV2 through the threaded client
GroupV2 (de-mls) conversations were reachable only from Core, and every
conversation ran the hardcoded millisecond timer profile in group_v2.rs
(20-150 ms freeze/consensus windows), which cannot survive real network
latency. Make them reachable through ChatClient (as DirectV1 already is), with
timing that holds up over a real network.
- ChatClient::create_group_conversation(accounts) and
add_group_members(convo_id, accounts): resolve each account address to
its endorsed signer ids through the client-held directory, the same
resolution create_direct_conversation uses, and drive
Core::create_group_convo / group_add_member.
- GroupV2 timing/policy is injectable: ServiceContext carries a
de_mls::ConversationConfig (re-exported as GroupV2Config) defaulting
to the de-mls library defaults; Core::set_group_v2_config and the
builder's group_v2_config setter override it. The creator's phase
durations reach joiners inside the welcome's ConversationSync, so the
group runs the creator's phase timing.
- GroupV2Convo::add_member validates every member's key package before
proposing any add, skips members de-mls would silently not propose
(self, already in the group) instead of stranding a pending invite,
and flushes opened proposals even on a mid-batch failure, so a failed
batch cannot invite members behind the caller's back.
- The millisecond test profile moves into the test harnesses
(integration_tests_core's TestHarness, crates/client/tests/group_v2.rs).
- New client-level tests: three accounts on the in-process transport
create a group, a non-creator adds the third member, and messages fan
out with directory-verified senders; a batch containing a member with
no key package fails without inviting anyone.
* fix: class inbound DirectV1 joins as Private, not Group
The joiner of a DirectV1 (pairwise) conversation received it classed as
Group, because dispatch_to_inbox2 hardcoded ConversationClass::Group for
every InboxV2 join. DirectV1 welcomes (InviteType::GroupV1) and GroupV2
welcomes (InviteType::GroupV2) both arrive over InboxV2, so a plain 1:1
invite surfaced to the display layer as a group. ConversationClass is
documented as stable across protocol versions of the same conversation
shape, and DirectV1 is the pairwise shape, so its joiner must see Private.
- InboxV2::handle_frame returns the class alongside the convo:
InviteType::GroupV1 (the DirectV1 welcome carrier) yields Private,
InviteType::GroupV2 yields Group.
- dispatch_to_inbox2 propagates that class instead of hardcoding Group.
- direct_v1_by_account_address asserts the joiner sees Private.
* feat: expose a group's roster, deduped to one entry per account
The display layer needs a group's membership, but nothing exposed it:
de-mls holds the authoritative roster (MLS group state) with no public
accessor, and members added by other members stay invisible until they
send a message. Rebuilding the roster from observed messages would fork
state the crypto layer owns and be wrong exactly when a group grows.
- GroupConvo::members() returns each member's hex-encoded MLS
leaf-credential content, self included. GroupV2Convo delegates to
de-mls and guarantees self-inclusion; GroupV1Convo reads its openmls
leaves.
- Core::group_members(convo_id) mirrors group_add_member's dispatch: a
cached group yields its members, a direct conversation is an
UnsupportedFunction, otherwise the group is loaded.
- ChatClient::group_members returns Vec<GroupMember>, resolving each
member's account claim through the directory. A member whose account
claim is unconfirmable is listed by device with account None rather
than dropped: it is cryptographically in the group, only the account
claim is unproven. The credential parsing decode_sender did is
factored into parse_credential and shared by both, leaving
decode_sender's stricter drop semantics for message senders unchanged.
- Because resolve_device_ids fans an account out to every endorsed
device, an account whose devices all join surfaced once per device;
group_members dedups by account, keeping the first-seen device as the
account's representative. Members with no confirmed account stay
individual, keyed by their unique device key.
- Unit tests cover the tolerant-vs-drop split and the per-account dedup;
the three-member group integration test asserts the roster converges
after create and after each add, and a solo group lists only its
creator.
* feat: retry the registry on transient 5xx with backoff and jitter
The keypackage/account registry is reliable request-by-request but sheds concurrent bursts with a 5xx, so several instances registering at once each hard-failed on init. HttpRegistry's four calls now retry network errors and 5xx/429 with exponential backoff and full jitter (the jitter decorrelates concurrent publishers so their retries don't re-collide); 4xx and success return immediately. The total retry window is bounded to a few seconds.
* fix: mark InboxV2 key package last-resort so members can join multiple groups
A key package's init key is one-time-use: openmls deletes it after the first
welcome that consumes it. Each installation registers a single key package, so a
second group inviting the same member found no matching key package and rejected
the welcome with "welcome not addressed to this member", the flaky group add.
Mark the InboxV2 key package as last-resort (and advertise the extension in the
leaf capabilities, which key-package validation requires) so openmls retains the
init key, letting one key package admit an installation to any number of groups.
This reuses one init key for every join, trading per-join forward secrecy for
membership that just works. A TODO at the publish site tracks the intended
one-time key-package pool (the registry pops one per fetch, the client
replenishes) with last-resort as the exhaustion fallback (#169).
Add regression tests: a member joining two groups (core harness) and two peers
invited to several groups over the threaded client.
* fix: dedup list_conversations across the store and the in-memory cache
A DirectV1 join persists its conversation to the store and also caches it in
memory, so list_conversations saw it twice. It deduped with Vec::dedup, which
only drops consecutive repeats, over cached_convos' nondeterministic HashMap
order, so the duplicate survived whenever another cached conversation fell
between the two copies. list_conversations then intermittently returned a
conversation twice, and a consumer counting conversations (e.g. checking that a
peer joined a group while a direct chat already existed) saw a flaky count.
Dedup through a set so a conversation held in both stores is listed once
regardless of iteration order.
Add a DirectV1-then-GroupV2 regression test, which also covers key-package reuse
across conversation types.
* fix: dedup the GroupV2 add batch to avoid redundant fetches and duplicate invites
Both create_group_convo_v2 and group_add_member funnel through
GroupV2Convo::add_member, so a duplicate signer (an account that resolves
to the same signer twice, or a repeated account) cost a redundant
key-package fetch and a second Add proposal. The existing guard skipped
only self and already-committed members, which a within-batch duplicate
escapes because add_member opens a proposal the committed roster does not
yet reflect, stranding a pending_invite that can later fire a spurious
duplicate welcome.
Dedup the requested signers before fetching, and guard the add loop with a
membership set seeded from the roster and self, hoisting the per-iteration
members() call out of the loop.
* docs: correct the retry-budget and group-add doc comments
The retry-budget comment claimed the ~20s init IPC budget held even at the
worst-case sum, but that only holds on the load-shed path where each retry
returns fast; a fully unreachable registry costs up to MAX_RETRIES times
the reqwest timeout, which no retry budget can rescue. State both.
Reword add_group_members to name the proposal, commit, and welcome flow
rather than the unexplained "once the add commits".
* chore: allow clippy::question_mark in LocalBroadcaster::poll (Rust 1.97 FP)
Stable rolled to 1.97, whose clippy question_mark flags poll()'s match on
`self.shared.borrow().read(next)`. Its suggested `read(next)?` would drop the
RefCell Ref guard and dangle the returned reference, so the lint is a false
positive here. CI tracks floating stable (`rustup update stable`), so this is
pre-existing code newly flagged; suppress it to keep the branch green.
2026-07-09 20:02:04 +02:00
|
|
|
) {
|
|
|
|
|
self.pending_invites.pop();
|
|
|
|
|
result = Err(e.into());
|
|
|
|
|
break;
|
|
|
|
|
}
|
2026-06-15 13:15:18 -07:00
|
|
|
}
|
feat: GroupV2 through the threaded client, group roster, registry retry (#167)
* feat: expose GroupV2 through the threaded client
GroupV2 (de-mls) conversations were reachable only from Core, and every
conversation ran the hardcoded millisecond timer profile in group_v2.rs
(20-150 ms freeze/consensus windows), which cannot survive real network
latency. Make them reachable through ChatClient (as DirectV1 already is), with
timing that holds up over a real network.
- ChatClient::create_group_conversation(accounts) and
add_group_members(convo_id, accounts): resolve each account address to
its endorsed signer ids through the client-held directory, the same
resolution create_direct_conversation uses, and drive
Core::create_group_convo / group_add_member.
- GroupV2 timing/policy is injectable: ServiceContext carries a
de_mls::ConversationConfig (re-exported as GroupV2Config) defaulting
to the de-mls library defaults; Core::set_group_v2_config and the
builder's group_v2_config setter override it. The creator's phase
durations reach joiners inside the welcome's ConversationSync, so the
group runs the creator's phase timing.
- GroupV2Convo::add_member validates every member's key package before
proposing any add, skips members de-mls would silently not propose
(self, already in the group) instead of stranding a pending invite,
and flushes opened proposals even on a mid-batch failure, so a failed
batch cannot invite members behind the caller's back.
- The millisecond test profile moves into the test harnesses
(integration_tests_core's TestHarness, crates/client/tests/group_v2.rs).
- New client-level tests: three accounts on the in-process transport
create a group, a non-creator adds the third member, and messages fan
out with directory-verified senders; a batch containing a member with
no key package fails without inviting anyone.
* fix: class inbound DirectV1 joins as Private, not Group
The joiner of a DirectV1 (pairwise) conversation received it classed as
Group, because dispatch_to_inbox2 hardcoded ConversationClass::Group for
every InboxV2 join. DirectV1 welcomes (InviteType::GroupV1) and GroupV2
welcomes (InviteType::GroupV2) both arrive over InboxV2, so a plain 1:1
invite surfaced to the display layer as a group. ConversationClass is
documented as stable across protocol versions of the same conversation
shape, and DirectV1 is the pairwise shape, so its joiner must see Private.
- InboxV2::handle_frame returns the class alongside the convo:
InviteType::GroupV1 (the DirectV1 welcome carrier) yields Private,
InviteType::GroupV2 yields Group.
- dispatch_to_inbox2 propagates that class instead of hardcoding Group.
- direct_v1_by_account_address asserts the joiner sees Private.
* feat: expose a group's roster, deduped to one entry per account
The display layer needs a group's membership, but nothing exposed it:
de-mls holds the authoritative roster (MLS group state) with no public
accessor, and members added by other members stay invisible until they
send a message. Rebuilding the roster from observed messages would fork
state the crypto layer owns and be wrong exactly when a group grows.
- GroupConvo::members() returns each member's hex-encoded MLS
leaf-credential content, self included. GroupV2Convo delegates to
de-mls and guarantees self-inclusion; GroupV1Convo reads its openmls
leaves.
- Core::group_members(convo_id) mirrors group_add_member's dispatch: a
cached group yields its members, a direct conversation is an
UnsupportedFunction, otherwise the group is loaded.
- ChatClient::group_members returns Vec<GroupMember>, resolving each
member's account claim through the directory. A member whose account
claim is unconfirmable is listed by device with account None rather
than dropped: it is cryptographically in the group, only the account
claim is unproven. The credential parsing decode_sender did is
factored into parse_credential and shared by both, leaving
decode_sender's stricter drop semantics for message senders unchanged.
- Because resolve_device_ids fans an account out to every endorsed
device, an account whose devices all join surfaced once per device;
group_members dedups by account, keeping the first-seen device as the
account's representative. Members with no confirmed account stay
individual, keyed by their unique device key.
- Unit tests cover the tolerant-vs-drop split and the per-account dedup;
the three-member group integration test asserts the roster converges
after create and after each add, and a solo group lists only its
creator.
* feat: retry the registry on transient 5xx with backoff and jitter
The keypackage/account registry is reliable request-by-request but sheds concurrent bursts with a 5xx, so several instances registering at once each hard-failed on init. HttpRegistry's four calls now retry network errors and 5xx/429 with exponential backoff and full jitter (the jitter decorrelates concurrent publishers so their retries don't re-collide); 4xx and success return immediately. The total retry window is bounded to a few seconds.
* fix: mark InboxV2 key package last-resort so members can join multiple groups
A key package's init key is one-time-use: openmls deletes it after the first
welcome that consumes it. Each installation registers a single key package, so a
second group inviting the same member found no matching key package and rejected
the welcome with "welcome not addressed to this member", the flaky group add.
Mark the InboxV2 key package as last-resort (and advertise the extension in the
leaf capabilities, which key-package validation requires) so openmls retains the
init key, letting one key package admit an installation to any number of groups.
This reuses one init key for every join, trading per-join forward secrecy for
membership that just works. A TODO at the publish site tracks the intended
one-time key-package pool (the registry pops one per fetch, the client
replenishes) with last-resort as the exhaustion fallback (#169).
Add regression tests: a member joining two groups (core harness) and two peers
invited to several groups over the threaded client.
* fix: dedup list_conversations across the store and the in-memory cache
A DirectV1 join persists its conversation to the store and also caches it in
memory, so list_conversations saw it twice. It deduped with Vec::dedup, which
only drops consecutive repeats, over cached_convos' nondeterministic HashMap
order, so the duplicate survived whenever another cached conversation fell
between the two copies. list_conversations then intermittently returned a
conversation twice, and a consumer counting conversations (e.g. checking that a
peer joined a group while a direct chat already existed) saw a flaky count.
Dedup through a set so a conversation held in both stores is listed once
regardless of iteration order.
Add a DirectV1-then-GroupV2 regression test, which also covers key-package reuse
across conversation types.
* fix: dedup the GroupV2 add batch to avoid redundant fetches and duplicate invites
Both create_group_convo_v2 and group_add_member funnel through
GroupV2Convo::add_member, so a duplicate signer (an account that resolves
to the same signer twice, or a repeated account) cost a redundant
key-package fetch and a second Add proposal. The existing guard skipped
only self and already-committed members, which a within-batch duplicate
escapes because add_member opens a proposal the committed roster does not
yet reflect, stranding a pending_invite that can later fire a spurious
duplicate welcome.
Dedup the requested signers before fetching, and guard the add loop with a
membership set seeded from the roster and self, hoisting the per-iteration
members() call out of the loop.
* docs: correct the retry-budget and group-add doc comments
The retry-budget comment claimed the ~20s init IPC budget held even at the
worst-case sum, but that only holds on the load-shed path where each retry
returns fast; a fully unreachable registry costs up to MAX_RETRIES times
the reqwest timeout, which no retry budget can rescue. State both.
Reword add_group_members to name the proposal, commit, and welcome flow
rather than the unexplained "once the add commits".
* chore: allow clippy::question_mark in LocalBroadcaster::poll (Rust 1.97 FP)
Stable rolled to 1.97, whose clippy question_mark flags poll()'s match on
`self.shared.borrow().read(next)`. Its suggested `read(next)?` would drop the
RefCell Ref guard and dangle the returned reference, so the lint is a false
positive here. CI tracks floating stable (`rustup update stable`), so this is
pre-existing code newly flagged; suppress it to keep the branch green.
2026-07-09 20:02:04 +02:00
|
|
|
// Flush even on a mid-loop failure: proposals already opened must be
|
|
|
|
|
// published and the wakeup re-armed, or they sit dormant until an
|
|
|
|
|
// unrelated frame drives the conversation.
|
|
|
|
|
let flushed = self.after_op(service_ctx).map(drop);
|
|
|
|
|
result.and(flushed)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn members(&self) -> Result<Vec<Vec<u8>>, ChatError> {
|
|
|
|
|
// Guarantee the local member is listed so callers see the full roster.
|
|
|
|
|
let mut members = self.conversation.members()?;
|
|
|
|
|
let self_id = self.conversation.member_id_bytes().to_vec();
|
|
|
|
|
if !members.contains(&self_id) {
|
|
|
|
|
members.push(self_id);
|
|
|
|
|
}
|
|
|
|
|
Ok(members)
|
2026-06-15 13:15:18 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// fn conversation_state(&self) -> Result<ConversationState, ChatError> {
|
|
|
|
|
// Ok(self
|
|
|
|
|
// .conversation
|
|
|
|
|
// .as_ref()
|
|
|
|
|
// .map(|c| c.state())
|
|
|
|
|
// .unwrap_or(ConversationState::PendingJoin))
|
|
|
|
|
// }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl GroupV2Convo {
|
|
|
|
|
fn after_op<S: ExternalServices>(
|
|
|
|
|
&mut self,
|
|
|
|
|
service_ctx: &mut ServiceContext<S>,
|
|
|
|
|
) -> Result<Vec<ConversationEvent>, ChatError> {
|
|
|
|
|
// Pull everything first (these are &self, take-all):
|
2026-06-24 07:34:52 -07:00
|
|
|
let events = self.conversation.drain_events();
|
|
|
|
|
let outbound = self.conversation.drain_outbound(); // Vec<de_mls::session::Outbound>
|
|
|
|
|
let wakeup = self.conversation.next_wakeup_in();
|
2026-06-15 13:15:18 -07:00
|
|
|
|
2026-07-03 23:18:10 +02:00
|
|
|
// 1. Route welcomes for joiners WE invited (event fires on every member
|
|
|
|
|
// now). The welcome travels to the joiner's signer id (where its
|
|
|
|
|
// InboxV2 listens), not its de-mls member id.
|
2026-06-15 13:15:18 -07:00
|
|
|
for evt in &events {
|
|
|
|
|
if let ConversationEvent::WelcomeReady { welcome, .. } = evt {
|
|
|
|
|
for joiner in &welcome.joiner_identities {
|
2026-07-03 23:18:10 +02:00
|
|
|
if let Some(i) = self.pending_invites.iter().position(|(p, _)| p == joiner) {
|
|
|
|
|
let (_, signer_id) = self.pending_invites.remove(i);
|
2026-06-15 13:15:18 -07:00
|
|
|
crate::inbox_v2::invite_user_v2(
|
|
|
|
|
&mut service_ctx.ds,
|
2026-07-03 23:18:10 +02:00
|
|
|
&IdentId::new(signer_id),
|
2026-06-15 13:15:18 -07:00
|
|
|
welcome,
|
|
|
|
|
)?;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// 2. Publish
|
|
|
|
|
for out in outbound {
|
|
|
|
|
let frame = GroupV2Frame {
|
|
|
|
|
payload: Some(GroupV2Payload::DeMlsWrapper(out.payload.into())),
|
|
|
|
|
sender_app_id: out.sender, // was pkt.app_id
|
|
|
|
|
};
|
|
|
|
|
let payload = AddressedEncryptedPayload {
|
|
|
|
|
delivery_address: Self::delivery_address_from_id(&out.conversation_id),
|
|
|
|
|
data: EncryptedPayload {
|
|
|
|
|
encryption: Some(encrypted_payload::Encryption::Plaintext(Plaintext {
|
|
|
|
|
payload: frame.encode_to_vec().into(),
|
|
|
|
|
})),
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
service_ctx
|
|
|
|
|
.ds
|
|
|
|
|
.publish(payload.into_envelope(out.conversation_id))
|
|
|
|
|
.map_err(ChatError::generic)?;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// 3. Re-arm the alarm with the conversation's earliest deadline.
|
|
|
|
|
if let Some(d) = wakeup {
|
|
|
|
|
service_ctx
|
|
|
|
|
.wakeup_service
|
|
|
|
|
.wakeup_in(d, self.convo_id.clone());
|
|
|
|
|
}
|
|
|
|
|
Ok(events)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn events_to_content(&self, events: &[ConversationEvent]) -> Option<ConvoOutcome> {
|
|
|
|
|
events.iter().find_map(|evt| match evt {
|
2026-06-29 15:54:26 +03:00
|
|
|
ConversationEvent::ConversationMessage(AppMessageProto {
|
2026-06-15 13:15:18 -07:00
|
|
|
payload: Some(app_message::Payload::ConversationMessage(cm)),
|
2026-06-23 18:08:25 +03:00
|
|
|
}) => Some(ConvoOutcome {
|
|
|
|
|
convo_id: self.convo_id.clone(),
|
|
|
|
|
content: Some(Content {
|
|
|
|
|
bytes: cm.message.clone(),
|
|
|
|
|
encoded_credential: cm.sender.clone(),
|
|
|
|
|
}),
|
|
|
|
|
}),
|
2026-06-15 13:15:18 -07:00
|
|
|
_ => None,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
use prost::{Oneof, bytes::Bytes};
|
|
|
|
|
|
|
|
|
|
#[derive(Clone, PartialEq, Message)]
|
|
|
|
|
pub struct GroupV2Frame {
|
|
|
|
|
#[prost(oneof = "GroupV2Payload", tags = "2, 3")]
|
|
|
|
|
pub payload: Option<GroupV2Payload>,
|
|
|
|
|
#[prost(bytes = "vec", tag = "4")]
|
|
|
|
|
pub sender_app_id: Vec<u8>,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[derive(Clone, PartialEq, Oneof)]
|
|
|
|
|
pub enum GroupV2Payload {
|
|
|
|
|
#[prost(message, tag = "2")]
|
|
|
|
|
DeMlsWrapper(Bytes),
|
|
|
|
|
#[prost(message, tag = "3")]
|
|
|
|
|
MlsCommitMessage(Bytes),
|
|
|
|
|
}
|