XEP-0461 feedback: multi-message replies
I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature. I think an addition like this would be good. """ Section 3.2 - Multi-Message Replies A user may want to reply to multiple messages with a single message. This can be done by including many reply elements. Ordering is important, so the reply element MUST include an "arrangement" attribute that counts up from 0, with 0 being displayed at the top in the client UI. EXAMPLE 5. Yuri replies to both Max's and Anna's messages in a MUC. ``` <message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/anna' id='groupchat-id1' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id1' /> <body>A fort will keep us safe!</body> </message> <message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/max' id='groupchat-id2' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id2' /> <body>Adoring blue flags for style!</body> </message> <message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id3' /> <body>Excellent ideas! Let's get right to it!</body> <reply to='knightsguild@muc.example.org/anna' id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0' /><reply to='knightsguild@muc.example.org/max' id='groupchat-id2' arrangement='1' xmlns='urn:xmpp:reply:0' /> </message> ``` A fallback for this would work in the same way as the previous section, the main difference is that the fallback would include all referenced messages. """ I think it also might be worth considering having some kind of limiter in how many messages can be referenced by one reply - perhaps MUCs that advertise support for replies could indicate in a data form how many references may be one message, and if clients don't self-enforce this, then the MUC could throw a policy violation error and drop the message.
Does anyone know what existing clients do when faced with multiple reply elements in a single message? Do they pick the first, last, or do anything with both? My guess is that they'll vary, giving us the XMPP equivalent of Undefined Behaviour - we saw that with MUC codes a few years back when clients often only picked one. Discovering the answer to this will indicate if this would need to be a spec bump or not. There's nothing I noted in the existing spec that stipulates only one reply element can exist in a single message, so it's possible some clients are doing this kind of thing already. Final comment - XML is ordered, so the arrangement attribute is redundant - and prone to other exciting UB, like if there's two at the same rank, or gaps, or... (I have no opinion on whether we should do multi-replies, incidentally - though to be clear, no objections either) On Sat, 28 Jun 2025 at 23:16, Greatsword <gs@greatsword.xyz> wrote:
I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature.
I think an addition like this would be good.
""" Section 3.2 - Multi-Message Replies
A user may want to reply to multiple messages with a single message. This can be done by including many reply elements. Ordering is important, so the reply element MUST include an "arrangement" attribute that counts up from 0, with 0 being displayed at the top in the client UI.
EXAMPLE 5. Yuri replies to both Max's and Anna's messages in a MUC. ``` <message to='knightsguild@muc.example.org' from=' knightsguild@muc.example.org/anna' id='groupchat-id1' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id1' /> <body>A fort will keep us safe!</body> </message>
<message to='knightsguild@muc.example.org' from=' knightsguild@muc.example.org/max' id='groupchat-id2' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id2' /> <body>Adoring blue flags for style!</body> </message>
<message to='knightsguild@muc.example.org' from=' knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id3' /> <body>Excellent ideas! Let's get right to it!</body> <reply to='knightsguild@muc.example.org/anna' id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0' /> <reply to='knightsguild@muc.example.org/max' id='groupchat-id2' arrangement='1' xmlns='urn:xmpp:reply:0' /> </message> ```
A fallback for this would work in the same way as the previous section, the main difference is that the fallback would include all referenced messages.
"""
I think it also might be worth considering having some kind of limiter in how many messages can be referenced by one reply - perhaps MUCs that advertise support for replies could indicate in a data form how many references may be one message, and if clients don't self-enforce this, then the MUC could throw a policy violation error and drop the message. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi, The current specification was definitely not written with the intention that one would use it to reply to multiple messages at once. I checked existing implementations and they all seem to only be suited for a single reply element and will either only take the first one if there are multiple or ignore all. So if we are to add this, it would need to be done with a namespace bump. Given that this is not the first time I hear people mention this idea (although I have yet to see a compelling usecase), I can see this being added. As Dave mentioned, the whole arrangement thing is making things rather complicated and given that ordering is already preserved in XML, we can make use of it. I do see a motivation though to not do this for direct stanza child elements (as these could interleave with other child elements), my idea would thus rather be to go with something along the lines of: <message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <body>Excellent ideas! Let's get right to it!</body> <reply xmlns='urn:xmpp:reply:1'> <to id='groupchat-id1' from='knightsguild@muc.example.org/anna' /> <to id='groupchat-id2' from='knightsguild@muc.example.org/max' /> </reply> </message> This also makes it syntactically more clear, that this is a single reply to multiple messages, rather than multiple replies sent within a single message (which is what we often do in emails when replying to multiple messages). Does this sound reasonable to everyone? Marvin On Sun, 2025-06-29 at 11:14 +0100, Dave Cridland wrote:
Does anyone know what existing clients do when faced with multiple reply elements in a single message? Do they pick the first, last, or do anything with both? My guess is that they'll vary, giving us the XMPP equivalent of Undefined Behaviour - we saw that with MUC codes a few years back when clients often only picked one. Discovering the answer to this will indicate if this would need to be a spec bump or not.
There's nothing I noted in the existing spec that stipulates only one reply element can exist in a single message, so it's possible some clients are doing this kind of thing already.
Final comment - XML is ordered, so the arrangement attribute is redundant - and prone to other exciting UB, like if there's two at the same rank, or gaps, or...
(I have no opinion on whether we should do multi-replies, incidentally - though to be clear, no objections either)
On Sat, 28 Jun 2025 at 23:16, Greatsword <gs@greatsword.xyz> wrote:
I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature.
I think an addition like this would be good.
""" Section 3.2 - Multi-Message Replies
A user may want to reply to multiple messages with a single message. This can be done by including many reply elements. Ordering is important, so the reply element MUST include an "arrangement" attribute that counts up from 0, with 0 being displayed at the top in the client UI.
EXAMPLE 5. Yuri replies to both Max's and Anna's messages in a MUC. ``` <message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/anna' id='groupchat-id1' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id1' /> <body>A fort will keep us safe!</body> </message>
<message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/max' id='groupchat-id2' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id2' /> <body>Adoring blue flags for style!</body> </message>
<message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id3' /> <body>Excellent ideas! Let's get right to it!</body> <reply to='knightsguild@muc.example.org/anna' id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0' /> <reply to='knightsguild@muc.example.org/max' id='groupchat-id2' arrangement='1' xmlns='urn:xmpp:reply:0' /> </message> ```
A fallback for this would work in the same way as the previous section, the main difference is that the fallback would include all referenced messages.
"""
I think it also might be worth considering having some kind of limiter in how many messages can be referenced by one reply - perhaps MUCs that advertise support for replies could indicate in a data form how many references may be one message, and if clients don't self-enforce this, then the MUC could throw a policy violation error and drop the message.
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
I see no issues with the new design, Martin! As for Dave's question about client support, I briefly tried it with two clients (Gajim and monocles chat), only one reply is displayed, with Gajim displaying the first and monocles displaying the last. I'm willing to bet that most other clients behave in this way. I think a namespace bump is reasonable, since we're now changing the structure of the XML. On 2025-06-29 05:13, Marvin W wrote:
Hi,
The current specification was definitely not written with the intention that one would use it to reply to multiple messages at once. I checked existing implementations and they all seem to only be suited for a single reply element and will either only take the first one if there are multiple or ignore all. So if we are to add this, it would need to be done with a namespace bump.
Given that this is not the first time I hear people mention this idea (although I have yet to see a compelling usecase), I can see this being added.
As Dave mentioned, the whole arrangement thing is making things rather complicated and given that ordering is already preserved in XML, we can make use of it. I do see a motivation though to not do this for direct stanza child elements (as these could interleave with other child elements), my idea would thus rather be to go with something along the lines of:
<message to='knightsguild@muc.example.org ' from='knightsguild@muc.example.org /yuri' id='groupchat-id3' type='groupchat'>
<body>Excellent ideas! Let's get right to it!</body>
<reply xmlns=' urn:xmpp:reply:1 '>
<to id='groupchat-id1' from [='knightsguild@muc.example.org](mailto:to='knightsguild@muc.example.org) /anna' />
<to id='groupchat-id2' from[='knightsguild@muc.example.org](mailto:to='knightsguild@muc.example.org)/max' />
</reply>
</message>
This also makes it syntactically more clear, that this is a single reply to multiple messages, rather than multiple replies sent within a single message (which is what we often do in emails when replying to multiple messages).
Does this sound reasonable to everyone?
Marvin
On Sun, 2025-06-29 at 11:14 +0100, Dave Cridland wrote:
Does anyone know what existing clients do when faced with multiple reply elements in a single message? Do they pick the first, last, or do anything with both? My guess is that they'll vary, giving us the XMPP equivalent of Undefined Behaviour - we saw that with MUC codes a few years back when clients often only picked one. Discovering the answer to this will indicate if this would need to be a spec bump or not.
There's nothing I noted in the existing spec that stipulates only one reply element can exist in a single message, so it's possible some clients are doing this kind of thing already.
Final comment - XML is ordered, so the arrangement attribute is redundant - and prone to other exciting UB, like if there's two at the same rank, or gaps, or...
(I have no opinion on whether we should do multi-replies, incidentally - though to be clear, no objections either)
On Sat, 28 Jun 2025 at 23:16, Greatsword <gs@greatsword.xyz> wrote:
I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature.
I think an addition like this would be good.
""" Section 3.2 - Multi-Message Replies
A user may want to reply to multiple messages with a single message. This can be done by including many reply elements. Ordering is important, so the reply element MUST include an "arrangement" attribute that counts up from 0, with 0 being displayed at the top in the client UI.
EXAMPLE 5. Yuri replies to both Max's and Anna's messages in a MUC. ``` <message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/anna' id='groupchat-id1' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id1' /> <body>A fort will keep us safe!</body> </message>
<message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/max' id='groupchat-id2' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id2' /> <body>Adoring blue flags for style!</body> </message>
<message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id3' /> <body>Excellent ideas! Let's get right to it!</body> <reply to='knightsguild@muc.example.org/anna' id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0' /><reply to='knightsguild@muc.example.org/max' id='groupchat-id2' arrangement='1' xmlns='urn:xmpp:reply:0' /> </message> ```
A fallback for this would work in the same way as the previous section, the main difference is that the fallback would include all referenced messages.
"""
I think it also might be worth considering having some kind of limiter in how many messages can be referenced by one reply - perhaps MUCs that advertise support for replies could indicate in a data form how many references may be one message, and if clients don't self-enforce this, then the MUC could throw a policy violation error and drop the message.
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Mon, 30 Jun 2025 at 03:50, Greatsword <gs@greatsword.xyz> wrote:
I see no issues with the new design, Martin!
As for Dave's question about client support, I briefly tried it with two clients (Gajim and monocles chat), only one reply is displayed, with Gajim displaying the first and monocles displaying the last. I'm willing to bet that most other clients behave in this way.
Right, so we're definitely into UB territory, and should the consensus be to have multi-replies, then we need to do something. Can we structure the XML change such that a degradation into a single reply works? Perhaps the first reply is as XEP-0461, but subsequent replies are a different element (possibly can be the same namespace). As a vague but concrete suggestion: <message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <body>Excellent ideas! Let's get right to it!</body> <reply xmlns='urn:xmpp:reply:0' id='groupchat-id1' to='knightsguild@muc.example.org <to='knightsguild@muc.example.org>/anna' /> <also id='groupchat-id2' to='knightsguild@muc.example.org <to='knightsguild@muc.example.org>/max' /> </reply> </message> (Changes: Incorporate the first reply into the reply element again, use original namespace, change subsequent reply to "also" with attribute "to" for consistency). I think this will work consistently with existing clients but provide the multi-reply as well. I think a namespace bump is reasonable, since we're now changing the
structure of the XML.
I'm possibly reading more into this statement than you intended, but in general we want to only bump the namespace where incompatibilities would otherwise arrive undetected. So no namespace bump unless we absolutely have to, but if we have to, we absolutely do it. Of note here is that adding elements and attributes is normally not a reason to bump the namespace, though traditional XML rules would indicate we should - clients and servers typically just ignore XML stuff they don't understand.
On 2025-06-29 05:13, Marvin W wrote:
Hi,
The current specification was definitely not written with the intention that one would use it to reply to multiple messages at once. I checked existing implementations and they all seem to only be suited for a single reply element and will either only take the first one if there are multiple or ignore all. So if we are to add this, it would need to be done with a namespace bump.
Given that this is not the first time I hear people mention this idea (although I have yet to see a compelling usecase), I can see this being added.
As Dave mentioned, the whole arrangement thing is making things rather complicated and given that ordering is already preserved in XML, we can make use of it. I do see a motivation though to not do this for direct stanza child elements (as these could interleave with other child elements), my idea would thus rather be to go with something along the lines of:
<message to='knightsguild@muc.example.org' from='knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'>
<body>Excellent ideas! Let's get right to it!</body>
<reply xmlns='urn:xmpp:reply:1'>
<to id='groupchat-id1' from='knightsguild@muc.example.org <to='knightsguild@muc.example.org>/anna' />
<to id='groupchat-id2' from='knightsguild@muc.example.org <to='knightsguild@muc.example.org>/max' />
</reply>
</message>
This also makes it syntactically more clear, that this is a single reply to multiple messages, rather than multiple replies sent within a single message (which is what we often do in emails when replying to multiple messages).
Does this sound reasonable to everyone?
Marvin
On Sun, 2025-06-29 at 11:14 +0100, Dave Cridland wrote:
Does anyone know what existing clients do when faced with multiple reply elements in a single message? Do they pick the first, last, or do anything with both? My guess is that they'll vary, giving us the XMPP equivalent of Undefined Behaviour - we saw that with MUC codes a few years back when clients often only picked one. Discovering the answer to this will indicate if this would need to be a spec bump or not.
There's nothing I noted in the existing spec that stipulates only one reply element can exist in a single message, so it's possible some clients are doing this kind of thing already.
Final comment - XML is ordered, so the arrangement attribute is redundant - and prone to other exciting UB, like if there's two at the same rank, or gaps, or...
(I have no opinion on whether we should do multi-replies, incidentally - though to be clear, no objections either)
On Sat, 28 Jun 2025 at 23:16, Greatsword <gs@greatsword.xyz> wrote:
I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature.
I think an addition like this would be good.
""" Section 3.2 - Multi-Message Replies
A user may want to reply to multiple messages with a single message. This can be done by including many reply elements. Ordering is important, so the reply element MUST include an "arrangement" attribute that counts up from 0, with 0 being displayed at the top in the client UI.
EXAMPLE 5. Yuri replies to both Max's and Anna's messages in a MUC. ``` <message to='knightsguild@muc.example.org' from=' knightsguild@muc.example.org/anna' id='groupchat-id1' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id1' /> <body>A fort will keep us safe!</body> </message>
<message to='knightsguild@muc.example.org' from=' knightsguild@muc.example.org/max' id='groupchat-id2' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id2' /> <body>Adoring blue flags for style!</body> </message>
<message to='knightsguild@muc.example.org' from=' knightsguild@muc.example.org/yuri' id='groupchat-id3' type='groupchat'> <stanza-id xmlns='urn:xmpp:sid:0' id='groupchat-id3' /> <body>Excellent ideas! Let's get right to it!</body> <reply to='knightsguild@muc.example.org/anna' id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0' /> <reply to='knightsguild@muc.example.org/max' id='groupchat-id2' arrangement='1' xmlns='urn:xmpp:reply:0' /> </message> ```
A fallback for this would work in the same way as the previous section, the main difference is that the fallback would include all referenced messages.
"""
I think it also might be worth considering having some kind of limiter in how many messages can be referenced by one reply - perhaps MUCs that advertise support for replies could indicate in a data form how many references may be one message, and if clients don't self-enforce this, then the MUC could throw a policy violation error and drop the message. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi, On Mon, 2025-06-30 at 10:49 +0100, Dave Cridland wrote:
Can we structure the XML change such that a degradation into a single reply works? Perhaps the first reply is as XEP-0461, but subsequent replies are a different element (possibly can be the same namespace).
I think a multi-reply should not "degrade" into a single-reply with to only one of the messages, as this would mean that the explicitly intended meaning of replying to more than one message is lost entirely. Instead the most graceful fallback is probably to instead have a message that has 2 block-quotes to refer to the previous message (and have those tagged with fallback indicator so they are hidden if multi- reply is supported).
I'm possibly reading more into this statement than you intended, but in general we want to only bump the namespace where incompatibilities would otherwise arrive undetected. So no namespace bump unless we absolutely have to, but if we have to, we absolutely do it.
In this case a namespace bump is totally reasonable: - We don't have a lot of implementations yet and the XEP is very young. - Good fallbacks are possible for unsupporting clients - Updated clients can temporarily send both versions at the same time for cases that would've been supported by the old spec (single message replies) On Mon, 2025-06-30 at 13:43 +0000, Stephen Paul Weber wrote:
I don't see how that's a problem. Order is preserved in any case.
I believe this would be the first time we'd give meaning to the ordering of direct child elements of stanzas. Previously, those elements have been processed largely independent of each other.
Using a grouping element just opens us up to new fun cases like multiple grouping elements.
Well, many existing XEPs don't allow for their elements to exist multiple times and not all make that really explicit. You likely can't (or shouldn't be able to) send multiple XEP-0353 <propose/> in a single message or have multiple XEP-0319 <idle/> in a presence. If you do, you end up in undefined behavior. Should we make more explicit what should happen in those cases? Yes, certainly. But them existing multiple times is really the only "fun case" you can come up with. I like that the syntax matches more the semantics if you "group" them. The message is a reply to two messages, not a message that is two replies. On Mon, 2025-06-30 at 13:45 +0000, Stephen Paul Weber wrote:
I'm interested to see a prototype of this rnd especially what kinds of UX are possible for multiple replies but no quotes.
Until then I think any discussion of XEP changes or namespace bumps is a bit cart before the horse.
As was mentioned by Greatsword in their initial message, there are already non-XMPP messengers that support this, it's really not something innovative. As this is not the first time this feature is desired, there seems to be people interested. For reference, here's screenshots of revolt.chat when doing replies to multiple messages: https://imgur.com/a/6n1oiPd Marvin
I'm possibly reading more into this statement than you intended, but in general we want to only bump the namespace where incompatibilities would otherwise arrive undetected. So no namespace bump unless we absolutely have to, but if we have to, we absolutely do it.
Of note here is that adding elements and attributes is normally not a reason to bump the namespace, though traditional XML rules would indicate we should - clients and servers typically just ignore XML stuff they don't understand.
my misunderstanding! thanks for pointing this out. On 2025-06-30 03:49, Dave Cridland wrote:
I'm possibly reading more into this statement than you intended, but in general we want to only bump the namespace where incompatibilities would otherwise arrive undetected. So no namespace bump unless we absolutely have to, but if we have to, we absolutely do it.
Of note here is that adding elements and attributes is normally not a reason to bump the namespace, though traditional XML rules would indicate we should - clients and servers typically just ignore XML stuff they don't understand.
make use of it. I do see a motivation though to not do this for direct stanza child elements (as these could interleave with other child elements),
I don't see how that's a problem. Order is preserved in any case. Using a grouping element just opens us up to new fun cases like multiple grouping elements.
I've seen some IM platforms (namely Revolt and Guilded) have the ability to let the user reference multiple messages in a single reply, which might be a useful feature. I think with the XEP as it currently is, it could be fairly simple to add support for this feature.
I'm interested to see a prototype of this rnd especially what kinds of UX are possible for multiple replies but no quotes. Until then I think any discussion of XEP changes or namespace bumps is a bit cart before the horse.
participants (4)
-
Dave Cridland -
Greatsword -
Marvin W -
Stephen Paul Weber