fix(transport): mirror request wrap kind in routeTargeted responses - #79
Merged
Merged
Conversation
routeTargeted() chose the gift-wrap kind without consulting the wrap kind recorded for the client's request event, while route() mirrors it on both send paths. A targeted response (e.g. explicit-gating -32042/-32043 errors) could therefore answer an ephemeral-wrapped request (kind 21059) with a relay-stored gift wrap (kind 1059) in GiftWrapMode.OPTIONAL when the session lacks the ephemeral capability tag. Look up the recorded wrap kind via a non-destructive getEventRoute() and pass it as fallbackWrapKind, matching route()'s policy. Callers passing an unknown event ID degrade to the previous default.
sendNotification() and the CEP-22 accept frame chose the gift-wrap kind without the request's wrap kind, so progress notifications and oversized accept frames answered an ephemeral-wrapped request (kind 21059) with a relay-stored gift wrap (kind 1059) in GiftWrapMode.OPTIONAL when the session lacks the ephemeral capability tag — the same divergence fixed for routeTargeted(). - sendNotification() mirrors via the correlated request's route and accepts an explicit wrapKindHint for callers without a route yet - the oversized accept frame threads the inbound request's wrap kind through that hint (no route exists at start-frame time) - route()'s send-failure re-register restores the full route, including the signed request event exposed via getNostrRequestEvent() Adds a path-agnostic invariant e2e: a raw ephemeral-wrapped client with no capability tags never receives a persistent (1059) wrap in OPTIONAL mode, across response, notification, and targeted forms.
- extract mirrorRequestWrapKind() into capability-negotiator and replace
the two hand-rolled ternaries in the inbound coordinator (identical
semantics: policy pins win, otherwise mirror the request's kind)
- add a debug tripwire in sendMcpMessage when an OPTIONAL-mode encrypted
send carries no wrap-kind hint, so future unmirrored send paths are
grep-visible in debug logs
- LruCache: evict correctly when the eldest key is falsy ('')
- delete unused isHex64()
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.
routeTargeted() chose the gift-wrap kind without consulting the wrap kind recorded for the client's request event, while route() mirrors it on both send paths. A targeted response (e.g. explicit-gating -32042/-32043 errors) could therefore answer an ephemeral-wrapped request (kind 21059) with a relay-stored gift wrap (kind 1059) in GiftWrapMode.OPTIONAL when the session lacks the ephemeral capability tag.
Look up the recorded wrap kind via a non-destructive getEventRoute() and pass it as fallbackWrapKind, matching route()'s policy. Callers passing an unknown event ID degrade to the previous default.