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

2016-10-18 Thread Chris Ballinger
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

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Kevin Smith
On 18 Oct 2016, at 10:31, Guus der Kinderen wrote: > On 18 October 2016 at 11:18, Kevin Smith wrote: >> >> On 18 Oct 2016, at 10:16, Guus der Kinderen >> wrote: >> > On 18 October 2016 at 11:12, Kevin Smith

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Guus der Kinderen
Not sure if I get what you're trying to say. I don't think that deletion should be an edit-to-empty, I think we're in agreement there. When defined in distinct XEPs, I think both XEPs would be (or should be) near copies of each-other, which would be needlessly complex. I propose to have one XEP,

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Kevin Smith
On 18 Oct 2016, at 10:16, Guus der Kinderen wrote: > On 18 October 2016 at 11:12, Kevin Smith wrote: >> On 18 Oct 2016, at 10:09, Guus der Kinderen >> wrote: >> > I don't have much of an argument other than the

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Guus der Kinderen
Why, when the use case, business rules and security considerations are pretty much the same (or perhaps: should be pretty much the same)? Wouldn't it be enough to perhaps have a distinct operation identifier in the same protocol? On 18 October 2016 at 11:12, Kevin Smith

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Kevin Smith
On 18 Oct 2016, at 10:09, Guus der Kinderen wrote: > I don't have much of an argument other than the obvious: both affect data > 'after-the-fact'. Concerns raised against one should likely also be tested > against the other - it's pretty much the same thing. As for

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Guus der Kinderen
I don't have much of an argument other than the obvious: both affect data 'after-the-fact'. Concerns raised against one should likely also be tested against the other - it's pretty much the same thing. As for the non-IM case: that could also apply to 'correction' of data, rather than only

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Dave Cridland
On 18 October 2016 at 09:55, Guus der Kinderen wrote: > Has the functional overlap with XEP-0308 "Last message correction" already > been discussed? What's the reason for creating a distinct XEP? Would it be > good to have the new XEP include 'correction', and replace

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Guus der Kinderen
Has the functional overlap with XEP-0308 "Last message correction" already been discussed? What's the reason for creating a distinct XEP? Would it be good to have the new XEP include 'correction', and replace 308? On 18 October 2016 at 10:44, Dave Cridland wrote: > On 17

Re: [Standards] Proposed XMPP Extension: Message Deletion

2016-10-18 Thread Dave Cridland
On 17 October 2016 at 20:45, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Deletion > > Abstract: This specification defines a method for indicating that a message > should be retracted. > > URL:

Re: [Standards] XEP-0050: Ad-Hoc Commands

2016-10-18 Thread jorge - w
I'm not really proposing altering the existing standard, because it works fine for several tasks. It seems it would be just a matter of scope. I know users writing commands looks weird, but we should consider that they will probably be using different clients at the same time and they would

Re: [Standards] XEP-0050: Ad-Hoc Commands

2016-10-18 Thread Dave Cridland
On 18 October 2016 at 08:11, jorge - w wrote: > I'm just trying to receive feeback from the community, since i have recently > joined it. > Sure - and it's appreciated. > In order to avoid client dependency, any programming should be done at > server side. I already know

Re: [Standards] XEP-0050: Ad-Hoc Commands

2016-10-18 Thread Dave Cridland
On 18 October 2016 at 07:54, jorge - w wrote: > My view is that XEP-0050 is fine as an admin tool, just like XEP-0133. > > But what is fine for admins is not always the same for regular users. That's > why i think there should be a different interface for regular users mostly

Re: [Standards] XEP-0050: Ad-Hoc Commands

2016-10-18 Thread jorge - w
I'm just trying to receive feeback from the community, since i have recently joined it. In order to avoid client dependency, any programming should be done at server side. I already know anything can be coded with no need for a standard, I'm just exposing an idea, not a personal need. El

Re: [Standards] XEP-0050: Ad-Hoc Commands

2016-10-18 Thread Kevin Smith
On 18 Oct 2016, at 07:54, jorge - w wrote: > My view is that XEP-0050 is fine as an admin tool, just like XEP-0133. > > But what is fine for admins is not always the same for regular users. That's > why i think there should be a different interface for regular users mostly

Re: [Standards] XEP-0050: Ad-Hoc Commands

2016-10-18 Thread jorge - w
My view is that XEP-0050 is fine as an admin tool, just like XEP-0133. But what is fine for admins is not always the same for regular users. That's why i think there should be a different interface for regular users mostly aimed to external applications. Users might prefer :app_short_name to