2xx without a readable receipt: make on-chain confirmation the default when an RPC is available
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 15/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- blockchain, payments
調査の方向性
The payload names no files. Start from the SDK code that handles a 2xx response, the confirmAuthorization option and usdcAuthorizationCheck, and the payment.confirmed field. The issue calls for auto-wiring the on-chain check when a public client or RPC URL is given, and returning a 2xx without a receipt as confirmed = false instead of resending. Done means Glim-style, CoinMarketCap-style and genuine-failure tests pass, and the settlement_pending / settlement_unknown invariant still holds. Treat this as design work and discuss the approach before coding.
索引モデルが issue の本文から書いたものです。
説明
Some merchants deliver the resource with a 200 but no standard PAYMENT-RESPONSE:
- Glim (surf.cascade.fyi) sends none;
- CoinMarketCap and JustaName send non-standard ones.
Without confirmAuthorization, the client resends the same proof. The merchant then refuses it (402 invalid_payload / "nonce already used"), and the content that was already paid for is lost. With confirmAuthorization, the SDK checks authorizationState on-chain and returns the response (confirmedOnChain: true).
The MCP server now enables this by default (agent-pay-mcp 0.2.0, confirmOnChain). Proposal for the SDK:
- When the caller passes a public client or RPC URL for the network, wire
usdcAuthorizationCheckautomatically. - Otherwise, return a 2xx without a receipt with
payment.confirmed = falseinstead of resending. The resource was delivered, and a resend can only be refused.
This needs care with the never-sign-twice invariant (settlement_pending / settlement_unknown). Tests should cover Glim-style (no header), CoinMarketCap-style (non-standard) and a genuine failure.
- 主要言語
- TypeScript
- スター
- 0
- フォーク
- 0
- 平均マージ
- 3時間 51分
- マージ済み PR（30日）
- 3
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
DeepFirstHQ/deepfirstsearch のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 50/100
DeepFirstHQ/deepfirstsearch#41 · コメント 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
DeepFirstHQ/deepfirstsearch#40 · コメント 2 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 38/100
DeepFirstHQ/deepfirstsearch の issue をすべて見る
似ている issue
-
documentation good first issue hacktoberfest help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
libredb/libredb-studio#1756 ·
メンテナーはふだん 1 日以内に返信
-
state:triage-needed
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
lingdojo/kana-dojo#32365 · コメント 1 件 · リアクション 5 件 ·
メンテナーはふだん 1 日以内に返信
-
friction
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
kentcdodds/kody#3706 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
copperheadhq/copperhead#378 ·
メンテナーはふだん 1 日以内に返信