28 Jun
2025
28 Jun
'25
4:15 p.m.
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.
29 Jun
29 Jun
4:14 a.m.
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
5:13 a.m.
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/anna'
/>
<to id='groupchat-id2' from='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
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
30 Jun
30 Jun
3:49 a.m.
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
10:51 a.m.
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
11:48 a.m.
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.
7:43 a.m.
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.
7:45 a.m.
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.
30
days inactive
32
days old
8 comments
4 participants
participants (4)
-
Dave Cridland -
Greatsword -
Marvin W -
Stephen Paul Weber