[Standards] Proposed XMPP Extension: Message Fastening

Philipp Hörist philipp at hoerist.com
Thu Dec 12 13:53:24 UTC 2019


Hi,

The current approach is not good for full stanza encryption. And we have to
assume full stanza encryption will become the norm at some point so any
proposal should have that in mind.
Full stanza encryption does not mean Full stanza encryption. There are
elements that are never encrypted, for example store hints for the server,
delay elements added by the server, and im sure i will find one or two more.

Full stanza encryption means, we encrypt everything that makes sense and
don't negatively impact usability.

This is a pretty substantial feature so to fallback to a "Download the
whole archive" approach to make it work is not a good solution for me and
will probably lead to fastening not working with full stanza encryption

The solution for me is to separate metadata and content

So instead of

<message id="6" from="user2 at chatservice.example"
to="chatroom at chatservice.example">
  <apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-1" replace='true'>
      <i-like-this xmlns='urn:example:lik'>Very much</i-like-this>
  </apply-to>
</message>

lets do something like

<message id="6" from="user2 at chatservice.example"
to="chatroom at chatservice.example">
<apply-to xmlns="urn:xmpp:fasten:0:metadata" id="origin-id-1" />
<apply-to xmlns="urn:xmpp:fasten:0:content" >
      <i-like-this xmlns='urn:example:lik'>Very much</i-like-this>
</apply-to>
</message>

This allows us to encrypt content but not the metadata, and in turn allows
the server archive to do some magic, for example if we want to request all
messages which were fastened to another message.

Keep in mind if this metadata leak is a problem for a client, nobody forces
a client to support fastening while encryption is activated. But it should
be possible if the user wishes.

Regards
Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191212/4f8ce5a4/attachment.html>


More information about the Standards mailing list