[Standards] XMPP Council Minutes 2018-06-06

Alexander Krotov ilabdsf at gmail.com
Mon Jun 11 01:30:02 UTC 2018


On Sat, Jun 09, 2018 at 12:52:42AM +0000, Tedd Sterr wrote:
> 4) Proposed XMPP Extension: Ephemeral Messages - https://xmpp.org/extensions/inbox/ephemeral-messages.html
> Kev isn't entirely sure he even understands this one.
> Daniel has implemented burner messages before and doesn't think this is the way to do it.
> Dave (thinks he) mostly understands it, but doesn't see how one can do ephemeral messages reliably in an open environment. Kev thinks it's meant to be advisory, and one can do advisory ephemeral messages in an open environment.
> Sam is unimpressed, and notes that everyone seems to be in agreement.
> Dave has no idea how the advisory nature would be communicated to the user; Kev adds, as another example, dealing with the UX of messages disappearing at different times from the local archive.
> Daniel thinks there is too much weird stuff for something that is supposedly advisory; suggests simply adding <burn-after seconds="5"/> to messages, which is how he usually implements this feature.
> Daniel adds that not everyone is running XMPP in an open environment; Dave concedes.
> 
> Kev blames Lua for the intermittent server freezes.
> 
> Sam: -1
> Kev: -1
> Dave: -1 (NTP-over-XMPP is enough [of a reason])
> Daniel: -1
> Georg: [on-list] (don't like it, but have no constructive ideas how to make ephemeral messages work better)
> 
> Kev doesn't believe it is NTP over XMPP, and thinks it tries to synchronise message age for expiration.
> 
> Daniel has previously offered to document his usual approach to this, but nobody was interested, however, the offer still stands if people will find it useful; Kev suggests it might be worthwhile, if only to avoid others doing the same thing in stranger ways.

Looks like at least two different people read "timer synchronization"
as NTP-over-XMPP, so maybe I should change "timer synchronization"
(which is not the same as "time synchronization") in the introduction
to "timer setting synchronization" to make it more clear.


As for the UX of messages disappearing at different times from the
local archive, they disappear almost simultaneously on all sender
devices, because timer is started for carbon copies as soon as they
are received, not read.  For the recipient devices, timers start
at different times.  Some way to synchronize the "displayed" status
across devices is required to fix this. I will look into how other
IM systems deal with this and change ProtoXEP, although I don't
think it is critical for the first version of the protocol.


About the advisory nature, I made sure that ephemeral messages are
not sent to devices that don't advertise ephemeral message support
as long as E2EE is used. As long as you trust your contacts not to
use clients that advertise ephemeral message support but implement
it incorrectly, it will work. As for the plaintext ephemeral messages,
I don't like this idea really and was not going to specify it, but
it was requested on the mailing list during the previous discussion.
So I tried to make it work for as many legacy cases as possible by
placing the message inside <ephemeral> tag and requiring
<no-permanent-store /> message hint. It is indeed hard to make sure
user understands that messages may still be stored by legacy clients
that archive entire stanzas and servers that don't support message
hints, so I suggest that the ability to send plaintext ephemeral
messages is disabled by default and can only be enabled from "advanced
settings".


To Daniel: I am interested in the description of your implementation if
there is something more than adding burn-after tag and removing the
message after the specified timer. I am especially interested in the
timer semantics, when does the timer start on each side of the
conversations etc.

As for the "there is way too much weird stuff going on in the xep", I am
not sure what are you referring to. The most complex part is the timer
setting synchronization, and I think it is essential.

I have used both Wire (which does not have this feature) and Signal
(which is the only IM system I know of that has it). In Wire, when
I start using timers, and my contact replies several times before
enabling timers (or does not enable them at all), I end up with
replies only in my message history when message timers expire. It
makes the logs littered with replies that are not related to any
messages, while at the same time defeats the purpose of ephemeral
messages, because it may be possible to reconstruct the conversation
from the replies.


More information about the Standards mailing list