bLIP: XXX
Title: LN P2P Protocol for forwarding LNURL-pay requests
Status: Active
Author: Hampus Sjöberg <hampus.sjoberg@protonmail.com>
Created: 2023-08-16
License: CC0
This bLIP describes a way to forward LNURL-pay requests from an LNURL-server ("Server") to a Lightning node ("Client") using Lightning P2P messaging.
The LNURL-pay JSON requests and responses SHOULD be forwarded verbatim
(with exception of the callback property) and the client is expected to return
valid LNURL-pay responses back.
In the case where the recipient client is offline, the server MAY return an LNURL error message back to the Requester.
[Requester] <--HTTP--> [LNURL-pay Server] <--LN P2P--> [Client]
This bLIP is licensed under the CC0 license.
Communication between the Client's Lightning node and the Server's Lightning
node is happening on the LN P2P code 33459.
Upon receiving an incoming LNURL-pay request, the Server MUST send a JSON stringified message to the Client. There are two requests and two responses as per the LNURL-pay protocol.
Refer to LNURL-pay LUD-06 and its extensions for specifics regarding each request and response.
interface ILnurlPayForwardP2PMessage {
id: number;
request:
| "LNURLPAY_REQUEST1"
| "LNURLPAY_REQUEST1_RESPONSE"
| "LNURLPAY_REQUEST2"
| "LNURLPAY_REQUEST2_RESPONSE";
data: any; // Data/JSON as defined in LUD-06 and other related LUDs
metadata: {
[key: string]: any;
};
}In order to keep track of requests and their corresponding responses, Server
MUST assign a unique id for each Request and Reponse bundle that the Client
MUST adhere to.
Server and Client MAY add additional metadata in the metadata prop.
This is the incoming LNURL-pay request and thus doesn't contain any data for the Client.
{
id: 1,
request: "LNURLPAY_REQUEST1",
data: {},
metadata: {}
}This is initial response providing payment information.
{
id: 1,
request: "LNURLPAY_REQUEST1_RESPONSE",
data: { // From LUD-06
tag: "payRequest",
minSendable: 1000,
maxSendable: 10000,
metadata: JSON.stringify([
["text/plain", "Cheers!"],
]),
callback: "" // MAY be ommitted as the Client may not know which endpoint Server will meet the Requester on
},
metadata: {}
}The Client might not know on what callback URL the LNURL-pay server is
supposed to meet the Requester on. Thus the Server MAY alter
LNURLPAY_REQUEST1_RESPONSE in order to provide the correct callback URL.
This is the final request from the Requester. Requester will make a GET request Server via the callback URL.
{
id: 2,
request: "LNURLPAY_REQUEST2",
data: { // From LUD-06
amount: 1000
},
metadata: {}
}This is the final response and will contain the BOLT11 code for the Requester.
{
id: 2,
request: "LNURLPAY_REQUEST2_RESPONSE",
data: { // From LUD-06
pr: "lnbc1abcdef",
routes: []
},
metadata: {}
}By how LNURLPAY_REQUEST1 is designed, the Client may not know which LNURL-pay
code or Lightning Address the incoming request is regarding.
The Server MAY provide additional metadata in the request:
{
id: 1,
request: "LNURLPAY_REQUEST1",
data: {},
metadata: {
lightningAddress: "satoshi@lightning.com" // and/or
lnurlPay: "LNURL123" // and/or
lud17: "lnurlp:https://domain.com/pay"
}
}In the case Client does not respond within a reasonable time, the Server SHUOLD stop waiting and terminate the request.