Re: [Standards] Proposed XMPP Extension: Spoiler messages

The element can be used to display human readable text via the `hint` attribute, so it should be noted that multiple elements could be present with different `xml:lang` values. It might be worth making the hint text the character data of the element instead of an attribute. /Lance

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

Quoting Dave Cridland : That's not the case in an open ecosystem - someone's client could just ignore the request, and might even have a setting to do so. It is very probable that many clients will offer this setting, so users will be rapidly aware of it - and that their

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

On Tue, Nov 1, 2016 at 1:43 PM, Chris Ballinger wrote: > I think people are overthinking this and expecting this proposal to be a > completely secure 100% guaranteed way to enforce message deletion on a > client you don't control. I think the real problem is that *users*

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

On 1 November 2016 at 18:13, Chris Ballinger wrote: > People already have a casual understanding that you can't completely enforce > message deletion. Actually, I'm really not sure that's as true as you assert. People currently think that it requires an assertive effort on

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

You're not promising anything, it's just a hint that the other side should automatically delete a message. If anything, it's most useful that it auto-deletes it from your own device from the perspective of physical security. You can phrase it as "Request automatic deletion" to make it more clear

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

> On 1 Nov 2016, at 17:43, forenjunkie wrote: > > But it doesnt work with a decentral, open source kind of system. > > a feature like that depends on the other side deleting the message. > > you are lying to your users the minute you offer this feature in your client >

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

But it doesnt work with a decentral, open source kind of system. a feature like that depends on the other side deleting the message. you are lying to your users the minute you offer this feature in your client and not show a disclaimer. you promise the message will self destruct, but you can

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

Regardless of whether or not "we" think it's a good idea, users are starting to demand the feature, especially because it's now present in almost every mainstream messaging app. At some point we will probably implement it because it's a relatively simple feature with a lot of demand. When that

Re: [Standards] XEP-0225: Component Connections (deferred status)

On 1 November 2016 at 14:23, jorge - w wrote: > If I understood it right XEP-0225 is meant to upgrade XEP-0114. Are there > technical issues still to be solved, so status is deferred? > It turns out that it doesn't solve any technical issues not currently addressed by '114,

Re: [Standards] LAST CALL: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)

On Tue, Nov 1, 2016 at 8:02 AM, Florian Schmaus wrote: > That is what I'm thinking too. The question is: Shall we assume that > every entity which announces support for hash algorithm X, also supports > HMAC based on X? If yes, then we could simply add a element to > XEP-0300

[Standards] XEP-0225: Component Connections (deferred status)

If I understood it right XEP-0225 is meant to upgrade XEP-0114. Are there technical issues still to be solved, so status is deferred? My opinion is that external component development should be facilitated as much as possible in order to promote its expansion. Currently it seems not easy to

Re: [Standards] LAST CALL: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)

On 01.11.2016 12:50, Tobias Markmann wrote: > Sounds sensible, do you have a XEP using these HMACs in mind or is it > just for the future. ISR [1] currently uses initator-hmac but I could imagine that we possible will see more usage of HMACs in XEPs in the future. > Probably makes

Re: [Standards] LAST CALL: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)

On Tue, Nov 1, 2016 at 12:43 PM, Florian Schmaus wrote: > One remark: Would it be sensible to do the same for HMACs? Specifying a > common element, like > > … > > and possible even announce support for HMAC-using-$algo (not sure about > that). > > And, if so, shall this be put

Re: [Standards] LAST CALL: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)

On 29.10.2016 23:37, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0300 (Use > of Cryptographic Hash Functions in XMPP). > > Abstract: This document provides recommendations for the use of cryptographic > hash functions in XMPP protocol

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

On Wed, 19 Oct 2016, 19:40 Kim Alvefur, wrote: > > The question becomes why should we standardize something that only works > in a closed system? The reason to standardize is, as with open systems, so that multiple servers and clients can provide the same feature.

Re: [Standards] LAST CALL: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)

On 30 October 2016 at 08:37, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0300 (Use > of Cryptographic Hash Functions in XMPP). > > Abstract: This document provides recommendations for the use of cryptographic > hash