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
..
2026-05-20 13:18:25 -07:00
2026-05-20 13:18:25 -07:00
2026-03-24 18:21:00 -07:00

Core

Crates in this directory will one day be separated into a separate shared repository.

They could be moved now, but it's desirable to have a monorepo setup at this time.

These crates MUST not depend on any code outside of this folder.