24 Dec
2024
24 Dec
'24
3:52 a.m.
Hey hey,
On Thu, 19 Dec 2024 at 09:21, Daniel Gultsch <daniel(a)gultsch.de> wrote:
This message constitutes notice of a Last Call for
comments on
XEP-0424.
Title: Message Retraction
Abstract:
This specification defines a method for indicating that a message
should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on
2025-01-06.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes, I think so. On the subject of whether it could be included within the
scope of "last message editing", I think that's a clear no -
"changing" a
message to be retracted is a very different concept, with different
implications, than "removing a message".
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes.
3. Do you plan to implement this specification in your
code? If not,
why not?
No! But only because I don't really do much client stuff. It's possible,
though, and if I do need to [try to] retract a message, it'll be with this
specification.
4. Do you have any security concerns related to this
specification?
Always! I think in this case the Security Considerations are quite light.
In particular, there is no discussion of how a message might be
deliberately retracted as a form of abuse - this is perhaps worst in cases
where the tombstone support is implemented.
In general, I think any specification which seeks to "change history" ought
to have this as a consideration.
5. Is the specification accurate and clearly written?
Yes.
6. Do I think it gets everything as right as can be before we set it in
stone?
I'm curious about the use of origin-id here. I thought from previous
discussions we'd decided that origin-id only had value within certain MUC
cases; whereas the origin-id is explicitly only for 1:1 messaging here.
Does this mean any message to be retracted has to use an origin-id, and
(therefore) a client must send all 1:1 messages with an origin-id?
Do we want to make it use the stanza id attribute instead? If not, why not?
It seems that XEP-0308 handles this fine without the use of origin-id.
What do existing clients do? Do they all really inject an origin-id for
this one case (are there any others?)
Dave.