Open
Conversation
Add intent URL parsing, resolution, and handling pipeline: Models: - IntentActionItem: SendTon, SendJetton, SendNft action types - IntentRequestEvent: Transaction, SignData, Action intent events - IntentResponse: Transaction, SignData, and error response types - BatchedIntentEvent: Multiple intents in a single event Handlers: - IntentParser: URL parsing, validation, wire-to-model mapping - IntentResolver: Action items to TransactionRequest conversion, action URL fetching with jetton/NFT message building - IntentHandler: Orchestrator with parse-resolve-emulate-emit flow, approval/rejection methods, pending connect request management Integration: - TonWalletKit: 10 public intent API methods - BridgeManager: sendIntentResponse with ephemeral SessionCrypto - Android bridge: Full intent API surface with event listeners
1. Action URL response parsing: handle { action_type, action } format
per spec instead of wire intent format. sendTransaction actions
return standard messages array, signData returns typed payload.
2. Query param: use 'address' instead of 'wallet' when appending
wallet address to action URL (spec requirement).
3. Wire response format: convert SDK response models to spec format
before sending via bridge:
- txIntent/signMsg: { result: '<boc>', id }
- signIntent: { result: { signature, address, timestamp, domain, payload }, id }
- error: { error: { code, message }, id }
4. SignData response: add echoed payload field per spec requirement
(MakeSignDataIntentResponseSuccess = SignDataResponseSuccess).
… multi-item intents
…e error messaging
…ning and adjust related logic in IntentHandler
…gy, add validation for missing actionUrl
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This reverts commit 7d54d81.
…e' and 'signMsgDraft'
…ntParser for bridge session integration
…alletV5R1 adapters
For signOnly (signMsgDraft) delivery mode, the TonConnect spec expects
{ result: { internal_boc: "<boc>" } } instead of { result: "<boc>" }
so that the SDK's signMessageDraftParser can deserialize it correctly.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…nternal_boc format
…t naming Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix fetchActionUrl body stream double-consume bug - Remove dead EventStore draft cases and unused removeEvent - Remove draft types from EventType (never stored) - Use static IntentParser instance for isIntentUrl pre-init - Make onIntentRequest/removeIntentRequestCallback async - Stop mutating input events in approveBatchedIntent - Extract signAndSendTransaction/signSignData/resolveAndApproveAction helpers - Rewrite approveBatchedIntent to reuse helpers (156→40 lines) - Replace per-item as any casts with single as unknown as Feature[] - Consistent Draft naming for bridge args types - Add default case to IntentParser switch - Remove unused _clientPubKeyHex param from decryptPayload
Intent features are advertised via walletManifest/deviceInfo config, not hardcoded in adapters. The external e2e test dApp validates features against @tonconnect/protocol which doesn't know intent feature names yet.
Adds a required `type: 'batched'` field so callers can distinguish
BatchedIntentEvent from IntentRequestEvent via a proper discriminated
union instead of duck-typing ('intents' in event).
Populates the field in both BatchedIntentEvent construction sites in
IntentHandler and updates spec helpers accordingly.
getSupportedFeatures() can return intent feature names (SendTransactionDraft, SignMessageDraft, SendActionDraft) for internal intent discovery. However DeviceInfo.features in the TonConnect connect response must only contain standard protocol feature names (SendTransaction, SignData), as dApps validate against the @tonconnect/protocol spec. getDeviceInfoForWallet() now filters walletSupportedFeatures to only standard TonConnect feature names before placing them in DeviceInfo.
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.
No description provided.