[Standards] Proposed XMPP Extension: MAM Fastening Collation

Marvin W xmpp at larma.de
Wed Jan 8 18:22:37 UTC 2020



On 1/8/20 5:25 PM, Florian Schmaus wrote:
> After briefly reading this thread, it is my impression that Dave wants
> to pursue a generic approach to referencing/linking/fastening messages
> and the related MAM retrieval, while you argue that a use-case specific
> approach is required (at least in some cases). Is that summary correct?

I think a generic approach of referencing/linking/fastening is possible.
XEP-0367 already does so in a very generic way. Related MAM retrieval
would also be possible generically.

What I don't think is possible or makes sense in a generic way is
"summarizing". This is what makes two <reaction emoji="👋" /> from two
senders being presented through MAM as <reaction emoji="👋" count="2" />
(not to be taken verbatim) and what ensures that you only retrieve the
latest edit with an message.

And to make this "summarizing" look like it's possible for now, XEP-0422
and MAM-FC are adjusted so that things indeed do work for reactions and
edits (I am not even convinced of those, but I feel Dave is open to
adjustments to his MAM-FC proposal such that those could work). But I
don't see a bright future for upcoming new concepts because they could
impossibly be considered while drafting this XEP.

> That does read like current design of xep422 and MAM-FC (?) disallows to
> explore your approach. And I'd really like to understand what is causing
> this. How exactly does "requiring all XEPs to use XEP-0422" hinder
> exploring other approaches? Couldn't you just add the extension of those
> other approaches together with the xep422 extensions? Why does the
> current design of xep422 prevent messages "that are compatible with
> both" (what is both here?)?

I'll try to outline this using reactions as an example here. The current
proposal of XEP-0422 + MAM-FC requires a reactions XEP to have the
following wire format to work as expected:

<message from="sender at server.example">
  <apply-to xmlns="urn:xmpp:fasten:0" id="message-to-react-to">
    <reaction xmlns="urn:example:reaction" emoji="👋" />
    <reaction xmlns="urn:example:reaction" emoji="👣" />
  </apply-to>
</message>

This is a message updating the reactions of sender at server.example for
message-to-react-to to be 👋 and 👣. This wire format is basically
enforced to be like this, because the "summary" of each fastening is
defined to be the qualified name and the direct attributes of the top
level element of it. Each child element of an <apply-to> is considered a
separate fastening (according to XEP-0422), and this is required so that
the server can correctly count the emojis (according to MAM-FC proposal).

If you have a message that tries to be compatible with two different
approaches of "smart mam", the fact that content elements have to be
inside the XEP-0422 apply-to for the proposed MAM-FC, means that if you
don't want duplication of the content you have to use XEP-0422 as well.

However XEP-0422 isn't just some syntax thing, it also carries some
semantics that might be in conflict with other approaches or ideas. For
example it is not possible to use XEP-0422 to attach something that
consists of multiple elements (because each child element is a separate
fastening and fastenings of different types may also not appear in the
same message). Also each occurrence of a fastening of a certain type is
considered a replacement of all previous fastenings of that type. Under
section 3.4 of XEP-0422, every fastening can be removed, which may not
be wanted for some fastenings (how can it make sense to remove a receive
confirmation?)

I don't see a route forward on how to really solve this issue. I feel
that XEP-0422 is already very much targeted to be solely used with the
proposed MAM-FC and the other way round (which kind of makes me question
why they are two separate XEPs). And I don't think the authors are
interested in changing this.

If XEP-0422 really was generic and didn't have any semantic, it should
be OK to do something like this:

<message from="sender at server.example">
  <apply-to xmlns="urn:xmpp:fasten:0" id="message-to-react-to">
    <reactions xmlns="urn:example:reactions:0">
      <reaction>👋</reaction>
      <reaction>👣</reaction>
    </reactions>
  </apply-to>
</message>

Or even:

<message from="sender at server.example">
  <apply-to xmlns="urn:xmpp:fasten:0" id="message-to-react-to">
    <external name="reactions"
element-namespace="urn:example:reactions:0" />
  </apply-to>
  <reactions xmlns="urn:example:reactions:0">
    <reaction>👋</reaction>
    <reaction>👣</reaction>
  </reactions>
</message>

Which would make the proposed MAM-FC rather useless, even if other
proposals may be able to handle this just fine. The first is an example
where the fastening can at least fully decide on their wire format. The
second even has forward compatibility built in, because a future
replacement for fastening could just also support something like
external, like this:

<message from="sender at server.example">
  <fasten xmlns="urn:example:fasten:2" id="message-to-react-to">
    <ref name="reactions" ns="urn:example:reactions:0" />
  </fasten>
  <apply-to xmlns="urn:xmpp:fasten:0" id="message-to-react-to">
    <external name="reactions"
element-namespace="urn:example:reactions:0" />
  </apply-to>
  <reactions xmlns="urn:example:reactions:0">
    <reaction>👋</reaction>
    <reaction>👣</reaction>
  </reactions>
</message>

Sorry, again a super long message, hope I am not causing more confusion.

Marvin


More information about the Standards mailing list