Re: [Standards] Disappearing timers for OMEMO proposal

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

Re: [Standards] Disappearing timers for OMEMO proposal

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

Re: [Standards] Disappearing timers for OMEMO proposal

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

Re: [Standards] Update to MIX 0.9.7

> -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ó:

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

Re: [Standards] Disappearing timers for OMEMO proposal

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

Re: [Standards] Disappearing timers for OMEMO proposal

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,

Re: [Standards] Disappearing timers for OMEMO proposal

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

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

Re: [Standards] Disappearing timers for OMEMO proposal

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

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

Re: [Standards] Disappearing timers for OMEMO proposal

> 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

Re: [Standards] Disappearing timers for OMEMO proposal

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

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

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

Re: [Standards] Disappearing timers for OMEMO proposal

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

Re: [Standards] Disappearing timers for OMEMO proposal

> 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

Re: [Standards] Update to MIX 0.9.7

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

Re: [Standards] Update to MIX 0.9.7

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

Re: [Standards] Update to MIX 0.9.7

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

Re: [Standards] Update to MIX 0.9.7

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

Re: [Standards] Update to MIX 0.9.7

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

Re: [Standards] Update to MIX 0.9.7

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.

Re: [Standards] Update to MIX 0.9.7

> 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

Re: [Standards] Update to MIX 0.9.7

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

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

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

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

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

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 >

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

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

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

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

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

Re: [Standards] Disappearing timers for OMEMO proposal

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