Re: Proposed XMPP Extension: Payment Required

This is a multi-part message in MIME format.
--===============4705206881082474575==
Content-Type: multipart/alternative;
 boundary="------------vPEZ32PH77Tb7IA38pKDBiKR"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------vPEZ32PH77Tb7IA38pKDBiKR
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Marvin

On 4/24/26 17:32, Marvin W. via Standards wrote:
> I don't believe the XSF should maintain a registry of payment schemes
> or systems or specific proof types for payment schemes. This is not our
> field of expertise and this should be happening elsewhere. I understand
> with RFC 8905 there is already some standard and a corresponding
> registry and we could entirely rely on that (or any other open standard
> with a suitable registry) instead of doing our own.
You're right, and I saw others have raised the same point in the MUC.

I've submitted a new revision on Github that removes the registry
for payment schemes, systems and proof formats.

A payment option is now a payment URI, and the payment system is
identified by that URI scheme.

The only registry that remains is the invoice-request service-context lis=
t
 =C2=A0(muc-entry, file-upload etc.), which is still XMPP application sem=
antics.

> I also would want to refrain to include any specific crypto-currency
> network or technology in a specification document, because else there
> will be a ton of stuff to specify: The industry site CoinMarketCap
> lists more than 150 "Layer 1" crypto-currencies and "competition" in
> the industry is largely about being mentioned in some "official"
> sounding documents, so soon everyone will want to have a XEP if we open
> that can of worms.

I agree on the substance and the new revision is now even more
generic because payment systems are purely identified by their
URI schemes. I've also generalized the prose in certain areas.

I did however keep a small number of illustrative examples.=C2=A0This
follows established XSF practice of naming concrete third-party
technologies as examples. For example XEP-0266 names specific
codecs (Opus, Speex, G.711), without pretending to be exhaustive.

> There's also a very unhelpful part where you say that currency is ISO
> 4217 or non-ISO code. That makes it effectively "put anything here".
> The part where the amount field also includes the currency code is also
> weird to me (usually we would want to use our XML syntax instead of a
> custom syntax), but that's a minor.

Fair. I've removed the "amount" attribute entirely in the latest revision=
.

The amount, currency and beneficiary are now carried inside the
payment URI and governed by that scheme's own standard and
we define no amount or currency syntax of our own.

I've kept "display-amount" to avoid clients having to be able to
parse payment URIs, but it's non-authoritative.

> So my suggestion is to mostly piggy-back on top of RFC 8905 (or any
> other suitable open standard specification) and have lighting or
> whatever cryptocurrency network you want to support be integrated with
> those people that actually do know payments much better than the XSF.
Yes thank you, the XEP is now updated accordingly.

Regards
JC

> Marvin
>
> On Fri, 2026-04-24 at 10:26 +0000, 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 [email protected]
> _______________________________________________
> Standards mailing list [email protected]
> To unsubscribe send an email [email protected]
--------------vPEZ32PH77Tb7IA38pKDBiKR
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>
    <p>Hi Marvin</p>
    <div class=3D"moz-cite-prefix">On 4/24/26 17:32, Marvin W. via
      Standards wrote:<span style=3D"white-space: pre-wrap">
</span><span style=3D"white-space: pre-wrap">
</span></div>
    <blockquote type=3D"cite"
      cite=3D"mid:[email protected]=
">
      <pre wrap=3D"" class=3D"moz-quote-pre">I don't believe the XSF shou=
ld maintain a registry of payment schemes
or systems or specific proof types for payment schemes. This is not our
field of expertise and this should be happening elsewhere. I understand
with RFC 8905 there is already some standard and a corresponding
registry and we could entirely rely on that (or any other open standard
with a suitable registry) instead of doing our own.</pre>
    </blockquote>
    You're right, and I saw others have raised the same point in the
    MUC.<br>
    <p>I've submitted a new revision on Github that removes the registry<=
br>
      for payment schemes, systems and proof formats.</p>
    <p>A payment option is now a payment URI, and the payment system is<b=
r>
      identified by that URI scheme.<br>
      <br>
      The only registry that remains is the invoice-request
      service-context list<br>
      =C2=A0(muc-entry, file-upload etc.), which is still XMPP applicatio=
n
      semantics.<br>
      <span style=3D"white-space: pre-wrap">
</span></p>
    <blockquote type=3D"cite"
      cite=3D"mid:[email protected]=
">
      <pre wrap=3D"" class=3D"moz-quote-pre">
I also would want to refrain to include any specific crypto-currency
network or technology in a specification document, because else there
will be a ton of stuff to specify: The industry site CoinMarketCap
lists more than 150 "Layer 1" crypto-currencies and "competition" in
the industry is largely about being mentioned in some "official"
sounding documents, so soon everyone will want to have a XEP if we open
that can of worms.
</pre>
    </blockquote>
    <p>I agree on the substance and the new revision is now even more<br>
      generic because payment systems are purely identified by their<br>
      URI schemes. I've also generalized the prose in certain areas.</p>
    <p>I did however keep a small number of illustrative examples.=C2=A0T=
his<br>
      follows established XSF practice of naming concrete third-party<br>
      technologies as examples. For example XEP-0266 names specific<br>
      codecs (Opus, Speex, G.711), without pretending to be exhaustive.</=
p>
    <span style=3D"white-space: pre-wrap">
</span><span style=3D"white-space: pre-wrap">
</span>
    <blockquote type=3D"cite"
      cite=3D"mid:[email protected]=
">
      <pre wrap=3D"" class=3D"moz-quote-pre">There's also a very unhelpfu=
l part where you say that currency is ISO
4217 or non-ISO code. That makes it effectively "put anything here".
The part where the amount field also includes the currency code is also
weird to me (usually we would want to use our XML syntax instead of a
custom syntax), but that's a minor.</pre>
    </blockquote>
    <p>Fair. I've removed the "amount" attribute entirely in the latest
      revision.<br>
      <br>
      The amount, currency and beneficiary are now carried inside the<br>
      payment URI and governed by that scheme's own standard and<br>
      we define no amount or currency syntax of our own.</p>
    <p>I've kept "display-amount" to avoid clients having to be able to<b=
r>
      parse payment URIs, but it's non-authoritative.</p>
    <span style=3D"white-space: pre-wrap">
</span>
    <blockquote type=3D"cite"
      cite=3D"mid:[email protected]=
">
      <pre wrap=3D"" class=3D"moz-quote-pre">So my suggestion is to mostl=
y piggy-back on top of RFC 8905 (or any
other suitable open standard specification) and have lighting or
whatever cryptocurrency network you want to support be integrated with
those people that actually do know payments much better than the XSF.</pr=
e>
    </blockquote>
    Yes thank you, the XEP is now updated accordingly.<br>
    <br>
    Regards<br>
    JC<br>
    <br>
    <blockquote type=3D"cite"
      cite=3D"mid:[email protected]=
">
      <pre wrap=3D"" class=3D"moz-quote-pre">Marvin

On Fri, 2026-04-24 at 10:26 +0000, Daniel Gultsch wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"" class=3D"moz-quote-pre">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: <a class=3D"moz-txt-link-freetext" href=3D"https://xmpp.org/extensio=
ns/inbox/payment-required.html">https://xmpp.org/extensions/inbox/payment=
-required.html</a>

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
_______________________________________________
Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" href=3D"m=
ailto:[email protected]">[email protected]</a>
To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
f=3D"mailto:[email protected]">[email protected]</a>
</pre>
      </blockquote>
      <pre wrap=3D"" class=3D"moz-quote-pre">____________________________=
___________________
Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" href=3D"m=
ailto:[email protected]">[email protected]</a>
To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
f=3D"mailto:[email protected]">[email protected]</a>
</pre>
    </blockquote>
  </body>
</html>

--------------vPEZ32PH77Tb7IA38pKDBiKR--

--===============4705206881082474575==
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]

--===============4705206881082474575==--