[Standards] Disappearing timers for OMEMO proposal

Alexander Krotov ilabdsf at gmail.com
Thu May 10 22:52:53 UTC 2018


On Thu, May 10, 2018 at 09:02:18AM +0200, Philipp Hörist wrote:
> Your proposal seems very complicated and impossible to understand for
> normal Users

Users only need to understand the UI. As I imagine it, it will
consist of two actions: switching encryption to OMEMO+Timers (just
like you switch it to OMEMO today) and a button with a drop-down
list to choose timer value.

> - They dont even know to which device they are sending a message. Most
> clients work on hiding resources from users, not bringing them back
> into the UI. You want users caring about resources? Naming them
> accordingly to the device, so other users can better guess what the
> device is they are sending a message to?

First of all, to avoid confusion: I use the word "device" as defined in
<https://xmpp.org/extensions/xep-0384.html#glossary>. "Resource"
is never mentioned in XEP-0384 so I would like to avoid it, because
relation of "resource" to "device" may be not one-to-one. Devices
are allowed to go offline and reuse the resource. Vice versa, device
can change its resource without changing its identity.

I don't want to bring contact's device list into the UI. Point 1
("a way to discover disappearing message timer support per device")
is not about the UI, but about the protocol.

I want to advertise device timer support not to display it to the
user.  It is to make sure a <key> element is not included for devices
that won't honor timer support.

For example, if I have a desktop client with OMEMO+Timers support,
and a phone with OMEMO support, I want to advertise that my phone
doesn't support timers, so my contacts don't include the corresponding
key in disappearing messages. Then, my phone won't be able to decrypt
the message and I don't have to clear the history on my phone manually.

> - you cite *not for situations where your contact is your adversary*
> and still take then multiple steps to ensure messages are deleted on
> other devices. Its doomed to fail, dont even try.

Please elaborate. None of the steps taken are to delete messages
on devices whose owners install faulty clients that don't implement
the extension correctly. I.e., they won't help in the case when
your contact is your adversary.

> - I dont even want to get into point 4.

...

> In my opinion this XEP should be very small, add a <timer> tag and use
> it only with encryption, then hope most clients implement it - done.

It won't work in the use case described above, when some of my clients
support timers and some don't. I would rather not receive disappearing
messages on these devices than cleanup the history on them manually.

I want timers to work reliably in all cases when neither me nor my
contact uses a faulty client. And I want to cover the case when
some clients are legacy, i.e., don't implement timers extension at
all.


More information about the Standards mailing list