[Standards] Proposed XMPP Extension: Message Fastening

Florian Schmaus flo at geekplace.eu
Mon Sep 9 19:37:51 UTC 2019

On 9/5/19 7:52 PM, Jonas Schäfer (XSF Editor) wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Message Fastening
> Abstract:
> This specification defines a way for payloads on a message to be
> marked as being logically fastened to a previous message.
> URL: https://xmpp.org/extensions/inbox/fasten.html

Thank you, Kev for pushing this forward. I think the kind of attention
this ProtoXEP already has received, shows that the XMPP ecosystem needs
such a XEP and the community desires one.

I want to suggest one small change to how the attached-to message is
specified: I always assumed that, if xep359 is used to refer a message,
the reference would not just be the id-value, but a tuple of id-value
and the id-assigning-entity address.
This avoids ambiguity if a <apply-to/> attaches to a stanza which
multiple <stanza-id/> elements. Furthermore, xep359 makes it very clear
that xep359-IDs are just unique and stable within the scope of the
id-assigning-entity (this allows implementations to use simple
mechanisms to generate the ID without considering collisions with other

So assume we have

<message from='room at muc.example.org/Kev' …>
  <stanza-id xmlns='urn'xmpp:sid:0'
             by='room at muc.example.org'/>

The according <apply-to/> element should include a 'id-by' (name is
subject to bikeshedding) attribute:

<apply-to xmlns='urn:xmpp:fasten:0'
          id-by='room at muc.example.org'/>

I was not yet able to conclude how it should look like for 1:1 chat and
<origin-id/>. However, I assume that the only relevant case where you
want to attach to via <origin-id/> is 1:1 chat. All other cases I can
think of right now, like MUC and MIX, would have the room/channel as
id-assigning-entity and therefore use <stanza-id>. Then the value of
'id-by' attribute could potentially be the full JID of the sender in
case of <origin-id/>.

That is my main concern with the current ProtoXEP right now. However, I
am probably going to think a little bit more about it, which could lead
to some more feedback.

What follows are some nits and remarks in no particular order:

Please remove "that contains content" from the very first sentence, to
make it more readable.

Explicitly referring to Entity Capabilities (XEP-0115) in § 2. is
redundant and prone to becoming outdated. I wish XEPs would instead
point to a location, for example in XEP-0030, where the interested
reader can read more about the current state of affairs regarding
feature discovery caching mechanisms. I would be happy to create such a
location if there is a consensus that this is a good idea.

The <external/> element should always state the QName of the external
element. I suggest we normalize the namespace of <body/>, and the other
few elements that carry multiple namespaces, to jabber:client.

The semantic of attaching again to a message which we already attached
to while using replace=false should be spelled out. Assuming 'false' is
the default value for the 'replace' attribute. I probably need to think
some more about it, but it feels like replace='true' is like a reset: It
doesn't just replace a single "attachment" but all previously attached
messages (regarding the child payload in question). Is that correct?

- Florian

More information about the Standards mailing list