Let the record show that I find this feature to be completely ridiculous
and I don't agree at all with Whisper Systems rational to implement this.
Data hygiene can best be achieved by a one sided feature that (optionally)
cleans all messages after a certain time period.
However I had several customers request this feature in the past and I
already implemented it once and there will be more implementations in the
near future. In that regard we might as well standardize it even though it
will probably be only implemented in closed systems were you can be
relatively certain that messages will in fact be deleted.
On Oct 19, 2016 8:33 AM, "Guus der Kinderen" <guus.der.kinde...@gmail.com>
> Do I understand this correctly: this feature depends on the author of a
> message enabling an 'auto-destruct' flag? From a user perspective, I'd be
> terribly annoyed by that. There is hardly any added security or privacy
> value in this feature, and the the data hygiene that applies to my data is
> something that I want control myself. Unless I'm chatting with my mother, I
> don't expect my peer to tell me when I need to clean my archive. If it were
> me in control of my messages (and the messages that I can retrieve from
> persistent storage, server side), that'd be another story.
> On 18 October 2016 at 23:58, Chris Ballinger <ch...@chatsecure.org> wrote:
>> Many other messaging apps are implementing features for self-destructing
>> messages. I dismissed the idea for a long time because of the impossibility
>> of actually enforcing deletion on the other side, but now I believe it
>> could be useful to help users "automate minimalist data hygiene" .
>> As far as an XMPP extension would be concerned, I think that it would be
>> important that clients can discover if another client claims to support
>> message timeouts, to allow for configurable timeouts, and work within the
>> context of a MUC. None of these hints would affect the current message
>> archiving specs because the timeouts are strictly for when a client views a
>> message, but could be used in combination with <no-permanent-store/>, for
>> Are there other scenarios that I'm missing? Would people be willing to
>> implement this into their apps? Is formalized spec for this something that
>> XSF would consider?
>> 1. https://whispersystems.org/blog/disappearing-messages/
>> 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 mailing list