mirror of
https://github.com/logos-messaging/libchat.git
synced 2026-06-30 21:20:09 +00:00
9fb2ae741c
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() -> IdentId (defaults to id()). - DelegateSigner derives routing_id() and account_addr() from its own credential: once associated, the account address is read from the DelegateCredential TLV; otherwise routing_id() falls back to the credential id. The association is stored only in the credential, never in a separate field. - 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.