fix: subscribe InboxV2 on routing_id, not the credential id#155
Draft
osmaczko wants to merge 1 commit into
Draft
fix: subscribe InboxV2 on routing_id, not the credential id#155osmaczko wants to merge 1 commit into
osmaczko wants to merge 1 commit into
Conversation
osmaczko
force-pushed
the
fix/directv1-account-routing
branch
from
5d02196 to
9fb2ae7
Compare
InboxV2 gated inbound on the credential id (hex of the DelegateCredential TLV), but a sender addresses the Welcome to the invitee's routing address, which the account directory resolves to the device key HttpRegistry stores the key-package under. The two differ, so the Welcome fell through to PayloadOutcome::Empty and the invitee never joined. EphemeralRegistry hid this by keying key-packages on the credential id. This is routing-vs-credential, not account-vs-device: the TLV-wrapped credential differs from the address even when account key == device key (testnet today), so a client associating over HttpRegistry hits it; only the in-process EphemeralRegistry path is unaffected. Add IdentityProvider::routing_id() (defaults to id()); DelegateSigner derives it from its credential (the account address once associated, else id()); Core::assemble subscribes InboxV2 on routing_id(). id() still backs the MLS credential, member id, sender id, and decode_sender, so membership and attribution are unchanged. Regression test direct_v1_welcome_routes_on_routing_id over a device-key-keyed registry (as HttpRegistry) fails without the fix.
osmaczko
force-pushed
the
fix/directv1-account-routing
branch
from
9fb2ae7 to
75435b3
Compare
osmaczko
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
InboxV2 gated inbound on the credential id (hex of the DelegateCredential TLV),
but a sender addresses the Welcome to the invitee's routing address, which the
account directory resolves to the device key HttpRegistry stores the key-package
under. The two differ, so the Welcome fell through to PayloadOutcome::Empty and
the invitee never joined. EphemeralRegistry hid this by keying key-packages on
the credential id.
This is routing-vs-credential, not account-vs-device: the TLV-wrapped credential
differs from the address even when account key == device key (testnet today), so
a client associating over HttpRegistry hits it; only the in-process
EphemeralRegistry path is unaffected.
Add IdentityProvider::routing_id() (defaults to id()); DelegateSigner derives it
from its credential (the account address once associated, else id());
Core::assemble subscribes InboxV2 on routing_id(). id() still backs the MLS
credential, member id, sender id, and decode_sender, so membership and
attribution are unchanged. Regression test direct_v1_welcome_routes_on_routing_id
over a device-key-keyed registry (as HttpRegistry) fails without the fix.