On 18 October 2016 at 22:58, Chris Ballinger <[email protected]> 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? >
I would be interested in exploring this. My gut feeling is that it would end up in the Retracted/Rejected bin, because I don't think the trade-off between trying to gain assurance that well-behaved applications would honour the request, and the additional round-trips and discovery involved, would be useful, and we'd never get solid assurance that the message was truly being deleted. But perhaps having the spec and documenting the issues would be the right first step. > Thanks! > > 1. https://whispersystems.org/blog/disappearing-messages/ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
