Re: [Standards] Deprecating Privacy Lists (again)

[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 inefficient, i always have to copy whole lists around because
it supports no real edits of lists, like adding single items and removing
them. We always have to send the whole List.

Active Lists not just layering over the default lists is also something i
would have expected.

It feels like too much stuff is packed into one XEP.
For example i find it very good that Invisibility Command will be a own XEP.

if i want to go invisible now, i have to add a rule to a list, then send my
whole list to the server, or copy the whole list and set another one
active. This gets more ugly the more your blocking list grows.

So we have Invisibility in a own easy to implement XEP.
We have Blocking Command.

And if in the future there is one or two use cases that we really want to
cover regarding blocking, we can just add it to Blocking Command and we
will still be miles away from a Privacy Lists complexity.


regards
Philipp

2017-03-23 20:14 GMT+01:00 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 blocking a
> while group.
>

 Ah yes! I knew there was something else that I was forgetting to
 address from last time.

 I also think this is not a good thing; it is an abuse of roster
 groups, and leads to an inconsistent experience across clients. It
 also makes the UX incredibly frustrating. For example:

 I block a group "work", but then I decide I want to talk to one of my
 coworkers so I go to their chat, but it says they're blocked. I hit
 unblock: what happens?

>>>
>>> It's probably UX problem but not list per se.
>>>
>> If a protocol explicitly creates UX problems, it's a protocol problem.
>>
>> List allows you creating overriding allow entry which will unblock single
>>> person while keeping the group blocked (order matters).
>>>
>> There's no way for one client to inform another that this is not a
>> general standalone rule, but an explicit exception to a previous rule,
>>
> But there is, active list. Active list is local to client, default to
> user. Active cannot be intermixed with default, so if one client wants an
> exception - it may (just a quick guess) copy a list and set it active.
> There're plenty of configurations client could apply. Although of course
> different implementations will probably treat lists differently. But if
> client allows raw list editing - user always has an option to apply
> whatever configuration he wants. Gajim is a good example of that - blocking
> option + raw editor.
>
> however. There's no way to say that this exception is a temporary
>> case, rather than the norm. There's no way to indicate that this is
>> actually a general rule because this particular co-worker is also an
>> XSF member, and people in both groups are always unblocked.
>>
>> I would much rather have clients using a simple interface that covers
>> the 90%, than not using a complicated one which fails to cover more
>> than 95%.
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating Privacy Lists (again)

[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 "Deprecated" stage described here: [1]. *NOT* to
obsolete.

—Sam

[1]: https://xmpp.org/extensions/xep-0001.html#states-Deprecated
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating Privacy Lists (again)

[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 blocking a
while group.


Ah yes! I knew there was something else that I was forgetting to
address from last time.

I also think this is not a good thing; it is an abuse of roster
groups, and leads to an inconsistent experience across clients. It
also makes the UX incredibly frustrating. For example:

I block a group "work", but then I decide I want to talk to one of my
coworkers so I go to their chat, but it says they're blocked. I hit
unblock: what happens?


It's probably UX problem but not list per se.

If a protocol explicitly creates UX problems, it's a protocol problem.


List allows you creating overriding allow entry which will unblock single
person while keeping the group blocked (order matters).

There's no way for one client to inform another that this is not a
general standalone rule, but an explicit exception to a previous rule,
But there is, active list. Active list is local to client, default to 
user. Active cannot be intermixed with default, so if one client wants 
an exception - it may (just a quick guess) copy a list and set it active.
There're plenty of configurations client could apply. Although of course 
different implementations will probably treat lists differently. But if 
client allows raw list editing - user always has an option to apply 
whatever configuration he wants. Gajim is a good example of that - 
blocking option + raw editor.



however. There's no way to say that this exception is a temporary
case, rather than the norm. There's no way to indicate that this is
actually a general rule because this particular co-worker is also an
XSF member, and people in both groups are always unblocked.

I would much rather have clients using a simple interface that covers
the 90%, than not using a complicated one which fails to cover more
than 95%.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[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. In 
order to minimize network impact, the transport mechanism is standard XMPP 
presence broadcast (thus forestalling the need for polling related to service 
discovery data), the capabilities information can be cached either within a 
session or across sessions, and the format has been kept as small as possible.

Changelog: First draft. (jwi)

Diff: N/A

URL: https://xmpp.org/extensions/xep-0390.html

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating Privacy Lists (again)

[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 individually block them all.  Then Sam's
hairy situation of wanting to talk to a single user becomes easy, you
just unblock that user.  Also this *just works* across all clients.

I've yet to see an upside of privacy lists.

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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, but not on a "public asset" shared with other
users.

> > - Named public long-lived MIXes: you want to either be the owner of it
> >   or have the creation fail.
> You do sometimes have exclusive races against other resources of your JID.

Like... when you attempt to create the same channel on two different
devices, at the same time?

Seriously, there is no such problem with MIX, because the first client
creating the MIX will get it pushed into the roster and all the others
will be auto-subscribed, or something along these lines.

The race condition I see as problematic is different users trying to
create the same MIX.


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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.

Sorry, not subscribe-and-maybe-create, but retrieve-and-maybe-create.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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 where a fixed channel name is needed. But do
> you really want to end up in a situation where a race condition decides
> on who will become the owner of that channel, and where you'll
> accidentally expose your full JID to a third party by join-or-creating
> some milliseconds too late?

See comment below.

>> For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the
>> situation here is not so bad, because the nodes don't get deleted usually).
> 
> Sorry, I can't follow you. What's the relevance of the current
> discussion to OMEMO etc?

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.

>> But yeah, § 6.5.3 could be sufficient in most cases. However, I still
>> feel like having an optional atomic join-or-maybe-create operation would
>> be nice to have.
> 
> I have a contrary opinion. Join-or-maybe-create is the wrong solution
> for the two MIX use cases I see, and it would make implementors take
> nasty shortcuts.
> 
> - Named public long-lived MIXes: you want to either be the owner of it
>   or have the creation fail.

You do sometimes have exclusive races against other resources of your JID.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating Privacy Lists (again)

[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.
>>
>>
>> Ah yes! I knew there was something else that I was forgetting to
>> address from last time.
>>
>> I also think this is not a good thing; it is an abuse of roster
>> groups, and leads to an inconsistent experience across clients. It
>> also makes the UX incredibly frustrating. For example:
>>
>> I block a group "work", but then I decide I want to talk to one of my
>> coworkers so I go to their chat, but it says they're blocked. I hit
>> unblock: what happens?
>
>
> It's probably UX problem but not list per se.

If a protocol explicitly creates UX problems, it's a protocol problem.

>
> List allows you creating overriding allow entry which will unblock single
> person while keeping the group blocked (order matters).

There's no way for one client to inform another that this is not a
general standalone rule, but an explicit exception to a previous rule,
however. There's no way to say that this exception is a temporary
case, rather than the norm. There's no way to indicate that this is
actually a general rule because this particular co-worker is also an
XSF member, and people in both groups are always unblocked.

I would much rather have clients using a simple interface that covers
the 90%, than not using a complicated one which fails to cover more
than 95%.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating Privacy Lists (again)

[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 implement many complex user desires into a
privacy list, it is not possible to do so such that another client
will understand the desires.

More comments against individual responses...

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[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 jabber:x:data fields for a proper labeling system.
> 
>   * This will simplify the mapping of the fields and prevent
> uppercase/lowercase/spaces issues in the servers and clients
> implementations

The use of entirely human-readable variable names in the configuration node 
slipped my first reading.

To double check I’ve skimmed XEP-0004 and XEP-0068 and names with spaces are 
not in violation with any of those. Nevertheless, I personally don’t like 
that, but that’s just like, my opinion, man.

regards,
jwi

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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 really want to end up in a situation where a race condition decides
on who will become the owner of that channel, and where you'll
accidentally expose your full JID to a third party by join-or-creating
some milliseconds too late?

> For PubSub/PEP this would be OMEMO, GeoLoc, etc., (although the
> situation here is not so bad, because the nodes don't get deleted usually).

Sorry, I can't follow you. What's the relevance of the current
discussion to OMEMO etc?

> But yeah, § 6.5.3 could be sufficient in most cases. However, I still
> feel like having an optional atomic join-or-maybe-create operation would
> be nice to have.

I have a contrary opinion. Join-or-maybe-create is the wrong solution
for the two MIX use cases I see, and it would make implementors take
nasty shortcuts.

- Named public long-lived MIXes: you want to either be the owner of it
  or have the creation fail.

- Anon/private MIXes: just use §6.5.3


Georg



signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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 join-and-maybe-create the TimAndTomsGame MIX channel.
>
> I think this is exactly what §6.5.3 "Creating a Channel for Ad Hoc Use"
> is meant for. One of the two creates such a "nameless" channel and sends
> an invitation, there is really no need to have both parties trying to
> create it, or any kind of out-of-band name arbitration.
>
> Just because in MUC there was no explicit way to create such a private
> channel, we don't need to mimic the old behavior in MIX.
>
> I'm not convinced by this example, and I think there is no other
> compelling use case for that functionality.

+1.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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 what §6.5.3 "Creating a Channel for Ad Hoc Use"
is meant for. One of the two creates such a "nameless" channel and sends
an invitation, there is really no need to have both parties trying to
create it, or any kind of out-of-band name arbitration.

Just because in MUC there was no explicit way to create such a private
channel, we don't need to mimic the old behavior in MIX.

I'm not convinced by this example, and I think there is no other
compelling use case for that functionality.


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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 already exists, then the create would return an error
> > (which you can ignore).
> 
> That is basically what Smack does [1], as I've written in [2], but is not
> sufficient.
> 
> A simple example:
> 
> 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.
> 
> Currently a client implementation will look something like this (note that
it
> does matter if you try to create first and then join, or the other way
around):
> 
> result = join(TimAndTomsGame)
> if (result == channel-does-not-exist) {
>// A
>result = create(TimAndTomsGame)
>if (result = channel-does-exist) {
>   // B
>   result = join(TimAndTomsGame)
>}
> }
> 
> This tries to fix all the races, but fails. A is what you mentioned. But
if Tom
> decides that he has waited long enough while Tim is at B, and leaves the
> channel, upon which the channel will get auto-destroyed, then Tim will get
a
> channel-does-not-exist result using this logic.
> 
> The only way to solve this is to make this an atomic operation at protocol
> level. Which is trivial to add, simply define an IQ which has "two" child
> elements,  and , and easy to implement server side (and,
of
> course, client side).
> 
> - Florian
> 


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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 third
>> operation "join-and-maybe-create". Otherwise the protocol is incomplete
>> and broken.
>>
>>> I feel that we have enough complexity with the modular operations, without
>>> creating compound operations that will have whole new classes of error to
>>> consider
>>
>> How about making this an optional feature in an add-on XEP?
> 
> Couldn't this be a create followed by a join?
> If the channel already exists, then the create would return an error
> (which you can ignore).

That is basically what Smack does [1], as I've written in [2], but is
not sufficient.

A simple example:

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.

Currently a client implementation will look something like this (note
that it does matter if you try to create first and then join, or the
other way around):

result = join(TimAndTomsGame)
if (result == channel-does-not-exist) {
   // A
   result = create(TimAndTomsGame)
   if (result = channel-does-exist) {
  // B
  result = join(TimAndTomsGame)
   }
}

This tries to fix all the races, but fails. A is what you mentioned. But
if Tom decides that he has waited long enough while Tim is at B, and
leaves the channel, upon which the channel will get auto-destroyed, then
Tim will get a channel-does-not-exist result using this logic.

The only way to solve this is to make this an atomic operation at
protocol level. Which is trivial to add, simply define an IQ which has
"two" child elements,  and , and easy to implement
server side (and, of course, client side).

- Florian

1:
https://github.com/igniterealtime/Smack/blob/08c228ef99b59c7c16b44941875e1ea640db3b62/smack-extensions/src/main/java/org/jivesoftware/smackx/pubsub/PubSubManager.java#L272
1: https://mail.jabber.org/pipermail/standards/2017-March/032419.html




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Join and Create

[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 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 third
> > operation "join-and-maybe-create". Otherwise the protocol is
> > incomplete and broken.
> >
> >> I feel that we have enough complexity with the modular operations,
> >> without creating compound operations that will have whole new classes
> >> of error to consider
> >
> > How about making this an optional feature in an add-on XEP?
> 
> Couldn't this be a create followed by a join?
> If the channel already exists, then the create would return an error
(which
> you can ignore).
[Steve Kille] 

That feels sensible to me.

I am not really seeing the benefit of adding a new operation


Steve




___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___