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 <> 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" [1].
> 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
> example.
> 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?
> Thanks!
> 1.
> _______________________________________________
> Standards mailing list
> Info:
> Unsubscribe:
> _______________________________________________
Standards mailing list

Reply via email to