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
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
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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org