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: [email protected] > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
