[Standards] "Self-destruct" message timeout deletion hints

ValdikSS iam at valdikss.org.ru
Sat Feb 4 01:05:34 UTC 2017


As a person who knows how teenagers use this functionality in proprietary and centralized messengers, I can tell it's not about information actuality, it's about transmitting a small secret you'd like to hide from a person who may watch your smartphone screen a bit later over your shoulder.

>From my standpoint, this should be just an XMPP (as in IM, not as in general message hub) client feature.  Clients should display self-destructing messages for a configurable by the sender amount of time, and send such messages with no-permanent-store hint (XEP-0334: Message Processing Hints) to prevent storing it on server and client archive.

This applies only to XMPP as IM, other use cases could be different.

On 06.11.2016 16:41, Stefan Hamacher wrote:
> Hello everybody,
>
> if I may make a suggestion: I agree with both positions on this:
>
> a) A message deletion/destruction feature requested on the senders side
> for the receiving side is not possible to implement reliably in an open
> protocol/environment where the receiving client just can ignore that
> request.
> Users can therefore be mislead and wonder why that feature does not work
> as expected.
>
> b) As being said a general demand still exists for such a feature. On
> the one hand we just have users who will compare XMPP programs with
> other solutions and will probably always keep asking for this. On the
> other hand there are certain environments where the users really have a
> use (and perhaps need) for such a feature, see Brian Cully's answer for
> example.
>
> So why not try to accommodate both realitys and define a feature which
> is called "Invalidation of Messages" or similar instead of "Destructible
> Messages". The goal of this feature should be to mark messages in a way,
> that the client somehow can mark the message as "not being relevant
> anymore" or something like that. So it could still be displayed but
> grayed out for example telling the receiver that the message can be ignored.
> Additionally there could then be added an attribute "deletionrequest"
> which can be set for clients which really want to have destructible
> messages like Signal does.
>
> This is of course not perfect either, because such a request can be
> ignored as well, but I think it would be a good compromise between the
> two extremes not defining such a feature at all (-> there will be
> unstandardized implementations) and defining it specificly as
> destructive messages feature (-> users are mislead). The term
> "invalidation" does not implicate that directly.
>
>
> Regards,
> Stefan Hamacher
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>



More information about the Standards mailing list