[Standards] XMPP Council Minutes 2018-05-09

[Tedd Sterr]

http://logs.xmpp.org/council/2018-05-09/#15:00:03

1) Roll Call - https://en.wikipedia.org/wiki/The_Roll_Call
Present: Dave, Daniel, Sam, Kev
Apologies: Georg

2) I wonder if Tedd Sterr is doing the minutes
(Tedd has already confirmed willingness to do the minutes until further notice.)
Dave would like it noted that he likes Tedd doing the minutes.

3) Adopt Proposed new XEP: XMPP Connections across HTTPS (HACX) - 
https://xmpp.org/extensions/inbox/hacx.html
Kev proposes this vote be put off until next week, given the author's intention 
to update the XEP to address identified issues.
Dave is not convinced any amount of editing will make it acceptable, but is 
happy to defer voting if others think it worthwhile.
Sam is also happy to defer voting, but has concerns and would like the 
opportunity to give it further consideration.
Dave makes some mystical hand gestures and ordains this item was never on the 
agenda; it will conveniently reappear next week.

4) XEPs Stuck In Proposed
Dave mentions the discussions on-list and asks whether there were any specific 
proposals (i.e. PR to XEP-0001); Kev says he made a specific proposal, but not 
as a PR. Kev thinks being stuck in Proposed state is a feature; Dave thinks 
it's symptomatic of a different problem, but agrees the ability to see what's 
stuck is a feature.
Kev outlines his proposal: at the end of a Last-Call council votes on 
advancement (Proposed->Draft), if the vote fails then council votes on 
rejection (Proposed->Rejected), if that vote fails then the XEP reverts to 
Experimental (Proposed->Experimental); if there are no further updates within 
the deferral period, it moves to Deferred (Experimental->Deferred).
Dave thinks this is not awful (dislikes the double-vote). Kev suggests this 
solves the stuck-in-proposed problem, while still keeping the ability to see if 
something has been forgotten, and allows straightforward deferral if 
advancement-stopping issues are not addressed. Kev agrees the double-vote is 
icky, but couldn't think of anything better; Dave at least prefers this 
solution to the current situation or removing the Proposed state.
Sam thinks this should be something that's discussed each time, and how that's 
done is less important; though more procedure seems worthless, it's fine if it 
forces discussion.
Dave is unsure of the utility of the Rejected state, given that it's virtually 
never used; Kev suggests that sometimes XEPs are accepted into Experimental 
without really expecting further advancement, but the barrier to Experimental 
should necessarily be low to allow for experimentation, and failed experiments 
can be Rejected. Dave agrees, but this has been done virtually never, as XEPs 
are more often left to whither to Deferred instead and fished out as desired.
Dave takes on the action to write up Kev's proposal as a PR; Kev is gratified.

Sam doesn't think voting to reject is a policy problem; (previously, as an 
editor) he would revert XEPs back to experimental when he remembered, but often 
not, due to the manual and laborious editor process.
Kev fears the possibility that somebody could accuse Council of not following 
the formal process, so process should match what is done; and while rejecting 
shouldn't really be necessary, it allows protection against a bad actor abusing 
the XEP process.
Dave suggests an appeals process may be needed to allow people to ask Board to 
investigate if they think Council isn't following the process; and XEP-0001 
should document what Council actually does.
Sam doesn't disagree with documenting what Council is doing anyway, but doesn't 
expect it will change or solve anything.

5) AOB
Dave hears the sound of one hand clapping.

6) Next Meeting
2018-05-16 1500 UTC

7) Close
Kev takes it upon himself to personally thank each and every one of the 
meeting's attendees.

Dave apologises for his recent poor performance, but is optimistic about now 
being able to dedicate more time to XMPP activities, instead of gallivanting 
about the country and single-handedly financing the British railway.
Peter reminds Dave that performance reviews happen in October, so there is 
still time to get that approval rating back up.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Alexander Krotov]

On Thu, May 10, 2018 at 02:31:27PM +0200, VanitasVitae wrote:
> Am 10. Mai 2018 14:24:47 MESZ schrieb "Remko Tronçon" :
> >I don't see why a XEP for data retention hints needs to be tied to
> >other XEPs like
> >OMEMO, though.
>
> I'd also rather not tie it to OMEMO. The same principle of
> disappearing messages could also be applied with other crypto in
> mind, or even no crypto at all. Remember, this functionality is not
> designed to give you any (serious) security improvements. Its rather
> a function which teenagers find neat and which was implemented in
> Signal for some reason.

Disappearing messages without end-to-end encryption and forward
secrecy are useless at best. They give the user false sense of
security. That is why Telegram implements timers for "secret" chats
only I believe, as I said in the first message.

The function you are talking about ("a function which teenagers
find neat") is not what I described in the first message. I
specifically stated that implementing "snapchat" is a non-goal.
This function works only if message contents is never distributed
outside the small trusted group of users.

Use case I have in mind is when the contents of your device is
leaked some time later after *private* conversation. Forward secrecy
alone does not help if message contents is retained. There is no
reason to securely delete old keys if you retain plaintext message
on the same device.

I will try to describe it as clearly as possible in the "Use Cases"
section. As all previous discussions on disappearing messages (this
list, GitHub, etc.) show, it is always the source of confusion.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Alexander Krotov]

On Thu, May 10, 2018 at 02:24:47PM +0200, Remko Tronçon wrote:
> > In federated environment you can't control what client is used
> > by remote party, and if it really does delete messages after timer expires.
> 
> True, but it would still be a useful in a situation where you trust
> the other parties
> (e.g. non-federated setup where you know which clients are being used).
> And even in a non-federated environment, you can't be sure that the
> other side doesn't
> retain your messages, so there's always trust involved.

Agree. It does not matter whether environment is federated or not.

Even in non-federated setup, such as Signal, I trust my contacts
not to retain or publish messages I send to them. The client is
open source, it can be easily modified to ignore timers, but I can trust
my contacts not to do it. Otherwise I don't message them.

Same is true for federated environments. When using Email+OpenPGP,
people trust each other not to leak message contents and generate strong
keys.

> I don't see why a XEP for data retention hints needs to be tied to
> other XEPs like
> OMEMO, though.

When I send a disappearing message, I want it to be decipherable
only on devices that advertised support for disappearing messages.
Therefore, I will have to go into detail and specify that  tag,
which is specified in OMEMO XEP, must not be included for devices which
don't advertise timer support.

I also want to avoid dealing with the subtle relation between
"devices" and "resources" and think in terms of "devices" only, as
defined in OMEMO XEP. Thinking in terms of "resources" will likely
lead to some bug in timer setting synchronization protocol. Or,
even worse, delivering a disappearing message to device that does
not support timers, if some device advertises this resource as
supporting timers and another device which does not support timers
connect with the same resource later.

Also, disappearing messages implicitly rely on forward secrecy. It does
not make sense to implement disappearing messages for plaintext
messages, because messages can be retained on the server and it is not
trusted. What is less obvious, disappearing messages are not worth
implementing for OpenPGP, which does not rotate keys frequently.
If the keys are not rotated, messages can be retained on the server
until the key is leaked eventually. In this case, messages effectively
disappear only when you securely delete old private key.

The only other encryption scheme worth adding timers is OTR, but it can
use much simpler protocol. Advertise timer support on both ends and add
 tag. There are only two devices, so start timer on the sender
immediately and on recevied when it is read.

If some encryption superior to OMEMO is developed later, it is
better to start from scratch and rethink all security considerations,
instead of trying to overgeneralize XEP now.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Alexander Krotov]

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

Re: [Standards] Update to MIX 0.9.7

[Steve Kille]

> -Original Message-
> From: Manuel Rubio 
> Sent: 10 May 2018 21:03
> To: XMPP Standards 
> Cc: Steve Kille 
> Subject: Re: [Standards] Update to MIX 0.9.7
> 
> Hello Steve,
> 
> El 2018-05-09 15:53, Steve Kille escribió:
> > 3.  Mandatory presence (3.9.7).   There is an option for a MIX  channel
> > to
> > require presence.  This allows a channel to specify the current MUC
> > behaviour that online clients are visible with presence (and no
> > "hidden"
> > listeners, which some might object to on privacy grounds).   This
> > cannot be
> > enforced by the MIX channel, so it is a policy that compliant MIX
> > clients
> > are expected to follow.   I have clarified this in the text.   It seems
> > useful to me, but we could drop this option if people feel it will
> > never be useful.
> 
> I think presence SHOULD NOT be mandatory. In my particular case we're not
> using presence at all and I like the flexibility to include/exclude nodes in 
> the
> features of the channel.
[Steve Kille] 

All this is doing is allowing you to create channels with mandatory presence.   
If you want a channel that has optional presence this is fine (and the default)


> 
> > 5.  6.3 (Ensuring Message Delivery) describes an important function
> > for MIX.
> > The detailed approach has issues, which Florian Schmaus flags.   Jonas
> > Wielicki also flagged the issues in Feb 2017.   I am replacing this
> > section
> > with a reference to a (yet to be written) XEP.Rationale:
> > - We clearly do not have the spec right
> > - Reliable message delivery seems like a generic capability that
> > could be used elsewhere.
> 
> I still considere that XEP-0199 (ping) fits better than use "markable"
> that is confusing because of the use of the same tag in XEP-0333 (chat 
> markers).
> It's not needed to write a whole new XEP for that IMO.

[Steve Kille] 

This is not straightforward.Lets try the separate XEP.If it comes out 
really short and is not useful anywhere else, we can consider folding it back in


Steve



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Manuel Rubio]

Hello Steve,

El 2018-05-09 15:53, Steve Kille escribió:
3.  Mandatory presence (3.9.7).   There is an option for a MIX  channel 
to

require presence.  This allows a channel to specify the current MUC
behaviour that online clients are visible with presence (and no 
"hidden"
listeners, which some might object to on privacy grounds).   This 
cannot be
enforced by the MIX channel, so it is a policy that compliant MIX 
clients

are expected to follow.   I have clarified this in the text.   It seems
useful to me, but we could drop this option if people feel it will 
never be

useful.


I think presence SHOULD NOT be mandatory. In my particular case we're 
not using presence at all and I like the flexibility to include/exclude 
nodes in the features of the channel.


5.  6.3 (Ensuring Message Delivery) describes an important function for 
MIX.

The detailed approach has issues, which Florian Schmaus flags.   Jonas
Wielicki also flagged the issues in Feb 2017.   I am replacing this 
section

with a reference to a (yet to be written) XEP.Rationale:
- We clearly do not have the spec right
- Reliable message delivery seems like a generic capability that 
could

be used elsewhere.


I still considere that XEP-0199 (ping) fits better than use "markable" 
that is confusing because of the use of the same tag in XEP-0333 (chat 
markers). It's not needed to write a whole new XEP for that IMO.


Kind regards.
Manuel Rubio.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Donnerstag, 10. Mai 2018 08:23:04 CEST Daniel Gultsch wrote:
> I implemented this several times for various closed systems. I always
> attached a per message timeout that started the moment the message was
> read.

How is this state synchronized across clients? "Displayed" Markers?

kind regards,
Jonas


signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Donnerstag, 10. Mai 2018 14:31:27 CEST VanitasVitae wrote:
> Am 10. Mai 2018 14:24:47 MESZ schrieb "Remko Tronçon" :
> >I don't see why a XEP for data retention hints needs to be tied to
> >other XEPs like
> >OMEMO, though.
> 
> I'd also rather not tie it to OMEMO. 

Agreed, if implemented, this should not be tied to OMEMO or any other E2EE.

We already have enough proliferation of E2EE technologies (and enough issues 
with partial support of the various technologies in clients). We don’t need 
another OMEMO mode.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Jonas Wielicki]

On Donnerstag, 10. Mai 2018 14:36:46 CEST Ненахов Андрей wrote:
> 2018-05-10 17:31 GMT+05:00 VanitasVitae :
> 
> 
> > I'd also rather not tie it to OMEMO.
> 
> By the way ,self-destructing messages should also be deleted from
> message archives on both sender and recipients servers. For e2ee
> messages one can argue that it's not really important if messages are
> not deleted from server, however, it's just yet another way to make
> such 'ephemeral' messages reappear on recipient's device - just by
> reading from archive.

We *can* technically "delete" from MAM-based archives, with tombstoning.

Also, if the client uses MAM for sync purposes, it won’t re-show the same 
message because internally it knows that it has already synced that part of 
the archive and won’t re-sync it. So this will actually work neatly in sync-
based clients.

Clients which use MAM in a "surf through your archives server-side" way 
without copying it locally will of course still see the message. They could 
still show it as "expired" or simply hide it from the view.

kind regards,
Jonas



signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Ненахов Андрей]

2018-05-10 19:03 GMT+05:00 VanitasVitae :
> I might be mistaken, but isn't there a message processing hint, that
> indicates that the message should not be stored in MAM? Or was it the other
> way round?

Any such hint can be easily ignored by archive.

Also, not storing messages in archive breaks reliable message delivery.

-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[VanitasVitae]

I might be mistaken, but isn't there a message processing hint, that indicates 
that the message should not be stored in MAM? Or was it the other way round?
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Ненахов Андрей]

2018-05-10 18:12 GMT+05:00 Philipp Hörist :
>> Why can't you decrypt OMEMO messages a second time? If you keep keys,
> what would stop you?
>
> then you implemented the signal protocol in a wrong way and you lose
> forward secrecy

Forward secrecy is a joke. As are functions that depend on correct
implementation by remote party. You send message, then you never have
any control over it. You might pretend that you do, but it would be
just fooling yourself.

>> yes, and I'd rather start with adding capability to delete messages from 
>> server.
> then do this, a call to the archive to delete a message can always be
> added to a xep like that at a later point.

Actually we do have such mod for ejabberd working.

-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Philipp Hörist]

> Why can't you decrypt OMEMO messages a second time? If you keep keys,
what would stop you?

then you implemented the signal protocol in a wrong way and you lose
forward secrecy

> yes, and I'd rather start with adding capability to delete messages from 
> server.

then do this, a call to the archive to delete a message can always be
added to a xep like that at a later point.

regards
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[W. Martin Borgert]

On 2018-05-10 14:31, VanitasVitae wrote:
> I'd also rather not tie it to OMEMO. The same principle of disappearing 
> messages could also be applied with other crypto in mind, or even no crypto 
> at all. Remember, this functionality is not designed to give you any 
> (serious) security improvements. Its rather a function which teenagers find 
> neat and which was implemented in Signal for some reason.

D'accord with not coupling ephemeral messages to encryption.
I would find it especially practical for unimportant messages with friends.
We just don't want all the nonsense cluttering our archives.
No need to check other sides client for that feature, of course.
It's their problem if they really like to store the noise.

Cheers
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Ненахов Андрей]

2018-05-10 17:44 GMT+05:00 Philipp Hörist :
> Thats why he wrote, it should only available for encrypted messages,
> because we have no way to delete messages from an archive.

yes, and I'd rather start with adding capability to delete messages from server.

> Also you can not decrypt OMEMO encrypted messages a second time, so if
> you delete the message once from your device, its gone for good.

Why can't you decrypt OMEMO messages a second time? If you keep keys,
what would stop you?


-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Philipp Hörist]

Thats why he wrote, it should only available for encrypted messages,
because we have no way to delete messages from an archive.

Also you can not decrypt OMEMO encrypted messages a second time, so if
you delete the message once from your device, its gone for good.

The idea in combination with OMEMO, minus all the proposed "try to
determine support on the other side" would be easy to implement and
would work

regards

2018-05-10 14:36 GMT+02:00 Ненахов Андрей :
> 2018-05-10 17:31 GMT+05:00 VanitasVitae :
>> I'd also rather not tie it to OMEMO.
>
> By the way ,self-destructing messages should also be deleted from
> message archives on both sender and recipients servers. For e2ee
> messages one can argue that it's not really important if messages are
> not deleted from server, however, it's just yet another way to make
> such 'ephemeral' messages reappear on recipient's device - just by
> reading from archive.
>
>
> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (351) 750-50-04
> http://www.redsolution.ru
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Ненахов Андрей]

2018-05-10 17:31 GMT+05:00 VanitasVitae :
> I'd also rather not tie it to OMEMO.

By the way ,self-destructing messages should also be deleted from
message archives on both sender and recipients servers. For e2ee
messages one can argue that it's not really important if messages are
not deleted from server, however, it's just yet another way to make
such 'ephemeral' messages reappear on recipient's device - just by
reading from archive.


-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[VanitasVitae]

Am 10. Mai 2018 14:24:47 MESZ schrieb "Remko Tronçon" :
>I don't see why a XEP for data retention hints needs to be tied to
>other XEPs like
>OMEMO, though.

I'd also rather not tie it to OMEMO. The same principle of disappearing 
messages could also be applied with other crypto in mind, or even no crypto at 
all. Remember, this functionality is not designed to give you any (serious) 
security improvements. Its rather a function which teenagers find neat and 
which was implemented in Signal for some reason.
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Remko Tronçon]

> In federated environment you can't control what client is used
> by remote party, and if it really does delete messages after timer expires.

True, but it would still be a useful in a situation where you trust
the other parties
(e.g. non-federated setup where you know which clients are being used).
And even in a non-federated environment, you can't be sure that the
other side doesn't
retain your messages, so there's always trust involved.

I don't see why a XEP for data retention hints needs to be tied to
other XEPs like
OMEMO, though.

Remko
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Dave Cridland]

On 10 May 2018 at 12:09, Evgeny Khramtsov  wrote:

> > essentially Joining, Leaving and Messaging, without any presence things
>
> Why we cannot use a pubsub node for this?


XEP-0060 takes a message protocol and builds a pubsub service on top.

You're suggesting that MIX should build a message service on top of this?

The problem, in my eyes, is that we have existing, well-defined, handling
for the concepts of "messages" and "presence", and I would hate to have to
deal with these entirely differently for group chat compared to for 1:1
chat.

There are always going to be differences, of course (short of forcing every
1:1 conversation into a  2-person groupchat, which has its own unique
problems), but it makes sense to me to minimize these, and reuse existing
handling wherever possible.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Kevin Smith]

On 10 May 2018, at 12:17, Evgeny Khramtsov  wrote:
> 
> Thu, 10 May 2018 12:14:12 +0100
> "Steve Kille"  wrote:
> 
>> I'm not sure that I understand your question here.   MIX does use a
>> PubSub node for message distribution.
> 
> Great. So this use case should be described in the core: i.e.
> pubsub without ad-hoc services. Other stuff (like presence, anonymous
> messaging and so on) should go into separate documents (which will
> require some additional services as I understand).

I think trying to split 369 up would be helpful, yes - although after trying we 
might find it doesn’t make much sense, we should likely at least try.

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Evgeny Khramtsov]

Thu, 10 May 2018 12:14:12 +0100
"Steve Kille"  wrote:

> I'm not sure that I understand your question here.   MIX does use a
> PubSub node for message distribution.

Great. So this use case should be described in the core: i.e.
pubsub without ad-hoc services. Other stuff (like presence, anonymous
messaging and so on) should go into separate documents (which will
require some additional services as I understand).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Kevin Smith]

On 10 May 2018, at 12:09, Evgeny Khramtsov  wrote:
>> essentially Joining, Leaving and Messaging, without any presence things
> 
> Why we cannot use a pubsub node for this?

There is no question whether we can use pure pubsub to implement something like 
MIX. Any part of XMPP can be framed in terms of pubsub - XMPP exchanges bits of 
XML, groupchat needs to exchange bits of data (that could be XML), and XEP-0060 
is one (of several) mechanisms for exchanging bits of XML. I’m sure we could 
frame the whole thing in terms of presence stanzas too, if we wanted.

The question isn’t “can we?” but “should we?”.

MIX attempts to use bits of XEP-0060 for providing these features where 
XEP-0060 is the most suitable building block, and other things where it is not. 
There are clearly some things that have better mechanisms - e.g. using presence 
for sharing presence information, and some things where XEP-0060 doesn’t give 
what we need to implement things straightforwardly - e.g. the grouping of ACL 
across several nodes based on participation.

I’m sure there are bound to be some bits we’ve got wrong at the moment, but I 
don’t think the fundamental model here is wrong.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Steve Kille]

> 
> > essentially Joining, Leaving and Messaging, without any presence
> > things
> 
> Why we cannot use a pubsub node for this? The main argument I recall is
that
> you cannot identify a sender, but this is not true, because we have a
'publisher'
> attribute. Another argument is that we cannot make it anonymous, but I
think
> anonymous publishing should be a separate extension in the first place. We
have
> some ability to set metadata, we have simple ACL configuration. So what
details
> do we need to address?

[Steve Kille] 
I'm not sure that I understand your question here.   MIX does use a PubSub
node for message distribution.


Steve


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Evgeny Khramtsov]

Thu, 10 May 2018 11:46:10 +0100
"Steve Kille"  wrote:

> Sometimes the nature of problems does not lend itself to short
> specification.The basic PubSub and MIX concepts are simple.
> However, there is a lot of devil in a lot of details that needs to be
> addressed. Ending large is not a goal, but is often a consequence
> of addressing real world problems.

Philosophic discussions aside, can you please tell what we're missing
from the use case mentioned by Jonas:

> essentially Joining, Leaving and Messaging, without any presence things

Why we cannot use a pubsub node for this? The main argument I
recall is that you cannot identify a sender, but this is not true,
because we have a 'publisher' attribute. Another argument is that we
cannot make it anonymous, but I think anonymous publishing should be a
separate extension in the first place. We have some ability to set
metadata, we have simple ACL configuration. So what details do we need
to address?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Steve Kille]

> MUC and PubSub often are used as excuse to write another big bloated XEP.
> Peter Waher also referred to them when he was faced with the same criticism.
> MUC and PubSub really can not be used as precedent for good specifications,
> they are prime examples of what is wrong with the one big monolithic
> specification approach. (PubSub in particular).
[Steve Kille] 

Aiming for small and modular is surely a good thing.   I don't think anyone 
disagrees with this.

Sometimes the nature of problems does not lend itself to short specification.   
 The basic PubSub and MIX concepts are simple.   However, there is a lot of 
devil in a lot of details that needs to be addressed. Ending large is not a 
goal, but is often a consequence of addressing real world problems.


Steve



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Update to MIX 0.9.7

[Florian Schmaus]

On 09.05.2018 15:53, Steve Kille wrote:
> Florian made some broader comments.
> 
> I do not agree with the assertion that MIX is bloated.   It provides a
> similar function to MUC and is of comparable size to the MUC and PubSub
> specs.
MUC and PubSub often are used as excuse to write another big bloated
XEP. Peter Waher also referred to them when he was faced with the same
criticism. MUC and PubSub really can not be used as precedent for good
specifications, they are prime examples of what is wrong with the one
big monolithic specification approach. (PubSub in particular).

If we want people to implement our stuff, then we need to craft slim,
easy to digest (base) specifications. Implementers should be able to
easily determine which parts of the spec are required to get an early
interoperable implementation going. This also reduces the time and
effort needed for the first "I've made it" experience.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Jonas Wielicki]

Hi Steve,

I’m interested in implementing MIX in aioxmpp and JabberCat. I consider the 
model of MUC broken (I’m not going to list the brokenness here) and unfixable 
within the existing specification.

MIX is huge, I agree. Splitting the spec seems like a good idea, but it will 
not be easy (to split it in a way that clients implementing only Base can 
interact (or detect incompatibility) with services implementing more than 
Base. If we can get this right, splitting would be tremendously useful.

The splitting point suggested by Daniel (essentially Joining, Leaving and 
Messaging, without any presence things) seems like a very good start to me.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Ненахов Андрей]

2018-05-10 14:38 GMT+05:00 Evgeny Khramtsov :
> I'm for sure vetoing MIX implementation in ejabberd in the form it's
> presented currently.

We too don't have plans to implement MIX in Xabber on any platforms.
It's too bloated and unnecessarily overcomplicated and hardly an
improvement over (insanely bad) XEP-0045.
We also don't have plans to support XEP-0045 in Xabber for Web or iOS.


-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Evgeny Khramtsov]

Thu, 10 May 2018 11:21:43 +0200
Daniel Gultsch  wrote:

> What worries me about MIX is that it looks like such a big spec that
> no body is going to implement fully that years from now we are still
> going to find 'bugs' in the XEP. Like we recently found 'bugs' (under
> specified things) in PubSub and that XEP is 15+ years old.

I agree with this (as I said many times). And I of course disagree with
the XEP author: comparing MIX with other poorly implemented monster
specs assuming that this is "normal" is beyond me.

I'm for sure vetoing MIX implementation in ejabberd in the form it's
presented currently. As I said: we just have to use pubsub and improve
pubsub spec if we miss some really basic functionality. And I agree
with Holger: if we cannot reuse pubsub for such simple functionality as
group messaging then why we need pubsub at all?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Daniel Gultsch]

2018-05-10 10:59 GMT+02:00 Philipp Hörist :
> Im interested in implementing it in Gajim
>
> It would be nice if someone could share the domains where a server
> runs that offers some kind of MIX impl.

Yeah if isode could make a mix server publicly available that would
certainly make the chicken/egg situation a bit easier.

What worries me about MIX is that it looks like such a big spec that
no body is going to implement fully that years from now we are still
going to find 'bugs' in the XEP. Like we recently found 'bugs' (under
specified things) in PubSub and that XEP is 15+ years old.
I’m not sure if there is even a 'complete' pubsub implementation out
there. And if we know that the XEP isn’t going to be implemented fully
I don’t understand why we are not splitting this into several smaller
XEPs.

I might be wrong about that but this is how I *feel* as a client developer.

I’m certainly interested in MIX in that I think we need the account
model and the better archive management.
But why not put the account model + basic message sending receiving in
a base XEP and do everything in separate XEPs?

If we can get people to implement those two things (I don’t even think
we need presence) this will already be a huge step forward for a more
modern group chat. And that doesn’t feel as overwhelming as having to
read a full MIX spec.

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Philipp Hörist]

Im interested in implementing it in Gajim

It would be nice if someone could share the domains where a server
runs that offers some kind of MIX impl.

regards
Philipp

2018-05-10 10:36 GMT+02:00 Steve Kille :
>
> Having made the latest round of MIX edits,  I felt it was time to share some
> thoughts on MIX.
>
> It has been a number of years since work was started on MIX, and
> implementations are thin on the ground.  It seems sensible consider when and
> if this will change.
>
> There are a number of reasons why MIX take-up is likely to be slow:
>
> 1.  It is a big spec to implement for either client or server, even for a
> server with a good MAM and PubSub base.
>
> 2.   The is a chicken/egg situation with clients and servers.  A server
> implementor will wait until MIX clients are available and vice versa.
>
> 3.   This does not appear to be an exciting new service (but see later).   A
> simple view of MIX is that it is just a different way of providing an
> existing service, so there is not simple customer benefit or drive for MIX.
>
> 4.  MUC broadly works.   There are lots of little things broken, but there
> is no major issue to force replacing it.
>
> 5.   MIX needs a migration.This will inherently slow things down and
> inhibit starting stuff.
>
> 6.   Some in the community are working to address issues by updates to MUC.
> From my perspective, this is "string and duct tape" and is not addressing
> deeper problems. Such activity will delay MIX.
>
> 7.   Related to the above, some feel that MIX is just too much, and this
> definitely creates a feeling of "will MIX ever happen?".
>
>
> Predicting the future is hard, but.
>
> Isode is committed to both server (M-Link COTS product) and client (Swift
> free & open source) implementations of MIX.   We have strategic reasons to
> do this, particularly because of requirements on constrained networks.   We
> have lots of other things we also need to do, but MIX is going to happen in
> our product set.
>
> It may well be that others will produce general purpose MIX implementations
> first (e.g., Surevine), but let's suppose this does not happen.
>
> It seems conceivable that MIX will end up as a specification that is useful
> for specific purposes, but not widely implemented (e.g., like XEP-0365).
>
> However,  I do not think this will happen, as MIX has many benefits.  I
> think that initial implementations will encourage others, almost certainly
> gradually at first.Once there are a few implementations, more will
> follow.   Then MIX will be seen as something that modern XMPP
> implementations need to have and other implementations will play catch up.
>
> Let me justify this in terms of MIX benefits that I see:
>- Some of the broken bits of MUC that we all live with will become much
> clearer as MIX starts to be used.  There will be a "how did I ever live with
> that" experience
>- Multi-client will become more important, and MIX will avoid a slew of
> MUC problems
>- "proper" history support will add value
>- Message only option will be important for constrained bandwidth and
> will facilitate observers (avoiding "presence clutter" from observers
>- As we work to build richer multi-user communication, with shared files,
> shared pictures, comments and likes, MIX is going to be the building block
> we need (that MUC is not)
>
> I do not think that this is going to happen quickly, but my  (biased) bet is
> that MIX is going to happen
>
>
>
> Steve
>
>
>
>
>
>
>
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Thoughts on MIX adoption (and will MIX ever happen?)

[Steve Kille]

Having made the latest round of MIX edits,  I felt it was time to share some
thoughts on MIX.

It has been a number of years since work was started on MIX, and
implementations are thin on the ground.  It seems sensible consider when and
if this will change.

There are a number of reasons why MIX take-up is likely to be slow:

1.  It is a big spec to implement for either client or server, even for a
server with a good MAM and PubSub base.

2.   The is a chicken/egg situation with clients and servers.  A server
implementor will wait until MIX clients are available and vice versa.

3.   This does not appear to be an exciting new service (but see later).   A
simple view of MIX is that it is just a different way of providing an
existing service, so there is not simple customer benefit or drive for MIX.

4.  MUC broadly works.   There are lots of little things broken, but there
is no major issue to force replacing it.

5.   MIX needs a migration.This will inherently slow things down and
inhibit starting stuff.

6.   Some in the community are working to address issues by updates to MUC.
>From my perspective, this is "string and duct tape" and is not addressing
deeper problems. Such activity will delay MIX.

7.   Related to the above, some feel that MIX is just too much, and this
definitely creates a feeling of "will MIX ever happen?".


Predicting the future is hard, but.

Isode is committed to both server (M-Link COTS product) and client (Swift
free & open source) implementations of MIX.   We have strategic reasons to
do this, particularly because of requirements on constrained networks.   We
have lots of other things we also need to do, but MIX is going to happen in
our product set.

It may well be that others will produce general purpose MIX implementations
first (e.g., Surevine), but let's suppose this does not happen.

It seems conceivable that MIX will end up as a specification that is useful
for specific purposes, but not widely implemented (e.g., like XEP-0365).

However,  I do not think this will happen, as MIX has many benefits.  I
think that initial implementations will encourage others, almost certainly
gradually at first.Once there are a few implementations, more will
follow.   Then MIX will be seen as something that modern XMPP
implementations need to have and other implementations will play catch up.

Let me justify this in terms of MIX benefits that I see:
   - Some of the broken bits of MUC that we all live with will become much
clearer as MIX starts to be used.  There will be a "how did I ever live with
that" experience
   - Multi-client will become more important, and MIX will avoid a slew of
MUC problems
   - "proper" history support will add value
   - Message only option will be important for constrained bandwidth and
will facilitate observers (avoiding "presence clutter" from observers
   - As we work to build richer multi-user communication, with shared files,
shared pictures, comments and likes, MIX is going to be the building block
we need (that MUC is not)

I do not think that this is going to happen quickly, but my  (biased) bet is
that MIX is going to happen



Steve










___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Disappearing timers for OMEMO proposal

[Ненахов Андрей]

Clients that would advertise this feature to their users will be deceiving
their users. In federated environment you can't control what client is used
by remote party, and if it really does delete messages after timer expires.

2018-05-10 12:02 GMT+05:00 Philipp Hörist :

> Your proposal seems very complicated and impossible to understand for
> normal Users
>
> - 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?
>
> - 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.
>
> - I dont even want to get into point 4.
>
> In my opinion this XEP should be very small, add a  tag and use
> it only with encryption, then hope most clients implement it - done.
>
>
> regards
>
> 2018-05-10 2:12 GMT+02:00 Alexander Krotov :
> > I propose to extend OMEMO with disappearing messages.
> >
> > There is already a thread with a subject: "Self-destruct" message
> timeout deletion hints.
> > It started with this message: https://mail.jabber.org/
> pipermail/standards/2016-October/031515.html
> > Continued in November: https://mail.jabber.org/pipermail/standards/2016-
> November/031595.html
> > Last message is from 2017: https://mail.jabber.org/
> pipermail/standards/2017-February/032092.html
> >
> > The thread was started shortly after Signal announced its implementation
> > of disappearing messages in October 2016.[1] Rationale provided in
> > the blog post is worth repeating here to avoid talking about the
> > goals of this feature again, because it causes confusion all the
> > time (emphasis mine):
> >> Disappearing messages are a way for you and your friends to keep
> >> your message history tidy. They are a *collaborative feature* for
> >> conversations where all participants want to automate minimalist
> >> data hygiene, *not for situations where your contact is your adversary*
> >> — after all, if someone who receives a disappearing message really
> >> wants a record of it, they can always use another camera to take a
> >> photo of the screen before the message disappears.
> > See also the Signal FAQ entry for disappearing messages[2].
> >
> > Implementing Snapchat-over-XMPP is a non-goal, so we don't have to
> > take into account hostile clients.  Someone may run a client that
> > advertises support for disappearing messages and does not actually
> > delete them, but it is the problem of trust between users.  Hostile
> > user may just as well run a client that advertises end-to-end
> > encryption, but leaks encryption keys or message contents later.
> >
> > The problem with previous thread is that it was about *message
> > hints*, as defined in XEP-0334[3].  Legacy clients, as well as
> > legacy or hostile servers, may not implement these hints and store
> > messages permanently without any way for users to ensure their
> > messages are deleted. Therefore, any plaintext message should be
> > assumed to be stored permanently, and there is no point in implementing
> > timers for them. Telegram developers seem to understand it too, and
> > only implement timed messages for end-to-end encrypted "secret
> > chats", in contrast to plaintext "cloud chats".
> >
> > What I propose instead of message hints is to extend OMEMO with:
> > 1. a way to discover disappearing message timer support per device,
> > 2. a way to specify timer value in messages,
> > 3. specification of timer value semantics,
> > 4. a protocol to negotiate common disappearing message timer.
> >
> > Signal solutions to these problems cannot be copied exactly for
> > several reasons, which I describe below.
> >
> > 1. A way to discover disappearing message timer support per device.
> >
> > In XMPP, some devices will never get the support for disappearing
> > messages. Therefore, disappearing messages must be encrypted only
> > for devices which advertise their support.
> >
> > Signal didn't have to deal with this problem. All devices were
> > eventually updated to the newest version of the Signal and processed
> > disappearing messages.
> >
> > As I understand from OMEMO specification[4], the best place to
> > advertise support for disappearing messages is the device bundle.
> >
> > As for UI, OMEMO+Timers can be treated simply as another encryption
> > method. User will have to choose between None, OpenPGP, OTR, OMEMO
> > and OMEMO+Timers. If user selects OMEMO+Timers, devices which only
> > support OMEMO will receive a message they can't decrypt.
> >
> > Devices that don't support OMEMO+Timers will leave the trace of
> > communication, but little can be done about it I believe. Proper
> > metadata protection, i.e., hiding the fact of communication, is
> > impossi

Re: [Standards] Disappearing timers for OMEMO proposal

[Philipp Hörist]

Your proposal seems very complicated and impossible to understand for
normal Users

- 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?

- 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.

- I dont even want to get into point 4.

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


regards

2018-05-10 2:12 GMT+02:00 Alexander Krotov :
> I propose to extend OMEMO with disappearing messages.
>
> There is already a thread with a subject: "Self-destruct" message timeout 
> deletion hints.
> It started with this message: 
> https://mail.jabber.org/pipermail/standards/2016-October/031515.html
> Continued in November: 
> https://mail.jabber.org/pipermail/standards/2016-November/031595.html
> Last message is from 2017: 
> https://mail.jabber.org/pipermail/standards/2017-February/032092.html
>
> The thread was started shortly after Signal announced its implementation
> of disappearing messages in October 2016.[1] Rationale provided in
> the blog post is worth repeating here to avoid talking about the
> goals of this feature again, because it causes confusion all the
> time (emphasis mine):
>> Disappearing messages are a way for you and your friends to keep
>> your message history tidy. They are a *collaborative feature* for
>> conversations where all participants want to automate minimalist
>> data hygiene, *not for situations where your contact is your adversary*
>> — after all, if someone who receives a disappearing message really
>> wants a record of it, they can always use another camera to take a
>> photo of the screen before the message disappears.
> See also the Signal FAQ entry for disappearing messages[2].
>
> Implementing Snapchat-over-XMPP is a non-goal, so we don't have to
> take into account hostile clients.  Someone may run a client that
> advertises support for disappearing messages and does not actually
> delete them, but it is the problem of trust between users.  Hostile
> user may just as well run a client that advertises end-to-end
> encryption, but leaks encryption keys or message contents later.
>
> The problem with previous thread is that it was about *message
> hints*, as defined in XEP-0334[3].  Legacy clients, as well as
> legacy or hostile servers, may not implement these hints and store
> messages permanently without any way for users to ensure their
> messages are deleted. Therefore, any plaintext message should be
> assumed to be stored permanently, and there is no point in implementing
> timers for them. Telegram developers seem to understand it too, and
> only implement timed messages for end-to-end encrypted "secret
> chats", in contrast to plaintext "cloud chats".
>
> What I propose instead of message hints is to extend OMEMO with:
> 1. a way to discover disappearing message timer support per device,
> 2. a way to specify timer value in messages,
> 3. specification of timer value semantics,
> 4. a protocol to negotiate common disappearing message timer.
>
> Signal solutions to these problems cannot be copied exactly for
> several reasons, which I describe below.
>
> 1. A way to discover disappearing message timer support per device.
>
> In XMPP, some devices will never get the support for disappearing
> messages. Therefore, disappearing messages must be encrypted only
> for devices which advertise their support.
>
> Signal didn't have to deal with this problem. All devices were
> eventually updated to the newest version of the Signal and processed
> disappearing messages.
>
> As I understand from OMEMO specification[4], the best place to
> advertise support for disappearing messages is the device bundle.
>
> As for UI, OMEMO+Timers can be treated simply as another encryption
> method. User will have to choose between None, OpenPGP, OTR, OMEMO
> and OMEMO+Timers. If user selects OMEMO+Timers, devices which only
> support OMEMO will receive a message they can't decrypt.
>
> Devices that don't support OMEMO+Timers will leave the trace of
> communication, but little can be done about it I believe. Proper
> metadata protection, i.e., hiding the fact of communication, is
> impossible in XMPP, so it is a non-goal for this proposal.
>
> 2. A way to specify timer value in messages.
>
> Timer value should be placed somewhere in  tag. I would
> also like to make it encrypted. Problem is, the only encrypted part
> of the message is the  which contains plaintext message
> corresponding to the contents of  and is not extensible.
>
> OX (XEP-0374) solves the problem by treating payload contents as
> the  contents, i.e., the pay