You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
The current specification has a couple places where an external URL is required (
incomingPayment
andpaymentPointer
). 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 befetch
ed, and thepaymentPointer
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 text was updated successfully, but these errors were encountered: