[Standards] Disappearing timers for OMEMO proposal

Alexander Krotov ilabdsf at gmail.com
Sun May 13 13:53:34 UTC 2018


On Sun, May 13, 2018 at 12:38:03PM +0200, Jonas Wielicki wrote:
> On Samstag, 12. Mai 2018 19:55:52 CEST Paul Schaub wrote:
> > Hi!
> > 
> > I get what you want to achieve, but I think it would be easier to define
> > disappearing messages for general XMPP (not only OMEMO).
> > 
> > As already stated, you cannot trust devices that announce support, to
> > actually delete messages after the timer expired. Lets assume you do
> > trust all involved devices. Lets see how to deal with legacy devices.
> > Why not specify ephemeral messages like this:
> > 
> > <message blabla="...">
> >     <timer secs="300">
> >         <body xmlns="jabber:client">This is an ephemeral message</body>
> >     </timer>
> > </message>
> 
> This is awful. It will require the message to carry a non-empty <body/> to 
> deal with the MAM/Carbons mess (and also to help users of clients which do not 
> support this feature).
> 
> In addition, this breaks all XEPs which depend on the <body/>, like References 
> and 394.

We already place dummy body when we use encryption. Why is this awful?

How about placing the whole message inside <ephemeral>, including
XEP-0394 <markup> elements etc., and adding a dummy <body> saying "this
is an ephemeral message, XEP-xxxx".

Clients that support <ephemeral> will extract its contents and place
it inside a <message>, replacing existing elements indented for
legacy clients. Then parse <message> as usual and setup a timer to
remove it once it expires.

This way XEP-0394 <markup> will apply only to ephemeral <body>, and
legacy <body> will not be affected.


More information about the Standards mailing list