Repository navigation
fix(transport): stop signing throwaway events during oversized size probing - #98
Merged
ContextVM-org merged 3 commits intoSep 17, 2026
Merged
Conversation
…robing measurePublishedMcpMessageSize built and signed the real event via the configured signer just to measure its serialized byte length, discarding the signature. Every progress-token request paid an extra getPublicKey+signEvent round trip (invisible for local signers; an approval prompt for NIP-07/NIP-55, a billed operation for NIP-46), and the oversized chunk-size binary search multiplied that ~16x. The server response path had the same problem via outbound-response-router. Sizing never needs a valid signature: pubkey/id/sig are fixed-length hex and NIP-44 v2 padding is deterministic given plaintext length, so a placeholder event serializes to a byte-identical length. Build it directly and drop the now-unused buildPublishedMcpEvent wrapper; the real send path (createSignedNostrEvent) is untouched, and the NIP-44 65 535-byte plaintext-cap throw handling in the binary search still works because encryptMessage still runs.
…rams type splitStringByByteSize encoded one character at a time (a TextEncoder allocation per char), costing ~65ms per MB of oversized payload on both client and server send paths. Encode once and split on byte boundaries, backing off over UTF-8 continuation bytes; identical output and error contract, ~60x faster. Also hoist resolveSafeOversizedChunkSize's params object, previously declared identically in the base transport, both outbound deps interfaces, and tests, into one exported ResolveSafeOversizedChunkSizeParams.
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
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.
measurePublishedMcpMessageSize built and signed the real event via the configured signer just to measure its serialized byte length, discarding the signature. Every progress-token request paid an extra getPublicKey+signEvent round trip (invisible for local signers; an approval prompt for NIP-07/NIP-55, a billed operation for NIP-46), and the oversized chunk-size binary search multiplied that ~16x. The server response path had the same problem via outbound-response-router.
Sizing never needs a valid signature: pubkey/id/sig are fixed-length hex and NIP-44 v2 padding is deterministic given plaintext length, so a placeholder event serializes to a byte-identical length. Build it directly and drop the now-unused buildPublishedMcpEvent wrapper; the real send path (createSignedNostrEvent) is untouched, and the NIP-44 65 535-byte plaintext-cap throw handling in the binary search still works because encryptMessage still runs.