thunder-bridge 1.0.0 → 1.3.0

package/dist/server.d.cts

@@ -1,5 +1,44 @@
-import { T as ThunderBridge } from './rail-CL9QkiHo.cjs';
-export { m as BlindLightningRailConfig, n as blindLightningRail } from './rail-CL9QkiHo.cjs';
+import { T as ThunderBridge } from './rail-DZzlN-bi.cjs';
+export { m as BlindLightningRailConfig, N as NwcConnection, n as NwcInvoice, o as NwcRailConfig, p as NwcVerifyConfig, q as Resolved, r as askWallet, s as blindLightningRail, u as invoiceFrom, v as nwcConnection, w as nwcHoldInvoice, x as nwcInvoice, y as nwcPay, z as nwcRail, A as nwcSettlement, D as nwcVerifyEndpoint, E as nwcVerifyUrl } from './rail-DZzlN-bi.cjs';
+
+/** The wallet's own LUD-21 URL and the hash its preimage has to match */
+interface Relayed {
+    url: string;
+    hash: string;
+}
+interface LightningVerifyConfig {
+    /** The secret the sealed wallet URL was made with, and nothing else uses it */
+    secret: string;
+    /**
+     * How often you want the gateway to ask, in seconds. It goes out as
+     * `Cache-Control: max-age`, so the pace is yours rather than the operator's.
+     * Five by default, which is what a Lightning checkout wants
+     */
+    pollEverySecs?: number;
+}
+/**
+ * A verify endpoint of your own that asks the recipient's wallet for you, so the
+ * gateway polls you and never the wallet.
+ *
+ * `relayedVerifyUrl` seals the wallet's own LUD-21 URL into the query with your
+ * secret, so what the gateway stores and replicates is opaque: not the wallet's
+ * host, not which provider the recipient uses, nothing but a blob it cannot read.
+ * This handler unseals it, asks the wallet, and answers the same LUD-21 shape.
+ *
+ * It relays rather than decides. The preimage still comes from the recipient's
+ * own server and still has to hash to the payment hash, so standing between the
+ * two buys privacy and pacing without becoming something anyone has to trust.
+ *
+ * A wallet it cannot reach answers `502` rather than "not settled", because those
+ * are different claims and only one of them is true. The gateway logs a failed
+ * poll and asks again, which is what a broken relay should look like.
+ */
+declare function lightningVerifyEndpoint(config: LightningVerifyConfig): (request: Request) => Promise<Response>;
+/**
+ * The URL to hand the gateway instead of the wallet's own, with the wallet's
+ * sealed inside it. Point it at wherever `lightningVerifyEndpoint` is mounted
+ */
+declare function relayedVerifyUrl(endpoint: string, wallet: Relayed, secret: string): Promise<string>;
 
 interface TriggerConfig {
     /** The gateway that quotes the addresses and mints the invoice */
@@ -18,6 +57,12 @@ interface TriggerConfig {
     secret: string;
     /** Groups every payment here so `followTrigger` can watch the place, keep it off the QR */
     watchSecret?: string;
+    /**
+     * How many settlements of this place the gateway keeps replayable past the hour
+     * it would otherwise forget them in, up to the ceiling its operator set. What a
+     * page that opens later still gets to see. Needs `watchSecret`
+     */
+    replay?: number;
     /** Override when a proxy hides the public URL from the request, no trailing slash */
     baseUrl?: string;
     /**
@@ -61,43 +106,4 @@ interface Minted {
  */
 declare function lnurlPayEndpoint(config: TriggerConfig): (request: Request) => Promise<Response>;
 
-/** The wallet's own LUD-21 URL and the hash its preimage has to match */
-interface Relayed {
-    url: string;
-    hash: string;
-}
-interface LightningVerifyConfig {
-    /** The secret the sealed wallet URL was made with, and nothing else uses it */
-    secret: string;
-    /**
-     * How often you want the gateway to ask, in seconds. It goes out as
-     * `Cache-Control: max-age`, so the pace is yours rather than the operator's.
-     * Five by default, which is what a Lightning checkout wants
-     */
-    pollEverySecs?: number;
-}
-/**
- * A verify endpoint of your own that asks the recipient's wallet for you, so the
- * gateway polls you and never the wallet.
- *
- * `relayedVerifyUrl` seals the wallet's own LUD-21 URL into the query with your
- * secret, so what the gateway stores and replicates is opaque: not the wallet's
- * host, not which provider the recipient uses, nothing but a blob it cannot read.
- * This handler unseals it, asks the wallet, and answers the same LUD-21 shape.
- *
- * It relays rather than decides. The preimage still comes from the recipient's
- * own server and still has to hash to the payment hash, so standing between the
- * two buys privacy and pacing without becoming something anyone has to trust.
- *
- * A wallet it cannot reach answers `502` rather than "not settled", because those
- * are different claims and only one of them is true. The gateway logs a failed
- * poll and asks again, which is what a broken relay should look like.
- */
-declare function lightningVerifyEndpoint(config: LightningVerifyConfig): (request: Request) => Promise<Response>;
-/**
- * The URL to hand the gateway instead of the wallet's own, with the wallet's
- * sealed inside it. Point it at wherever `lightningVerifyEndpoint` is mounted
- */
-declare function relayedVerifyUrl(endpoint: string, wallet: Relayed, secret: string): Promise<string>;
-
 export { type LightningVerifyConfig, type Minted, type Relayed, type TriggerConfig, lightningVerifyEndpoint, lnurlPayEndpoint, relayedVerifyUrl };

package/dist/server.d.ts

@@ -1,5 +1,44 @@
-import { T as ThunderBridge } from './rail-CL9QkiHo.js';
-export { m as BlindLightningRailConfig, n as blindLightningRail } from './rail-CL9QkiHo.js';
+import { T as ThunderBridge } from './rail-DZzlN-bi.js';
+export { m as BlindLightningRailConfig, N as NwcConnection, n as NwcInvoice, o as NwcRailConfig, p as NwcVerifyConfig, q as Resolved, r as askWallet, s as blindLightningRail, u as invoiceFrom, v as nwcConnection, w as nwcHoldInvoice, x as nwcInvoice, y as nwcPay, z as nwcRail, A as nwcSettlement, D as nwcVerifyEndpoint, E as nwcVerifyUrl } from './rail-DZzlN-bi.js';
+
+/** The wallet's own LUD-21 URL and the hash its preimage has to match */
+interface Relayed {
+    url: string;
+    hash: string;
+}
+interface LightningVerifyConfig {
+    /** The secret the sealed wallet URL was made with, and nothing else uses it */
+    secret: string;
+    /**
+     * How often you want the gateway to ask, in seconds. It goes out as
+     * `Cache-Control: max-age`, so the pace is yours rather than the operator's.
+     * Five by default, which is what a Lightning checkout wants
+     */
+    pollEverySecs?: number;
+}
+/**
+ * A verify endpoint of your own that asks the recipient's wallet for you, so the
+ * gateway polls you and never the wallet.
+ *
+ * `relayedVerifyUrl` seals the wallet's own LUD-21 URL into the query with your
+ * secret, so what the gateway stores and replicates is opaque: not the wallet's
+ * host, not which provider the recipient uses, nothing but a blob it cannot read.
+ * This handler unseals it, asks the wallet, and answers the same LUD-21 shape.
+ *
+ * It relays rather than decides. The preimage still comes from the recipient's
+ * own server and still has to hash to the payment hash, so standing between the
+ * two buys privacy and pacing without becoming something anyone has to trust.
+ *
+ * A wallet it cannot reach answers `502` rather than "not settled", because those
+ * are different claims and only one of them is true. The gateway logs a failed
+ * poll and asks again, which is what a broken relay should look like.
+ */
+declare function lightningVerifyEndpoint(config: LightningVerifyConfig): (request: Request) => Promise<Response>;
+/**
+ * The URL to hand the gateway instead of the wallet's own, with the wallet's
+ * sealed inside it. Point it at wherever `lightningVerifyEndpoint` is mounted
+ */
+declare function relayedVerifyUrl(endpoint: string, wallet: Relayed, secret: string): Promise<string>;
 
 interface TriggerConfig {
     /** The gateway that quotes the addresses and mints the invoice */
@@ -18,6 +57,12 @@ interface TriggerConfig {
     secret: string;
     /** Groups every payment here so `followTrigger` can watch the place, keep it off the QR */
     watchSecret?: string;
+    /**
+     * How many settlements of this place the gateway keeps replayable past the hour
+     * it would otherwise forget them in, up to the ceiling its operator set. What a
+     * page that opens later still gets to see. Needs `watchSecret`
+     */
+    replay?: number;
     /** Override when a proxy hides the public URL from the request, no trailing slash */
     baseUrl?: string;
     /**
@@ -61,43 +106,4 @@ interface Minted {
  */
 declare function lnurlPayEndpoint(config: TriggerConfig): (request: Request) => Promise<Response>;
 
-/** The wallet's own LUD-21 URL and the hash its preimage has to match */
-interface Relayed {
-    url: string;
-    hash: string;
-}
-interface LightningVerifyConfig {
-    /** The secret the sealed wallet URL was made with, and nothing else uses it */
-    secret: string;
-    /**
-     * How often you want the gateway to ask, in seconds. It goes out as
-     * `Cache-Control: max-age`, so the pace is yours rather than the operator's.
-     * Five by default, which is what a Lightning checkout wants
-     */
-    pollEverySecs?: number;
-}
-/**
- * A verify endpoint of your own that asks the recipient's wallet for you, so the
- * gateway polls you and never the wallet.
- *
- * `relayedVerifyUrl` seals the wallet's own LUD-21 URL into the query with your
- * secret, so what the gateway stores and replicates is opaque: not the wallet's
- * host, not which provider the recipient uses, nothing but a blob it cannot read.
- * This handler unseals it, asks the wallet, and answers the same LUD-21 shape.
- *
- * It relays rather than decides. The preimage still comes from the recipient's
- * own server and still has to hash to the payment hash, so standing between the
- * two buys privacy and pacing without becoming something anyone has to trust.
- *
- * A wallet it cannot reach answers `502` rather than "not settled", because those
- * are different claims and only one of them is true. The gateway logs a failed
- * poll and asks again, which is what a broken relay should look like.
- */
-declare function lightningVerifyEndpoint(config: LightningVerifyConfig): (request: Request) => Promise<Response>;
-/**
- * The URL to hand the gateway instead of the wallet's own, with the wallet's
- * sealed inside it. Point it at wherever `lightningVerifyEndpoint` is mounted
- */
-declare function relayedVerifyUrl(endpoint: string, wallet: Relayed, secret: string): Promise<string>;
-
 export { type LightningVerifyConfig, type Minted, type Relayed, type TriggerConfig, lightningVerifyEndpoint, lnurlPayEndpoint, relayedVerifyUrl };