21 Apr
2025
21 Apr
'25
1:13 a.m.
Hi,
All these XEPs miss a paragraph how corrections should be handled correctly e.g. if the ID
of the original message or of the correction should be used.
This leads already to different implementations in popular clients, none of which can be
considered wrong as the XEPs do not specify a correct handling.
Regards
Philipp
21 Apr
21 Apr
8:41 a.m.
Additionally, XEP-0444 (Message Reactions), and pretty much anywhere an ID will ever be
used to reference another message.
The issue stems from XEP-0308 replacing/overwriting the message ID, and consequently all
references already using the previous message ID are left pointing to a non-existent
message.
Amongst other things, this provides a way to avoid moderation — send an offensive message,
it gets moderated, just LMC the message and it's no longer moderated.
So, while it feels 'wrong' from a purist view, NOT replacing the message ID would
be the better option - old and new references will then all point to the same message.
Otherwise, presumably, clients (and servers?) will be required to track all past message
IDs for each corrected message.
9:01 a.m.
XEP-0444 specifies it in the business rules, although its not very strict, basically says
you should use the original id but everyone should also support everything else.
XEP-0308 does not overwrite the original message id, the client just replaces the payload
of the message.
From XEP-308
If the same message is to be corrected several times,
the id of the original message is used in each case (e.g. If a message of id 1 is
corrected by a message of id 2, a subsequent correction should correct 1, not 2).
So all corrections point to the original message.
I would argue the case if the corrections XEP itself always references the original
message, all other XEPs should do aswell.
Regards
Philipp
On Mon, Apr 21, 2025, at 16:41, Tedd Sterr wrote:
Additionally, XEP-0444 (Message Reactions), and pretty
much anywhere an ID will ever be used to reference another message.
The issue stems from XEP-0308 replacing/overwriting the message ID, and consequently all
references already using the previous message ID are left pointing to a non-existent
message.
Amongst other things, this provides a way to avoid moderation — send an offensive
message, it gets moderated, just LMC the message and it's no longer moderated.
So, while it feels 'wrong' from a purist view, NOT replacing the message ID would
be the better option - old and new references will then all point to the same message.
Otherwise, presumably, clients (and servers?) will be required to track all past message
IDs for each corrected message.
11:04 a.m.
Hi,
I understand the nature of XEP-0308 in such that it changes the body of
another message and is not to be understood as a message itself. This
is why if the same message is corrected multiple times, they all refer
to the initial message id. And I agree that we should generally apply
the same logic to other XEPs.
That said, other XEPs don't depend on XEP-0308 and generally should not
assume XEP-0308 to be supported by sending or receiving clients. Thus
these XEPs don't only need to specify "which ID should be used when a
message was XEP-0308 corrected", but also might specify other rules and
need to consider how this will behave with other clients supporting or
not supporting XEP-0308.
For XEP-0461, I think the best handling would be, that it is allowed to
reference not only the initial message, but also any of the
corrections. If entities receive a reply to a message that was
corrected later (or was a correction itself) it may decide the display
the body of this specific iteration of the message (instead of the
latest iteration) if it displays the body of the message replied to
next to the reply.
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Bob reply-to=b body="> Second\nReply" fallback=reply:0:9
The XEP-0308-aware client would then display something like
Alice: Third (edited)
Bob: > Alice wrote: (link to above message "Third")
Second (edited)
Reply
The XEP-0308-unaware client would instead display something like
Alice: First
Alice: Second
Alice: Third
Bob: > Alice wrote (link to above message "Second")
Second
Reply
I think this is fair.
For XEP-0424 my personal suggestion would be, that a retraction for a
corrected or correction message, should only be understood as a
retraction of that revision of the message. If that revision is not the
latest (the message was corrected further later) retracting an older
revision has no effect - this also applies to the original message.
This makes the behavior across XEP-0308-aware and -unaware clients the
most consistent:
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Alice retraction-of=b
The XEP-0308-aware client would then display something like:
Alice: Third (edited)
It the client supports showing a correction history, it would display
that the second revision of the message was retracted. If instead the
latest revision is retracted, the previous (unretracted) revision is
displayed.
The XEP-0308-unaware client would instead display something like:
Alice: First
Alice: (retracted)
Alice: Third
Only once all revisions of a message have been retracted, such message
will completely be retracted (for both XEP-0308-aware and- unaware
clients). As such, if a client wants to remove a message with
corrections entirely, it should send retractions for each revision
(it's probably worth explicitly allowing this to happen in a single
message).
If we agree on above for XEP-0424, XEP-0425 wouldn't strictly need any
additions. And because XEP-0308 is based on the messages @id even in
MUCs and we don't want to ask MUC servers to keep track of those,
there's not a lot a MUC server can do here either.
Marvin
On Mon, 2025-04-21 at 17:01 +0200, Philipp Hörist wrote:
XEP-0444 specifies it in the business rules, although
its not very
strict, basically says you should use the original id but everyone
should also support everything else.
XEP-0308 does not overwrite the original message id, the client just
replaces the payload of the message.
From XEP-308
If the same message is to be corrected several
times, the id of the
original message is used in each case (e.g. If a message of id
1 is
corrected by a message of id 2, a subsequent correction should
correct 1, not 2).
So all corrections point to the original message.
I would argue the case if the corrections XEP itself always
references the original message, all other XEPs should do aswell.
Regards
Philipp
On Mon, Apr 21, 2025, at 16:41, Tedd Sterr wrote:
Additionally, XEP-0444 (Message Reactions), and
pretty much
anywhere an ID will ever be used to reference another message.
The issue stems from XEP-0308 replacing/overwriting the message ID,
and consequently all references already using the previous message
ID are left pointing to a non-existent message.
Amongst other things, this provides a way to avoid moderation —
send an offensive message, it gets moderated, just LMC the message
and it's no longer moderated.
So, while it feels 'wrong' from a purist view, NOT replacing the
message ID would be the better option - old and new references will
then all point to the same message. Otherwise, presumably, clients
(and servers?) will be required to track all past message IDs for
each corrected message.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
1:04 p.m.
Hi,
Not sure why you spec out stuff for XEP-0308 non-aware clients.
XEP-308 is the oldest, its in all the compliance XEPs as a core feature that every IM
Client should support, i think we all agree its a core part of any messenger application.
Why would it be a problem for these XEPs to depend on XEP-308? You solve a problem nobody
has.
You state
And I agree that we should generally apply the same
logic to other XEPs.
then go on and make an over engineered spec to do exactly the opposite.
We changed XEP-0308 to make it extra so that it is not a chain, that all corrections
reference always the original, now you want to introduce right now 4 different XEPs that
in the future can reference any of these in between correction messages?
The sane thing to do is, reference the original message, always. An easy rule, no need to
define what it means if the 2nd of 3 corrections is retracted or moderated or replied to.
Regards
Philipp
On Mon, Apr 21, 2025, at 19:04, Marvin W wrote:
Hi,
I understand the nature of XEP-0308 in such that it changes the body of another message
and is not to be understood as a message itself. This is why if the same message is
corrected multiple times, they all refer to the initial message id. And I agree that we
should generally apply the same logic to other XEPs.
That said, other XEPs don't depend on XEP-0308 and generally should not assume
XEP-0308 to be supported by sending or receiving clients. Thus these XEPs don't only
need to specify "which ID should be used when a message was XEP-0308 corrected",
but also might specify other rules and need to consider how this will behave with other
clients supporting or not supporting XEP-0308.
For XEP-0461, I think the best handling would be, that it is allowed to reference not
only the initial message, but also any of the corrections. If entities receive a reply to
a message that was corrected later (or was a correction itself) it may decide the display
the body of this specific iteration of the message (instead of the latest iteration) if it
displays the body of the message replied to next to the reply.
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Bob reply-to=b body="> Second\nReply" fallback=reply:0:9
The XEP-0308-aware client would then display something like
Alice: Third (edited)
Bob: > Alice wrote: *(link to above message "Third")*
Second (edited)
Reply
The XEP-0308-unaware client would instead display something like
Alice: First
Alice: Second
Alice: Third
Bob: > Alice wrote *(link to above message "Second")*
Second
Reply
I think this is fair.
For XEP-0424 my personal suggestion would be, that a retraction for a corrected or
correction message, should only be understood as a retraction of that revision of the
message. If that revision is not the latest (the message was corrected further later)
retracting an older revision has no effect - this also applies to the original message.
This makes the behavior across XEP-0308-aware and -unaware clients the most consistent:
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Alice retraction-of=b
The XEP-0308-aware client would then display something like:
Alice: Third (edited)
It the client supports showing a correction history, it would display that the second
revision of the message was retracted. If instead the latest revision is retracted, the
previous (unretracted) revision is displayed.
The XEP-0308-unaware client would instead display something like:
Alice: First
Alice: (retracted)
Alice: Third
Only once all revisions of a message have been retracted, such message will completely be
retracted (for both XEP-0308-aware and- unaware clients). As such, if a client wants to
remove a message with corrections entirely, it should send retractions for each revision
(it's probably worth explicitly allowing this to happen in a single message).
If we agree on above for XEP-0424, XEP-0425 wouldn't strictly need any additions. And
because XEP-0308 is based on the messages @id even in MUCs and we don't want to ask
MUC servers to keep track of those, there's not a lot a MUC server can do here
either.
Marvin
On Mon, 2025-04-21 at 17:01 +0200, Philipp Hörist wrote:
XEP-0444 specifies it in the business rules,
although its not very strict, basically says you should use the original id but everyone
should also support everything else.
XEP-0308 does not overwrite the original message id, the client just replaces the payload
of the message.
From XEP-308
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
If the same message is to be corrected several
times, the id of the original message is used in each case (e.g. If a message of id 1 is
corrected by a message of id 2, a subsequent correction should correct 1, not 2).
So all corrections point to the original message.
I would argue the case if the corrections XEP itself always references the original
message, all other XEPs should do aswell.
Regards
Philipp
On Mon, Apr 21, 2025, at 16:41, Tedd Sterr wrote:
Additionally, XEP-0444 (Message Reactions), and
pretty much anywhere an ID will ever be used to reference another message.
The issue stems from XEP-0308 replacing/overwriting the message ID, and consequently all
references already using the previous message ID are left pointing to a non-existent
message.
Amongst other things, this provides a way to avoid moderation — send an offensive
message, it gets moderated, just LMC the message and it's no longer moderated.
So, while it feels 'wrong' from a purist view, NOT replacing the message ID would
be the better option - old and new references will then all point to the same message.
Otherwise, presumably, clients (and servers?) will be required to track all past message
IDs for each corrected message.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
2:40 p.m.
Hi,
XEP-0308 is currently not a requirement of XEP-0424/0425/0461 and is
largely an unrelated feature. It's of course possible to design around
it being a requirement, but that also would be weird, given that XEP-
0308 has a number of known limitations (e.g. correcting older than the
latest messages is explicitly out of scope) and thus is likely to be
replaced eventually.
As long as XEP-0308 is not a requirement, you must live under the
assumption of some clients supporting it and some not supporting it.
There's also a number of practically relevant cases where XEP-0308
can't be used safely (e.g. semi-anonymous MUCs without occupant-id, if
the messages are received from archive or without all participants
online between the original message and its correction) and clients are
also typically partial knowledge, meaning they might not be able to
fully comply with XEP-0308 (e.g. if they don't know the original
message because it is out of the sync window). As such, it is just a
sane default to assume that even if clients are aware of XEP-0308, they
might not be able to use it. And to extend on this, it's easier to just
assume the client does not support it (because every client can just
fallback to the behavior of not supporting it).
XEP-0424/XEP-0425 apply to almost all clients - even if they only
support very basic XMPP features - simply due to it potentially
tombstone'ing the message before it arrives at a client. The behavior
of tombstone'ing becomes very vague if you include XEP-0308 and only
the reference the original message, as it means only that is
tombstone'd, not any of the other revisions, which thus remain stored
and available. If later a client syncs the correction, but not the
tombstone, it wouldn't even know that the message was meant to be
retracted, simply because it's out of the sync window.
For the reasons laid out before, a rule to require to always only
reference the initial message in a multi-revision scenario is
conceptually flawed in that the sending client might just be unaware
what the initial message was. In XEP-0308 that was acceptable, given
the restrictions it puts on the sending clients (by only allowing to
edit ones own last message).
As a side note: XEP-0308 is currently stable, but lacks multiple of the
formal requirements for being stable, as it has neither a schema, nor a
normative description of the <replace/> element, but only an example.
Marvin
On Mon, 2025-04-21 at 21:04 +0200, Philipp Hörist wrote:
Hi,
Not sure why you spec out stuff for XEP-0308 non-aware clients.
XEP-308 is the oldest, its in all the compliance XEPs as a core
feature that every IM Client should support, i think we all agree its
a core part of any messenger application.
Why would it be a problem for these XEPs to depend on XEP-308? You
solve a problem nobody has.
You state
And I agree that we should generally apply the
same logic to other
XEPs.
then go on and make an over engineered spec to do exactly the
opposite.
We changed XEP-0308 to make it extra so that it is not a chain, that
all corrections reference always the original, now you want to
introduce right now 4 different XEPs that in the future can reference
any of these in between correction messages?
The sane thing to do is, reference the original message, always. An
easy rule, no need to define what it means if the 2nd of 3
corrections is retracted or moderated or replied to.
Regards
Philipp
On Mon, Apr 21, 2025, at 19:04, Marvin W wrote:
Hi,
I understand the nature of XEP-0308 in such that it changes the
body of another message and is not to be understood as a message
itself. This is why if the same message is corrected multiple
times, they all refer to the initial message id. And I agree that
we should generally apply the same logic to other XEPs.
That said, other XEPs don't depend on XEP-0308 and generally should
not assume XEP-0308 to be supported by sending or receiving
clients. Thus these XEPs don't only need to specify "which ID
should be used when a message was XEP-0308 corrected", but also
might specify other rules and need to consider how this will behave
with other clients supporting or not supporting XEP-0308.
For XEP-0461, I think the best handling would be, that it is
allowed to reference not only the initial message, but also any of
the corrections. If entities receive a reply to a message that was
corrected later (or was a correction itself) it may decide the
display the body of this specific iteration of the message (instead
of the latest iteration) if it displays the body of the message
replied to next to the reply.
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Bob reply-to=b body="> Second\nReply" fallback=reply:0:9
The XEP-0308-aware client would then display something like
Alice: Third (edited)
Bob: > Alice wrote: (link to above message "Third")
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org Second (edited)
Reply
The XEP-0308-unaware client would instead display something like
Alice: First
Alice: Second
Alice: Third
Bob: > Alice wrote (link to above message "Second")
Second
Reply
I think this is fair.
For XEP-0424 my personal suggestion would be, that a retraction for
a corrected or correction message, should only be understood as a
retraction of that revision of the message. If that revision is not
the latest (the message was corrected further later) retracting an
older revision has no effect - this also applies to the original
message. This makes the behavior across XEP-0308-aware and -unaware
clients the most consistent:
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Alice retraction-of=b
The XEP-0308-aware client would then display something like:
Alice: Third (edited)
It the client supports showing a correction history, it would
display that the second revision of the message was retracted. If
instead the latest revision is retracted, the previous
(unretracted) revision is displayed.
The XEP-0308-unaware client would instead display something like:
Alice: First
Alice: (retracted)
Alice: Third
Only once all revisions of a message have been retracted, such
message will completely be retracted (for both XEP-0308-aware and-
unaware clients). As such, if a client wants to remove a message
with corrections entirely, it should send retractions for each
revision (it's probably worth explicitly allowing this to happen in
a single message).
If we agree on above for XEP-0424, XEP-0425 wouldn't strictly need
any additions. And because XEP-0308 is based on the messages @id
even in MUCs and we don't want to ask MUC servers to keep track of
those, there's not a lot a MUC server can do here either.
Marvin
On Mon, 2025-04-21 at 17:01 +0200, Philipp Hörist wrote:
XEP-0444 specifies it in the business rules,
although its not
very strict, basically says you should use the original id but
everyone should also support everything else.
XEP-0308 does not overwrite the original message id, the client
just replaces the payload of the message.
From XEP-308
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
If the same message is to be corrected several
times, the id of
the original message is used in each case (e.g. If a message of
id 1 is corrected by a message of id 2, a subsequent correction
should correct 1, not 2).
So all corrections point to the original message.
I would argue the case if the corrections XEP itself always
references the original message, all other XEPs should do aswell.
Regards
Philipp
On Mon, Apr 21, 2025, at 16:41, Tedd Sterr wrote:
Additionally, XEP-0444 (Message Reactions), and
pretty much
anywhere an ID will ever be used to reference another message.
The issue stems from XEP-0308 replacing/overwriting the message
ID, and consequently all references already using the previous
message ID are left pointing to a non-existent message.
Amongst other things, this provides a way to avoid moderation —
send an offensive message, it gets moderated, just LMC the
message and it's no longer moderated.
So, while it feels 'wrong' from a purist view, NOT replacing
the message ID would be the better option - old and new
references will then all point to the same message. Otherwise,
presumably, clients (and servers?) will be required to track
all past message IDs for each corrected message.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
4:26 p.m.
Hi,
Actually i thought about the tombstone problem myself a few days ago, and i also don't
see another solution than to retract all revisions, otherwise we would need to implement
some corrections aware server, which is probably overkill when the client can simply send
out 3 moderate messages instead of one. I guess in practice moderating/retracting often
corrected messages will probably not be the case anyway.
This of course will pose a problem for many clients, as nothing in 308 even hints at it
being necessary to keep all correction ids around, which would now be a necessity to
implement message moderation and retraction.
I vaguely remember that multiple clients simply replace the content of the original
message in the database and probably not storing correction message ids.
Also for reactions (XEP-0444) this feels all crazy complicated, if you have to gather
reactions over multiple messages, deduplicating, then picking the right message id if you
want to change your reaction, because you reacted on the 2nd of 3 corrections ..
Maybe im the only one, but all this feels quite hard to implement and get right,
especially if you don't know all this beforehand and try to gradually implement a new
xmpp client. If you make the wrong architecture decision when implementing corrections,
you can go back to zero.
Also libraries cannot help with that at all, because its all in the right database design
from start.
All in all it feels a bit frustrating to implement these new reference XEPs.
I expect that many bugs will plague the eco system because of how complicated they can get
to implement.
Regards
Philipp
On Mon, Apr 21, 2025, at 22:40, Marvin W wrote:
Hi,
XEP-0308 is currently not a requirement of XEP-0424/0425/0461 and is largely an unrelated
feature. It's of course possible to design around it being a requirement, but that
also would be weird, given that XEP-0308 has a number of known limitations (e.g.
correcting older than the latest messages is explicitly out of scope) and thus is likely
to be replaced eventually.
As long as XEP-0308 is not a requirement, you must live under the assumption of some
clients supporting it and some not supporting it. There's also a number of practically
relevant cases where XEP-0308 can't be used safely (e.g. semi-anonymous MUCs without
occupant-id, if the messages are received from archive or without all participants online
between the original message and its correction) and clients are also typically partial
knowledge, meaning they might not be able to fully comply with XEP-0308 (e.g. if they
don't know the original message because it is out of the sync window). As such, it is
just a sane default to assume that even if clients are aware of XEP-0308, they might not
be able to use it. And to extend on this, it's easier to just assume the client does
not support it (because every client can just fallback to the behavior of not supporting
it).
XEP-0424/XEP-0425 apply to almost all clients - even if they only support very basic XMPP
features - simply due to it potentially tombstone'ing the message before it arrives at
a client. The behavior of tombstone'ing becomes very vague if you include XEP-0308 and
only the reference the original message, as it means only that is tombstone'd, not any
of the other revisions, which thus remain stored and available. If later a client syncs
the correction, but not the tombstone, it wouldn't even know that the message was
meant to be retracted, simply because it's out of the sync window.
For the reasons laid out before, a rule to require to always only reference the initial
message in a multi-revision scenario is conceptually flawed in that the sending client
might just be unaware what the initial message was. In XEP-0308 that was acceptable, given
the restrictions it puts on the sending clients (by only allowing to edit ones own last
message).
As a side note: XEP-0308 is currently stable, but lacks multiple of the formal
requirements for being stable, as it has neither a schema, nor a normative description of
the <replace/> element, but only an example.
Marvin
On Mon, 2025-04-21 at 21:04 +0200, Philipp Hörist wrote:
Hi,
Not sure why you spec out stuff for XEP-0308 non-aware clients.
XEP-308 is the oldest, its in all the compliance XEPs as a core feature that every IM
Client should support, i think we all agree its a core part of any messenger application.
Why would it be a problem for these XEPs to depend on XEP-308? You solve a problem nobody
has.
You state
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
And I agree that we should generally apply the
same logic to other XEPs.
then go on and make an over engineered spec to do exactly the opposite.
We changed XEP-0308 to make it extra so that it is not a chain, that all corrections
reference always the original, now you want to introduce right now 4 different XEPs that
in the future can reference any of these in between correction messages?
The sane thing to do is, reference the original message, always. An easy rule, no need to
define what it means if the 2nd of 3 corrections is retracted or moderated or replied to.
Regards
Philipp
On Mon, Apr 21, 2025, at 19:04, Marvin W wrote:
Hi,
I understand the nature of XEP-0308 in such that it changes the body of another message
and is not to be understood as a message itself. This is why if the same message is
corrected multiple times, they all refer to the initial message id. And I agree that we
should generally apply the same logic to other XEPs.
That said, other XEPs don't depend on XEP-0308 and generally should not assume
XEP-0308 to be supported by sending or receiving clients. Thus these XEPs don't only
need to specify "which ID should be used when a message was XEP-0308 corrected",
but also might specify other rules and need to consider how this will behave with other
clients supporting or not supporting XEP-0308.
For XEP-0461, I think the best handling would be, that it is allowed to reference not
only the initial message, but also any of the corrections. If entities receive a reply to
a message that was corrected later (or was a correction itself) it may decide the display
the body of this specific iteration of the message (instead of the latest iteration) if it
displays the body of the message replied to next to the reply.
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Bob reply-to=b body="> Second\nReply" fallback=reply:0:9
The XEP-0308-aware client would then display something like
Alice: Third (edited)
Bob: > Alice wrote: *(link to above message "Third")*
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org Second (edited)
Reply
The XEP-0308-unaware client would instead display something like
Alice: First
Alice: Second
Alice: Third
Bob: > Alice wrote *(link to above message "Second")*
Second
Reply
I think this is fair.
For XEP-0424 my personal suggestion would be, that a retraction for a corrected or
correction message, should only be understood as a retraction of that revision of the
message. If that revision is not the latest (the message was corrected further later)
retracting an older revision has no effect - this also applies to the original message.
This makes the behavior across XEP-0308-aware and -unaware clients the most consistent:
For the following log of messages:
- from=Alice id=a body=First
- from=Alice id=b correction-of=a body="Second"
- from=Alice id=c correction-of=a body="Third"
- from=Alice retraction-of=b
The XEP-0308-aware client would then display something like:
Alice: Third (edited)
It the client supports showing a correction history, it would display that the second
revision of the message was retracted. If instead the latest revision is retracted, the
previous (unretracted) revision is displayed.
The XEP-0308-unaware client would instead display something like:
Alice: First
Alice: (retracted)
Alice: Third
Only once all revisions of a message have been retracted, such message will completely be
retracted (for both XEP-0308-aware and- unaware clients). As such, if a client wants to
remove a message with corrections entirely, it should send retractions for each revision
(it's probably worth explicitly allowing this to happen in a single message).
If we agree on above for XEP-0424, XEP-0425 wouldn't strictly need any additions. And
because XEP-0308 is based on the messages @id even in MUCs and we don't want to ask
MUC servers to keep track of those, there's not a lot a MUC server can do here
either.
Marvin
On Mon, 2025-04-21 at 17:01 +0200, Philipp Hörist wrote:
XEP-0444 specifies it in the business rules,
although its not very strict, basically says you should use the original id but everyone
should also support everything else.
XEP-0308 does not overwrite the original message id, the client just replaces the payload
of the message.
From XEP-308
> If the same message is to be corrected several times, the id of the original message
is used in each case (e.g. If a message of id 1 is corrected by a message of id 2, a
subsequent correction should correct 1, not 2).
So all corrections point to the original message.
I would argue the case if the corrections XEP itself always references the original
message, all other XEPs should do aswell.
Regards
Philipp
On Mon, Apr 21, 2025, at 16:41, Tedd Sterr wrote:
> Additionally, XEP-0444 (Message Reactions), and pretty much anywhere an ID will ever
be used to reference another message.
>
> The issue stems from XEP-0308 replacing/overwriting the message ID, and consequently
all references already using the previous message ID are left pointing to a non-existent
message.
>
> Amongst other things, this provides a way to avoid moderation — send an offensive
message, it gets moderated, just LMC the message and it's no longer moderated.
>
> So, while it feels 'wrong' from a purist view, NOT replacing the message ID
would be the better option - old and new references will then all point to the same
message. Otherwise, presumably, clients (and servers?) will be required to track all past
message IDs for each corrected 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
24 Apr
24 Apr
2:38 p.m.
Hi,
And what about Reactions? Reactions can land on any revision of corrected messages also.
revision 0 has 10 reaction
revision 1 has 2 reactions
revision 2 has 1 reaction
if revision 0 is retracted or moderated, should we then also lose the 10 reactions?
My gut feeling would says no, it should be no problem to display to a user the timestamp
when a reaction was made and the timestamps of the revision history.
If we lose the 10 reactions, we basically set an incentive for the user to not correct
messages anymore.
Kind regards
Philipp
25 Apr
25 Apr
6:19 a.m.
People send reactions in response to the meaning of the message content, not to the
individual stanza (of which they're largely unaware.)
So, even though the message correction is a new stanza, unless it changes the meaning of
the content, their reactions are still valid for that content's meaning.
Obviously it's possible for someone to change the meaning of the content after the
fact, but the vast majority of corrections are either fixing typos or adding
clarification, and to degrade the user experience by throwing away all previous reactions
on a worst-case basis of 'somebody could do bad things' is a poor choice. In the
worst case, you'd get reactions that are inappropriate, but it's not quite a
disaster (particularly when the edit history is available.)
19
days inactive
23
days old
8 comments
3 participants
participants (3)
-
Marvin W -
Philipp Hörist -
Tedd Sterr