On Mon, 30 Jun 2025 at 03:50, Greatsword <gs(a)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(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:0' id='groupchat-id1'
to='knightsguild(a)muc.example.org
<to='knightsguild(a)muc.example.org>/anna' />
<also id='groupchat-id2' to='knightsguild(a)muc.example.org
<to='knightsguild(a)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(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(a)muc.example.org
<to='knightsguild(a)muc.example.org>/anna' />
<to id='groupchat-id2' from='knightsguild(a)muc.example.org
<to='knightsguild(a)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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org