[Standards] Proposed XMPP Extension: Message Fastening

Marvin W xmpp at larma.de
Fri Sep 6 22:11:09 UTC 2019


Just a few things I noticed while reading this proto xep:

In the introduction it describes "a server adding information on a link
previously posted to a chat room" as a use case of Fastening, which is
exactly a use cases of XEP-0367 (Message Attaching) as already pointed
to by Sam. Is it expected that XEP-0367 is updated to use Fastening
instead or basically be completely abandoned in favor of Fastening?

The business rules in §4 say that a Fastening can not have a Fastening
themselves. If both message attaching, reactions and others are realized
using Fastening, this implies that you can not react to an attached
message, for example you would not be able to thumbs-up the fact that a
bot provided a helpful attaching. While it is arguable that this is not
strictly a required feature, the restriction seems to be unreasonable in
that case.

§3.3 describes a `replace="true"` attribute that can be added to
<apply-to> to indicate that a message replaces a previous message. The
rules say that it is to be decided by the namespace and name of the
child payload, which element to replace. Does that mean that an
<apply-to> must contain exactly one element? How does this play together
with <external> elements?
What happens if a client accidentally does not add the `replace="true"`
(for example because the same element was send from two different
devices at about the same time)? Will a) there be two elements with the
same namespace and name then, b) the second silently ignored or c) the
first silently replaced? In case of a), how to decide which to replace
in the future? In case of b), how does the sending entity know if there
message was first or second? In case of c), why put `replace="true"` at
all if it is implicitly done anyways?

I see severe problems when using this together with XEP-0420 (Stanza
Content Encryption). Which content is expected to be encrypted? If the
whole stanza is encrypted, the server looses the id information and thus
can not make use of the advantage of Fastening. If we encrypt the
content of <apply-to>, the replacing logic will select the <encrypted>
element from XEP-0420 to decide which message to replace, which means
all encrypted messages would (potentially) replace each other (for
example an encrypted read marker and an encrypted thumbs up reaction).
If the encrypted content is a sibling to the <apply-to> and the
<apply-to> contains an <external> to reference inside the encrypted
content, it would leak the name of the element inside the encryption.

There is a bit of uncertainty which ID to use. §3 says <origin-id>
should be used and the examples all refer to an origin-id. §4 says
<stanza-id> must be present. IMO the correct would be to use <stanza-id>
in groupchat and either <origin-id> or message id (in that order, if
they mismatch) in chat. This behavior is also described in other XEPs IIRC.

Marvin


More information about the Standards mailing list