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. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
