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/anna' />
<also id='groupchat-id2' 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/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

_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org