29 Jun
2025
29 Jun
'25
8:49 p.m.
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(a)muc.example.org
'
from='knightsguild(a)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(a)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(a)muc.example.org'
from='knightsguild(a)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(a)muc.example.org'
from='knightsguild(a)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(a)muc.example.org'
from='knightsguild(a)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(a)muc.example.org/anna'
id='groupchat-id1' arrangement='0' xmlns='urn:xmpp:reply:0'
/><reply to='knightsguild(a)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(a)xmpp.org
>> To unsubscribe send an email to standards-leave(a)xmpp.org
>
> _______________________________________________
> Standards mailing list -- standards(a)xmpp.org
> To unsubscribe send an email to standards-leave(a)xmpp.org