Re: Proposed XMPP Extension: Payment Required
JC Brand <[email protected]> Fri, 12 Jun 2026 17:12:04 +0200
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0975795742818755912== Content-Type: multipart/alternative; boundary="------------mrbE9Nev747UYck8PJDJT4Fh" Content-Language: en-US This is a multi-part message in MIME format. --------------mrbE9Nev747UYck8PJDJT4Fh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/24/26 15:27, techmetx11 via Standards wrote: > Nice XEP. I wonder if Monero could be added to this? Thanks, and sorry for the delayed response. After the latest revision a payment option is just a payment URI identified by its scheme. So a monero: URI will work with a client (or wallet) that recognizes that scheme. Different payment types have different proofs, so that's an additional nuance to keep in mind. With Monero you can't verify from a public txid (amounts and recipients aren't on-chain) so Monero relies on an out-of-band transaction proof. So concerning the proof-types, the issuing service should declare the proof type as "proof" (and not "txid") on the option and the payer echoes it (together with the proof itself). > Also, another note: If the client sent a payment but the server is > waiting for it to confirm > properly (and it doesn't really care about the payment proof), How > would we signal to > the client to wait a certain amount of time before it tries again? Good catch, this is something I missed. The latest revision adds a payment-pending reason plus a retry-after attribute (seconds), returned with stanza error type of "wait" (per RFC 6120). The payer backs off for the indicated interval and retries the same session without re-paying. JC > On 4/24/26 11:26 AM, Daniel Gultsch wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Payment Required >> Abstract: >> This specification defines an XMPP protocol extension that enables >> services to require payment before granting access to a resource. It >> provides a payment-system neutral invoice format supporting multiple >> concurrent payment options, including bank transfers (SEPA, IBAN, UPI) >> and instant-settlement networks (Lightning Network), and integrates >> with the existing CAPTCHA challenge mechanism defined in XEP-0158. >> >> URL: https://xmpp.org/extensions/inbox/payment-required.html >> >> The Council will decide in the next two weeks whether to accept this >> proposal as an official XEP. >> _______________________________________________ >> Standards mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected] --------------mrbE9Nev747UYck8PJDJT4Fh Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF= -8"> </head> <body> <div class=3D"moz-cite-prefix">On 4/24/26 15:27, techmetx11 via Standards wrote:<br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]">Nice XEP. I wonder if Monero could be added to this?=C2=A0</blockquote> <br> Thanks, and sorry for the delayed response.<br> <br> After the latest revision a payment option is just a payment URI identified by its scheme.<br> So a monero: URI will work with a client (or wallet) that recognizes that scheme.<br> Different payment types have different proofs, so that's an additional nuance to keep in mind.<br> With Monero you can't verify from a public txid (amounts and recipients aren't on-chain)<br> so Monero relies on an out-of-band transaction proof. So concerning the proof-types,<br> the issuing service should declare the proof type as "proof" (and not "txid") on the option<br> and the payer echoes it (together with the proof itself).=C2=A0=C2=A0= <br> <br> <blockquote type=3D"cite" cite=3D"mid:[email protected]">Also, another note: If the client sent a payment but the server is waiting for it to confirm<br> properly (and it doesn't really care about the payment proof), How would we signal to<br> the client to wait a certain amount of time before it tries again?=C2=A0</blockquote> <p><br> Good catch, this is something I missed. The latest revision adds a payment-pending<br> reason plus a retry-after attribute (seconds), returned with stanza error type of "wait"<br> (per RFC 6120). The payer backs off for the indicated interval and retries the same session<br> without re-paying.<br> <br> JC<br> <br> </p> <blockquote type=3D"cite" cite=3D"mid:[email protected]">On 4/24/26 11:26 AM, Daniel Gultsch wrote: <br> <blockquote type=3D"cite">The XMPP Extensions Editor has received a proposal for a new XEP. <br> <br> Title: Payment Required <br> Abstract: <br> This specification defines an XMPP protocol extension that enables <br> services to require payment before granting access to a resource. It <br> provides a payment-system neutral invoice format supporting multiple <br> concurrent payment options, including bank transfers (SEPA, IBAN, UPI) <br> and instant-settlement networks (Lightning Network), and integrates <br> with the existing CAPTCHA challenge mechanism defined in XEP-0158. <br> <br> URL: <a class=3D"moz-txt-link-freetext" href=3D"https://xmpp.org/= extensions/inbox/payment-required.html">https://xmpp.org/extensions/inbox= /payment-required.html</a> <br> <br> The Council will decide in the next two weeks whether to accept this <br> proposal as an official XEP. <br> _______________________________________________ <br> Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" h= ref=3D"mailto:[email protected]">[email protected]</a> <br> To unsubscribe send an email to <a class=3D"moz-txt-link-abbrevia= ted" href=3D"mailto:[email protected]">[email protected]</a= > <br> </blockquote> _______________________________________________ <br> Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" hre= f=3D"mailto:[email protected]">[email protected]</a> <br> To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviate= d" href=3D"mailto:[email protected]">[email protected]</a> <br> </blockquote> </body> </html> --------------mrbE9Nev747UYck8PJDJT4Fh-- --===============0975795742818755912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected] --===============0975795742818755912==--