Re: [Standards] Deprecating Privacy Lists (again)

2017-03-23 Thread Philipp Hörist
btw the Gajim default blocking option should work in 0.16.7 perfectly together with blocking command, just for info. On Topic i think nobody uses Privacy Lists .. like with different lists and setting active this and that and creating cool special rules. At least not in Gajim. Its also very

Re: [Standards] Deprecating Privacy Lists (again)

2017-03-23 Thread Sam Whited
On Thu, Mar 23, 2017 at 8:09 AM, Dave Cridland wrote: > I'm in favour of deprecation (but not elimination). I forgot there was a difference, but I used the word I meant purely by accident. To make sure it's absolutely clear: I am advocating that we move XEP-0016 to the

Re: [Standards] Deprecating Privacy Lists (again)

2017-03-23 Thread Ruslan N. Marchenko
On 23.03.2017 14:18, Dave Cridland wrote: On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote: On 22.03.2017 20:37, Sam Whited wrote: On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger wrote: One nice feature we also don't have with blocking command is

[Standards] UPDATED: XEP-0390 (Entity Capabilities 2.0)

2017-03-23 Thread XMPP Extensions Editor
Version 0.0.1 of XEP-0390 (Entity Capabilities 2.0) has been released. Abstract: This document overhauls the XMPP protocol extension Entity Capabilities (XEP-0115). It defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities.

Re: [Standards] Deprecating Privacy Lists (again)

2017-03-23 Thread Travis Burtrum
Hi all, On 03/22/2017 04:08 PM, Ruslan N. Marchenko wrote: > List allows you creating overriding allow entry which will unblock > single person while keeping the group blocked (order matters). So does keeping the UI option to block a whole group, and then just using the blocking command to

Re: [Standards] Join and Create

2017-03-23 Thread Georg Lukas
* Florian Schmaus [2017-03-23 14:25]: > It is the same feature request for PubSub/PEP. For example when using > OMEMO you always want to subscribe-and-maybe-create the devicelist node. I can see how an UPSERT operation is useful on a resource that is exclusively owned by you,

Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
On 23.03.2017 14:25, Florian Schmaus wrote: > It is the same feature request for PubSub/PEP. For example when using > OMEMO you always want to subscribe-and-maybe-create the devicelist node. > Some goes for the XEP-0080 geoloc node. It would be nice if PubSub would > provide that as primitive.

Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
On 23.03.2017 11:05, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 10:11]: >> That does work if the name of the channel can be random (nameless). But >> I believe that there will be use cases where the name of the channel >> needs to be fixed. > > Yes, there are use cases

Re: [Standards] Deprecating Privacy Lists (again)

2017-03-23 Thread Dave Cridland
On 22 March 2017 at 20:08, Ruslan N. Marchenko wrote: > > On 22.03.2017 20:37, Sam Whited wrote: >> >> On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger >> wrote: >>> >>> One nice feature we also don't have with blocking command is blocking a >>> while group.

Re: [Standards] Deprecating Privacy Lists (again)

2017-03-23 Thread Dave Cridland
On 22 March 2017 at 19:08, Sam Whited wrote: > I'd love your thoughts before I bring this before the council for a vote. I'm in favour of deprecation (but not elimination). * Privacy lists are mammothly complicated, and therefore error-prone. * While it's possible to

Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

2017-03-23 Thread Jonas Wielicki
On Mittwoch, 22. März 2017 18:48:06 CET edhe...@movim.eu wrote: > * var='Participation Addition by Invitation from Participant' > > * I think that it would be better to set this field var to > 'participation_addition_by_invitation_from_participant' and use the > label tag for all the

Re: [Standards] Join and Create

2017-03-23 Thread Georg Lukas
* Florian Schmaus [2017-03-23 10:11]: > That does work if the name of the channel can be random (nameless). But > I believe that there will be use cases where the name of the channel > needs to be fixed. Yes, there are use cases where a fixed channel name is needed. But do you

Re: [Standards] Join and Create

2017-03-23 Thread Dave Cridland
On 23 March 2017 at 08:38, Georg Lukas wrote: > * Florian Schmaus [2017-03-23 08:22]: >> Consider an chess-game service build on top of MIX. Tim and Tom want to >> play a game and agree on the "TimAndTomsGame" as name. Now both clients >> want to

Re: [Standards] Join and Create

2017-03-23 Thread Georg Lukas
* Florian Schmaus [2017-03-23 08:22]: > Consider an chess-game service build on top of MIX. Tim and Tom want to > play a game and agree on the "TimAndTomsGame" as name. Now both clients > want to join-and-maybe-create the TimAndTomsGame MIX channel. I think this is exactly

Re: [Standards] Join and Create

2017-03-23 Thread Steve Kille
Flo, I'm not convinced by this example. MIX is primarily oriented for end users, not as a building block like PubSub. I don't see this example as a target application and the issue seems quite pathological to me Steve > > Couldn't this be a create followed by a join? > > If the channel

Re: [Standards] Join and Create

2017-03-23 Thread Florian Schmaus
On 23.03.2017 04:14, Daurnimator wrote: > On 23 March 2017 at 01:40, Florian Schmaus wrote: >> On 22.03.2017 12:53, Steve Kille wrote: >>> I think that keeping Create and Join separate is the right thing. >> >> They can and should be separate, but I think there needs to be a

Re: [Standards] Join and Create

2017-03-23 Thread Steve Kille
> -Original Message- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of > Daurnimator > Sent: 23 March 2017 03:15 > To: XMPP Standards > Subject: Re: [Standards] Join and Create > > On 23 March 2017 at 01:40, Florian Schmaus wrote: > > On 22.03.2017