I think people are overthinking this and expecting this proposal to be a completely secure 100% guaranteed way to enforce message deletion on a client you don't control. For every messenger app, including centralized ones, this is impossible to enforce. From that perspective of course it also doesn't work on a decentralized / federated network.
The best we can do is allow trusted contacts (w/ verified OMEMO fingerprints) combined with client software advertising the feature to suggest automatic message timeouts to each other. Clearly this isn't a way to protect against an untrusted contact from logging your chat, or even a trusted contact. It's merely a suggestion. Don't like this feature? Don't advertise support. Advertising support and want to log messages anyway? Go right ahead. I don't see how allowing two trusted contacts to voluntarily agree to delete messages is a bad thing. If you don't trust your contact, why are you messaging them? The alternative is.. the status quo! Where all messages are logged forever on both ends. Honestly this is essentially a client-side only timeout for your own chats, with the bonus feature of maybe triggering deletion on the other end. We already offer an option to delete your chats after you logout, but perhaps we could offer a middle ground where your locally stored messages expire after X hours/days, and certain conversations could expire more quickly. To the people who don't like this idea.. have you ever used any ephemeral messaging features before? Do you understand the user perspective? On Tue, Nov 1, 2016 at 11:12 AM, Ashley Ward <ashley.w...@surevine.com> wrote: > > On 1 Nov 2016, at 17:43, forenjunkie <forenjun...@chello.at> wrote: > > But it doesnt work with a decentral, open source kind of system. > a feature like that depends on the other side deleting the message. > > you are lying to your users the minute you offer this feature in your > client and not show a disclaimer. > you promise the message will self destruct, but you can never be sure, > because you have no control over the other side. > you would have to show a disclaimer: We dont know if it gets deleted, we > hope it does. > > > There are a couple of ways this might be able to work (to some extent > anyway) although neither are particularly great. > > You could either: > > a) Trust the remote user. Encryption would allow you to establish a level > of trust with the recipient. I.e. you encrypt the message and mark it for > ‘self destruct’. You then have to trust the recipient to destroy it (but at > least you don’t have to trust every server along the way). This gives you > some level of reassurance that the message will be destroyed, assuming the > recipient is trustworthy (and runs trustworthy clients). > > b) Trust the remote client. If you could somehow establish a level of > trust of the remote client then you could discover that, and again have > some level of reassurance that the remote client will do the right thing. I > don’t think there’s any protocol to do this currently (i.e. certifying an > application rather than a user). It would also mean you would have to > somehow maintain a list of trusted applications/certificates. > > Without this in an open, federated network then you really can’t guarantee > anything, and the semantics are more of a message expiry (i.e. this message > is no longer valid after a certain time). > > Just some thoughts. > > — > Ash > > _______________________________________________ > 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 _______________________________________________
