osmaczko 5d02196e6a

fix: deliver DirectV1 Welcome to account-associated invitees (routing_id) ...

DirectV1 over a shared key-package registry (HttpRegistry) could not deliver
the MLS Welcome to an account-associated invitee. Key-package resolution
requires the shared address to be the account key (the account directory
resolves it to the device key HttpRegistry stores the package under), but the
Welcome was routed to, and the invitee's InboxV2 subscribed and gated on, the
credential id (hex of the DelegateCredential TLV). The two strings never
matched, so the Welcome fell through the dispatch gate to PayloadOutcome::Empty
and the invitee never joined. EphemeralRegistry hid this by keying key-packages
on the credential id, collapsing both halves onto one string.

Decouple the 1:1 routing identity from the credential identity:

- Add a defaulted IdentityProvider::routing_id() (defaults to id()).
- DelegateSigner returns its account address from routing_id() once associated.
- Core::assemble feeds InboxV2 routing_id() instead of id(); the MLS credential,
  member id, sender id, and decode_sender keep reading id(), so MLS membership
  and sender attribution are unchanged.

Add a regression test (direct_v1_associated_invitee_receives_welcome) over a
DeviceKeyedRegistry that keys key-packages by the device verifying key, as the
deployed HttpRegistry does; it fails without routing_id and passes with it.

2026-06-27 13:58:05 +02:00

..

src

fix: deliver DirectV1 Welcome to account-associated invitees (routing_id)

2026-06-27 13:58:05 +02:00

Cargo.toml

Update Context to accept External Identity Provider. (#127)

2026-06-10 06:59:04 -07:00