The current specification has a couple places where an external URL is required (incomingPayment and paymentPointer). While in theory a URL could be something other than HTTP (e.g., file://, bitcoin://, etc.), the spec's wording seems to strongly imply that it will always be something that can be fetched, and the paymentPointer is defined as an Open Payments API entry which I believe requires a server component.
I'm not exactly sure how to resolve this, but it feels like leaning into digital currencies peer to peer nature and decentralization would be beneficial.
Use case: Website hosted on S3/IPFS with no server infrastructure wants to provide an enhanced experience to users who make a donation with a digital currency, and it may utilize the browser's built-in wallet for payment verification.
The current specification has a couple places where an external URL is required (
incomingPaymentandpaymentPointer). While in theory a URL could be something other thanHTTP(e.g.,file://,bitcoin://, etc.), the spec's wording seems to strongly imply that it will always be something that can befetched, and thepaymentPointeris defined as an Open Payments API entry which I believe requires a server component.I'm not exactly sure how to resolve this, but it feels like leaning into digital currencies peer to peer nature and decentralization would be beneficial.
Use case: Website hosted on S3/IPFS with no server infrastructure wants to provide an enhanced experience to users who make a donation with a digital currency, and it may utilize the browser's built-in wallet for payment verification.