NIP-57はzapsを定義します。これは、Lightning paymentをNostr identityやcontentへ結び付ける方法です。zap対応invoiceのrequestと、支払い後にwalletが公開するreceipt eventの両方を標準化しています。

仕組み

  1. clientは、profile metadataまたは対象イベント上のzapタグから受信者のLNURL endpointを見つける
  2. clientは、relayではなく受信者のLNURL callbackへ、署名済みkind 9734 zap requestを送る
  3. ユーザーがinvoiceを支払う
  4. 受信者のwallet serverが、zap requestで指定されたrelayへkind 9735 zap receiptを公開する
  5. clientがzapを検証し、表示する

Zap Request（kind 9734）

zap requestは、支払者と意図した対象を識別する署名済みイベントです。通常は次を含みます。

  • pタグ - 受信者pubkey
  • eタグ - zap対象のイベント（任意）
  • amountタグ - millisatoshis単位の金額
  • relaysタグ - receiptを公開するrelay一覧

addressable contentでは、eタグの代わりに、または併用してaタグを使えます。任意のkタグは対象kindを記録します。

Zap Receipt（kind 9735）

支払い確認後に、受信者のwallet serverが公開します。内容は次の通りです。

  • descriptionタグ内に元のzap request
  • bolt11タグに支払済みinvoice
  • preimageタグで支払いを証明

clientは、受信者のLNURL nostrPubkey、invoice amount、元のzap requestに照らしてreceiptを検証する必要があります。その検証なしでは、receiptは単なる主張にすぎません。

信頼モデルとトレードオフ

zapsは、支払いをsocial graph内で可視化できる点で有用ですが、receipt自体は依然として受信者のwallet infrastructureが作成します。仕様自身も、zap receiptは普遍的なpayment proofではないと述べています。最も正確には、「zap requestに結び付いたinvoiceが支払われた」というwallet署名付きの陳述として理解すべきです。

妥当なclientは、receiptをzapとして表示する前に4つを確認すべきです。receiptの署名が受信者のLNURL responseでadvertiseされたnostrPubkeyに一致すること、bolt11 invoice amountが埋め込まれたzap request内のamountタグと一致すること、invoiceのdescription hashが文字列化されたzap requestへコミットしていること、preimageがinvoiceのpayment_hashへハッシュされることです。これをせずに集計済みzap数を表示するclientは、偽造kind 9735イベントを出す攻撃者に簡単に騙されます。

Private zapsとAnonymous zaps

private zapsは、その上に機密性レイヤーを追加します。送信者はzap requestのcontentを受信者向けに暗号化し、外側requestへanonタグを含めることで、relay networkには支払い対象だけを見せつつ、添えたメモは読ませません。anonymous zapではさらに一歩進み、clientがzap request自体のために新しいephemeral keypairを生成するため、receiptは支払いがあったことを示しても、受信者はそのzapを送信者の長期pubkeyへ結び付けられません。

Zap GoalsとSplits

NIP-57は、NIP-75で定義されるzap-goal systemの土台です。goalは、目標額とreceiptを数えるrelay setを宣言するkind 9041イベントであり、clientは一致するkind 9735イベントの検証済みbolt11 amountを合計して進捗を集計します。

NIP付録で定義されたzap splitsでは、受信者が複数の重み付きzapタグを持つkind 0 profileを公開でき、1回のzap paymentを複数のpubkeyへ原子的に分配できます。Amethyst、Damus、noStrudelはsplit-payingをend-to-endで実装しています。

Primary sources:

Mentioned in:

See also: