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
___

Re: [Standards] Deprecating Privacy Lists (again)

[Ruslan N. Marchenko]

On 23.03.2017 14:41, Travis Burtrum wrote:

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

Uhm? Group? With XEP-0191? Oh, yes, roster abuse.
So UI option to block the group would iterate through all members of the 
group and put a callback to when the group is updated (roster push), right?

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] 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] 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] Deprecating Privacy Lists (again)

[Ruslan N. Marchenko]

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.

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


So - I'm against that. Priv.Lists is a very flexible and precise tool.


Does it unblock the entire group (oops,
everyone knows I'm online now and can start asking me work related
questions after hours), does it unblock just them? If it unblocks just
them, how does that work? Do I have to maintain a white list of "the
entire group is blocked, but this person is specifically unblocked"?

This becomes very complex very quickly, and is one of the reasons that
privacy lists are too complex; I also suspect it's very niche. This is
not a use case I think we should support.

—Sam
___
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)

[Jonas Wielicki]

On Mittwoch, 22. März 2017 14:37:07 CET 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? Does it unblock the entire group (oops,
> everyone knows I'm online now and can start asking me work related
> questions after hours), does it unblock just them? If it unblocks just
> them, how does that work? Do I have to maintain a white list of "the
> entire group is blocked, but this person is specifically unblocked"?

That sounds like a use-case for the Invisibility Command. Or simply separate 
JIDs, really.

best regards,
Jonas

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] Deprecating Privacy Lists (again)

[Sam Whited]

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? Does it unblock the entire group (oops,
everyone knows I'm online now and can start asking me work related
questions after hours), does it unblock just them? If it unblocks just
them, how does that work? Do I have to maintain a white list of "the
entire group is blocked, but this person is specifically unblocked"?

This becomes very complex very quickly, and is one of the reasons that
privacy lists are too complex; I also suspect it's very niche. This is
not a use case I think we should support.

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

Re: [Standards] Deprecating Privacy Lists (again)

[Yann Leboulanger]

One nice feature we also don't have with blocking command is blocking a
while group.

-- 

Yann


Le 22/03/2017 à 20:08, Sam Whited a écrit :
> TL;DR — Privacy lists don't give us anything that we actually want to
> have that the blocking command doesn't give us already, and they're
> too complicated.
>
>
> Hi all,
>
> I would like to restart the discussion on deprecating XEP-0016:
> Privacy Lists [1] in favor of XEP-0191: Blocking Command [2].
> Currently, we list both XEPs on the website with shiny green "this is
> recommended" text (privacy lists are final, blocking command is draft)
> which is confusing. I would like to see us make a single concrete
> recommendation in the future, and I think that the blocking command is
> a better candidate to be that XEP.
>
> The last time I brought this up, the main argument against was that
> the blocking command didn't address all of the cases that privacy
> lists does. This is true, and I see it as a feature. Specifically, the
> following points were raised:
>
> 1. The blocking command does not allow blocking of anyone that you
> don't have a subscription too
>
> This is not true, however, the language was unclear. Since then this
> has been clarified. It was also mentioned that domains couldn't be
> blocked, but this was also untrue and works fine.
>
> 2. The blocking command does not allow blocking traffic from strangers
> except for presence subscription requests.
>
> This is mostly brought up in terms of spam prevention, however, it
> does not do a good job at preventing spam (presence subscription spam
> is also a thing). In general, I think this is generally something
> that's appropriate to very specific use cases, but is not something we
> (the XSF) should encourage in general: it damages the network, and
> makes XMPP less useable and more confusing for everyone. People that
> have this option turned on in a client won't understand why their
> friends can't contact them and they can't contact their friends after
> one of them sends a presence request (but a bidirectional relationship
> hasn't been established), also if you don't want to expose that this
> setting is on and your friend is trying to contact you, they won't
> have any indication that their messages are being dropped.
>
> Furthermore, although in theory the blocking command and privacy lists
> can use the same backend store, it is not entirely clear how this
> would work in a general way. Until recently if you blocked a
> conversation in Gajim (which uses privacy lists), it would not show up
> as blocked in Conversations (using the blocking command). This was
> fixed by tweaking Gajim's privacy list to use the format the server
> expected for a shared list, but the flexibility of privacy lists just
> means it would happen again in a different way on another server or
> with different clients. There is no general solution.
>
> Finally, Prosody 0.10 has removed their privacy lists implementation
> in favor of the blocking command already because the privacy lists
> protocol was too complicated and lead to buggy code, which indicates
> to me that this isn't a protocol we should recommend.
>
> I'd love your thoughts before I bring this before the council for a vote.
>
> Best,
> sam
>
>
>
> [1]: https://xmpp.org/extensions/xep-0016.html
> [2]: https://xmpp.org/extensions/xep-0191.html
> ___
> 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

[Genghis Khan]

> Sent: Friday, October 23, 2015 at 10:05 PM
> From: Goffi 
> To: "XMPP Standards" 
> Subject: Re: [Standards] Deprecating Privacy Lists
>
> Le vendredi 23 octobre 2015, 13:08:54 Sam Whited a écrit :
> > In that case it sounds like this is a great opportunity for them to
> > create standards that actually meet the needs of the social-networking
> > crowd instead of relying on a single monolithic one-size-fits-all
> > standard.
> > 
> > —Sam
> 
> Hi,
> 
> I'm working on “Salut à Toi”, one of the two you are talking about.
> About privacy list we are not using it yet, but we would need it to be 
> (in)visible only to a group, as I said in previous message. I woud be happy 
> with a new XEP if it allows to do that. But I think this thread is long 
> enough 
> to not launch again the subject, I have already expressed my opinion. If 
> privacy list are deprecated and if we need the missing feature, I can write 
> the XEP myself (if nobody do it before).
> 
> Cheers
> Goffi
> 

Please do so.  If you would need any feedback, please feel free to bother me.

Jaussoin Timothée, please read this thread, if you have not already; I think
this issue should concern you.

Re: [Standards] Deprecating Privacy Lists

[Goffi]

Le vendredi 23 octobre 2015, 13:08:54 Sam Whited a écrit :
> In that case it sounds like this is a great opportunity for them to
> create standards that actually meet the needs of the social-networking
> crowd instead of relying on a single monolithic one-size-fits-all
> standard.
> 
> —Sam

Hi,

I'm working on “Salut à Toi”, one of the two you are talking about.
About privacy list we are not using it yet, but we would need it to be 
(in)visible only to a group, as I said in previous message. I woud be happy 
with a new XEP if it allows to do that. But I think this thread is long enough 
to not launch again the subject, I have already expressed my opinion. If 
privacy list are deprecated and if we need the missing feature, I can write 
the XEP myself (if nobody do it before).

Cheers
Goffi

Re: [Standards] Deprecating Privacy Lists

[Genghis Khan]

> Sent: Friday, October 23, 2015 at 7:09 PM
> From: "Sam Whited" 
> To: "XMPP Standards" 
> Subject: Re: [Standards] Deprecating Privacy Lists
>
> On Fri, Oct 23, 2015 at 10:38 AM, Genghis Khan  wrote:
> > My fear is that at some point in time, we might lose some features.
> 
> I don't see this as a problem. Fewer features (assuming these aren't
> popular features that lots of people use, which I don't think they
> are) just means that things will be simpler to implement and less
> confusing to use.
> 

I think you are correct; I, too, assume that not many use this feature.
If XMPP was used by hundred of millions, I believe that server
administrators would have demanded from XMPP client developers to provide
some sort of automation of presence-control (not presence-management) by
utilizing XEP-0016, be it automatically by client or by client or server
prompting users to make some order in their rosters with privacy list
sets of rules.

Maybe, if our assumption is correct, XEP-0016 is not used by end-users
(end-users are any user but a company employee) because it is not yet
needed, yet it is still relevant and need not yet to be deprecated.

I will also add this, Psi seems to handle privacy lists elegantly per
end-user, but Gajim has an extremely ugly way, per end-user, to manage
privacy lists.  I know there are more XMPP clients than these two, but
perhaps it is the UI design that deters end-users to enjoy this feature.

P.S. I have read this thread twice, I understand that it is not only the
 UI to blame.  Maybe if more users would have used it, we would have
 updated XEP-0016 to something more sensible, by now.

I do not know.  When I do not know, I prefer not to take risks.

Re: [Standards] Deprecating Privacy Lists

[Sam Whited]

In that case it sounds like this is a great opportunity for them to
create standards that actually meet the needs of the social-networking
crowd instead of relying on a single monolithic one-size-fits-all
standard.

—Sam

On Fri, Oct 23, 2015 at 11:14 AM, Genghis Khan  wrote:
> I do not know how many of you heard of social networking platforms that
> are based on XMPP, such as Movim and Salut à Toi
>
> By deprecating XEP-0016, even if it does not mean nullification, we
> might harm progress of XMPP based social networks.  Not only that the
> centralized social networks deprecate and even actively destroy user
> privacy, they do not seem to allow powerful privacy feature such as
> XEP-0016.
>
> Another reason to keep XEP-0016 until further corresponding
> advancements be made is to protect this almost exclusive potential that
> is now reserved to social networking platforms based on XMPP.
>
> Also, if you think that XEP-0016, due to its complicity or flexibility
> rate, is resulting in bad code or implementation, please update XEP-0016
> with a new section that would provide a proper UI guidelines to handle it;
> UI may be a filter dialog such of Email clients (e.g. Claws Mail and
> Sylpheed).
>
> Posts I legitimize or agree with:
> http://mail.jabber.org/pipermail/standards/2015-September/030396.html Florian 
> Schmaus
> http://mail.jabber.org/pipermail/standards/2015-September/030397.html Goffi
> http://mail.jabber.org/pipermail/standards/2015-September/030398.html 
> Christian Schudt
> http://mail.jabber.org/pipermail/standards/2015-September/030400.html Goffi
> http://mail.jabber.org/pipermail/standards/2015-October/030429.html Evgeny 
> Khramtsov
> http://mail.jabber.org/pipermail/standards/2015-October/030434.html Evgeny 
> Khramtsov
> http://mail.jabber.org/pipermail/standards/2015-October/030438.html Evgeny 
> Khramtsov
> http://mail.jabber.org/pipermail/standards/2015-October/030460.html Christian 
> Schudt
> http://mail.jabber.org/pipermail/standards/2015-October/030466.html Evgeny 
> Khramtsov
> http://mail.jabber.org/pipermail/standards/2015-October/030481.html Evgeny 
> Khramtsov
> http://mail.jabber.org/pipermail/standards/2015-October/030484.html Evgeny 
> Khramtsov
>
> I strongly suggest not to deprecate XEP-0016 yet.
>
>> Sent: Tuesday, September 29, 2015 at 11:02 PM
>> From: "Sam Whited" 
>> To: "XMPP Standards" 
>> Subject: [Standards] Deprecating Privacy Lists
>>
>> I've brought up reconciling privacy lists and the blocking command in
>> the past [1], but the discussion faltered and it never went before the
>> council. It was brought up as part of a recent discussion again [2],
>> and I'd like to formally propose that it be deprecated.
>>
>> I have made a pull request here: https://github.com/xsf/xeps/pull/104
>>
>> As I see it, privacy lists are complicated and don't work well with
>> the blocking command in practice. As an example, if I block a user (on
>> an ejabberd server) in Gajim (which uses privacy lists), and then view
>> the same user in Conversations (which suports the blocking command),
>> that user does not appear blocked because Gajim's privacy list is
>> slightly different from what the server considers "blocked" so it's
>> never mapped to the privacy lists.
>>
>> The majority of the functionality of privacy lists is covered by
>>
>> - XEP-0191: Blocking command
>> - XEP-0186: Invisibility
>>
>> While privacy lists do have other functionality, it is rarely used.
>>
>> Deprecating privacy lists will simplify the XMPP stack and remove one
>> more interop issue between clients which implement different
>> protocols, and I'd like to request that it be taken up and discussed
>> by the council.
>>
>> Best,
>> Sam
>>
>>
>>
>> [1]: http://mail.jabber.org/pipermail/standards/2014-December/029402.html
>> [2]: http://mail.jabber.org/pipermail/standards/2015-September/030358.html
>>
>> --
>> Sam Whited
>> pub 4096R/54083AE104EA7AD3
>> https://blog.samwhited.com
>>



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

Re: [Standards] Deprecating Privacy Lists

[Genghis Khan]

I do not know how many of you heard of social networking platforms that
are based on XMPP, such as Movim and Salut à Toi

By deprecating XEP-0016, even if it does not mean nullification, we
might harm progress of XMPP based social networks.  Not only that the
centralized social networks deprecate and even actively destroy user
privacy, they do not seem to allow powerful privacy feature such as
XEP-0016.

Another reason to keep XEP-0016 until further corresponding
advancements be made is to protect this almost exclusive potential that
is now reserved to social networking platforms based on XMPP.

Also, if you think that XEP-0016, due to its complicity or flexibility
rate, is resulting in bad code or implementation, please update XEP-0016
with a new section that would provide a proper UI guidelines to handle it;
UI may be a filter dialog such of Email clients (e.g. Claws Mail and
Sylpheed).

Posts I legitimize or agree with:
http://mail.jabber.org/pipermail/standards/2015-September/030396.html Florian 
Schmaus
http://mail.jabber.org/pipermail/standards/2015-September/030397.html Goffi
http://mail.jabber.org/pipermail/standards/2015-September/030398.html Christian 
Schudt
http://mail.jabber.org/pipermail/standards/2015-September/030400.html Goffi
http://mail.jabber.org/pipermail/standards/2015-October/030429.html Evgeny 
Khramtsov
http://mail.jabber.org/pipermail/standards/2015-October/030434.html Evgeny 
Khramtsov
http://mail.jabber.org/pipermail/standards/2015-October/030438.html Evgeny 
Khramtsov
http://mail.jabber.org/pipermail/standards/2015-October/030460.html Christian 
Schudt
http://mail.jabber.org/pipermail/standards/2015-October/030466.html Evgeny 
Khramtsov
http://mail.jabber.org/pipermail/standards/2015-October/030481.html Evgeny 
Khramtsov
http://mail.jabber.org/pipermail/standards/2015-October/030484.html Evgeny 
Khramtsov

I strongly suggest not to deprecate XEP-0016 yet.

> Sent: Tuesday, September 29, 2015 at 11:02 PM
> From: "Sam Whited" 
> To: "XMPP Standards" 
> Subject: [Standards] Deprecating Privacy Lists
>
> I've brought up reconciling privacy lists and the blocking command in
> the past [1], but the discussion faltered and it never went before the
> council. It was brought up as part of a recent discussion again [2],
> and I'd like to formally propose that it be deprecated.
> 
> I have made a pull request here: https://github.com/xsf/xeps/pull/104
> 
> As I see it, privacy lists are complicated and don't work well with
> the blocking command in practice. As an example, if I block a user (on
> an ejabberd server) in Gajim (which uses privacy lists), and then view
> the same user in Conversations (which suports the blocking command),
> that user does not appear blocked because Gajim's privacy list is
> slightly different from what the server considers "blocked" so it's
> never mapped to the privacy lists.
> 
> The majority of the functionality of privacy lists is covered by
> 
> - XEP-0191: Blocking command
> - XEP-0186: Invisibility
> 
> While privacy lists do have other functionality, it is rarely used.
> 
> Deprecating privacy lists will simplify the XMPP stack and remove one
> more interop issue between clients which implement different
> protocols, and I'd like to request that it be taken up and discussed
> by the council.
> 
> Best,
> Sam
> 
> 
> 
> [1]: http://mail.jabber.org/pipermail/standards/2014-December/029402.html
> [2]: http://mail.jabber.org/pipermail/standards/2015-September/030358.html
> 
> -- 
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
>

Re: [Standards] Deprecating Privacy Lists

[Sam Whited]

On Fri, Oct 23, 2015 at 10:38 AM, Genghis Khan  wrote:
> My fear is that at some point in time, we might lose some features.

I don't see this as a problem. Fewer features (assuming these aren't
popular features that lots of people use, which I don't think they
are) just means that things will be simpler to implement and less
confusing to use.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

Re: [Standards] Deprecating Privacy Lists

[Genghis Khan]

> Sent: Wednesday, September 30, 2015 at 3:18 PM
> From: "Kevin Smith" 
> To: "XMPP Standards" 
> Subject: Re: [Standards] Deprecating Privacy Lists
>
> On 30 Sep 2015, at 09:07, Goffi  wrote:
> > I think a XEP should not be deprecated if its features are not superseeded 
> > by 
> > the new one(s).
> 

Agreed

> Just addressing this one point, rather than the wider ‘privacy lists’ issue. 
> I don’t think there’s any need to have a new XEP providing all the features 
> of another before the other can be deprecated.
> 
> /K
> 

My fear is that at some point in time, we might lose some features.

By stating this I actually apply that XSF members are irresponsible.

I think that members of XSF are good and high quality people, yet
I suggest to take extra cautious measures in this concern, such as
not deprecating XEP-0016 until there are other XEPs that cover any
thing that user can do with XEP-0016.

Re: [Standards] Deprecating Privacy Lists

On 9/29/15 2:02 PM, Sam Whited wrote:

I've brought up reconciling privacy lists and the blocking command in
the past [1], but the discussion faltered and it never went before the
council. It was brought up as part of a recent discussion again [2],
and I'd like to formally propose that it be deprecated.


As an author of XEP-0016, I am in favor of deprecating privacy lists, 
for the following reasons:


1. Smaller, simpler extensions to solve particular problems are 
preferable to large, complex frameworks.


2. We defined privacy lists to address a requirement from RFC 2779 that 
in fact we misunderstood, so it was over-engineered from the start.


Full disclosure: I have not yet read the long thread that resulted from 
Sam's original message.


Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] Deprecating Privacy Lists

[Sam Whited]

On Mon, Oct 12, 2015 at 2:04 PM, Ben Langfeld  wrote:
> Sorry Sam, just on something of a crusade against entitlement
> recently!

No worries; I think some of this discussion is interesting (catching
up now: disclaimer, I'm not at the end). However, if it's going to
continue a nice subject / thread change (WAS: Deprecating privacy
lists...) would be appreciated.



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 22:21:38 +0200
Ralph Meijer  wrote:

Technical arguments, finally :)

> One of the major problems on the client side, is that implementing a
> proper user interface for this protocol is a challenge and unlikely to
> be very intuitive. Have a look at Gajim's implementation. It seems to
> do everything the protocol specifies, but it is very confusing. See
> also . Suggested solutions in
> that ticket include breaking it down into simpler dialogs for
> specific use cases and then create/modify privacy lists rules for the
> result. This is a problem, because not only does the client developer
> have to think about proper abstractions, *every* client developer has
> to do the same work in their own implementation.
> ...
> As I mentioned before, deprecating a XEP just means that new
> implementations are not encouraged *by the XSF*. It means that the
> people currently on the Council have decided, based on input from the
> community, that the general consensus is that this particular
> enhancement is no longer the best way to go about things. It does not
> mean everyone agrees with that. It does not mean you can not start new
> implementation. It does not mean you can not use it.
> ...
> The next step might be obsoletion. This means that the XSF thinks that
> the protocol should not be deployed or used any longer. If you want,
> of course you can still do that, though.

The arguments are convincing, I admit. I hope XSF will find a solution
for blocking messages from unsubscribed users before the XEP moves to
obsoletion state.

Re: [Standards] Deprecating Privacy Lists

[Dave Cridland]

On 12 October 2015 at 20:32, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 16:27:51 -0300
> Ben Langfeld  wrote:
>
> > So your argument is in-fact that there's nothing wrong with Privacy
> > Lists and therefore the XSF should continue promoting it as a good
> > quality specification?
>
> No, probably it should be improved. The problem with Privacy Lists is
> that developers are trying to implement it as is and end up with
> iptables-like interface.
>

That's exactly it.

One client, used exclusively, can construct useful and valid rules to
express particular semantics (like invisibility, for example).

Two different clients can't recognise each other's rules and present any
kind of useful UX.

What's needed is a set of protocol which express, semantically, what the
user is trying to accomplish, such that different clients can universally
understand the semantics of the user's desires, and represent accordingly.

Dave.

Re: [Standards] Deprecating Privacy Lists

[Ralph Meijer]

On 2015-10-12 21:20, Evgeny Khramtsov wrote:
> Mon, 12 Oct 2015 16:04:43 -0300
> Ben Langfeld  wrote:
> 
>> "We want to deprecate Privacy Lists because we think it's a bad spec."
>> "You'll have to write a good spec first!"
>> "A good spec would be nice. Do you (or anyone else in the community)
>> fancy helping write one?"
>> "No! You (XSF council / mystical XEP-writing fairies) have to do it.
>> Don't you dare deprecate Privacy Lists!"
>> "Yeah, developers shouldn't have to write specs. That's the project
>> manager's job. Developers just translate specs into code."
> 
> Well basically that's true. Not in the details because you added to
> many emotions here (probably you're a very hurting person), but true.
> Ah, and still no technical arguments except "Privacy Lists are complex
> (just like PubSub)" :)

No. Some arguments, gotten from implementation experience, are actually
listed in the Blocking Command (XEP-0191) introduction:

RFC 3921 [1] includes an XMPP protocol extension for communications
blocking, which has since been moved to Privacy Lists (XEP-0016)
[2]. Unfortunately, because the privacy lists extension is quite
complex, it has not been widely implemented in servers and has been
implemented virtually not at all in clients. This is problematic,
since the ability to block communications with selected users is an
important feature for an instant messaging system (and is required
by RFC 2779 [3]). However, the full power of privacy lists is not
needed in order to block communications, so this document proposes a
simpler blocking protocol that meets the requirement specified in
RFC 2779 and can be implemented more easily in XMPP clients and
servers.

This has been recognised since 2006 and resulted in the deprecation of
the same protocol as being part of the XMPP IM specification over at the
IETF. Granted, probably more implementations of Privacy Lists happened
since then, but I have yet to meet a person that enjoyed working on
that.

One of the major problems on the server side, is that processing all
those, possibly complex, lists of rules, is very resource intensive.
This hurts performance and is why people are now actively moving away
from it. E.g. Prosody deciding is will not consider it part of its core,
with maintenance of the module passed to whomever wants to still spend
time on it.

One of the major problems on the client side, is that implementing a
proper user interface for this protocol is a challenge and unlikely to
be very intuitive. Have a look at Gajim's implementation. It seems to do
everything the protocol specifies, but it is very confusing. See also
. Suggested solutions in that ticket
include breaking it down into simpler dialogs for specific use cases and
then create/modify privacy lists rules for the result. This is a
problem, because not only does the client developer have to think about
proper abstractions, *every* client developer has to do the same work in
their own implementation.

The alternative, as shown for Blocking Command above, is that those
simpler use cases are indeed formulated and protocol specific for those
use cases is designed to make things easier to implement *and use* on
the client side, without every client developer having to reinvent the
wheel. A server implementation may still choose to translate that
protocol to privacy lists internally. Or not.

Most of the time, to get people to do something, they need an incentive:
an itch to scratch, a friend, family member, or customer that wants a
certain feature, and/or money. If no-one is indeed willing to come up
with a proposal for those simpler use cases (even if it is just the
protocol exchange on a napkin) than I indeed don't see that ever ending
up as a XEP.

The XSF is in the business of documenting enhancements to XMPP that it
can recommend as good common building blocks for various application
domains. Implementation experience might change how good we think such
a building block might be. And if someone indeed finds it insufficiently
good, they may suggest deprecating it. So far, general consensus seems
to be that Privacy Lists are not awesome, that Blocking Command is a
good alternative for an oft-use use case, and that no one has stepped up
to document alternative protocols for other use cases.

It doesn't require 15 years of prior experience to write a XEP and one
doesn't need to earn special credits for their proposals to be
considered. We do attempt to make sure things are consistent across
various XEPs. We have even written guidelines for protocol design
(XEP-0134: XMPP Design Guidelines) and writing XEPs themselves
(XEP-0143: Guidelines for Authors of XMPP Extension Protocols). If
anyone needs help to get there, shooting off an e-mail with some
suggested protocol exchanges will probably be sufficient to start a
fruitful discussion on this very list.

As I mentioned before, deprecating a XEP just means that

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 16:27:51 -0300
Ben Langfeld  wrote:

> So your argument is in-fact that there's nothing wrong with Privacy
> Lists and therefore the XSF should continue promoting it as a good
> quality specification?

No, probably it should be improved. The problem with Privacy Lists is
that developers are trying to implement it as is and end up with
iptables-like interface.

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 16:20, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 16:04:43 -0300
> Ben Langfeld  wrote:
>
> > "We want to deprecate Privacy Lists because we think it's a bad spec."
> > "You'll have to write a good spec first!"
> > "A good spec would be nice. Do you (or anyone else in the community)
> > fancy helping write one?"
> > "No! You (XSF council / mystical XEP-writing fairies) have to do it.
> > Don't you dare deprecate Privacy Lists!"
> > "Yeah, developers shouldn't have to write specs. That's the project
> > manager's job. Developers just translate specs into code."
>
> Well basically that's true. Not in the details because you added to
> many emotions here (probably you're a very hurting person), but true.
>

Ok, thanks for the psych eval, much appreciated.


> Ah, and still no technical arguments except "Privacy Lists are complex
> (just like PubSub)" :)
>

So your argument is in-fact that there's nothing wrong with Privacy Lists
and therefore the XSF should continue promoting it as a good quality
specification?

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 16:04:43 -0300
Ben Langfeld  wrote:

> "We want to deprecate Privacy Lists because we think it's a bad spec."
> "You'll have to write a good spec first!"
> "A good spec would be nice. Do you (or anyone else in the community)
> fancy helping write one?"
> "No! You (XSF council / mystical XEP-writing fairies) have to do it.
> Don't you dare deprecate Privacy Lists!"
> "Yeah, developers shouldn't have to write specs. That's the project
> manager's job. Developers just translate specs into code."

Well basically that's true. Not in the details because you added to
many emotions here (probably you're a very hurting person), but true.
Ah, and still no technical arguments except "Privacy Lists are complex
(just like PubSub)" :)

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 15:54, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 15:39:38 -0300
> Ben Langfeld  wrote:
>
> > On 12 October 2015 at 14:28, Evgeny Khramtsov 
> > wrote:
> >
> > > Mon, 12 Oct 2015 13:48:34 -0300
> > > Ben Langfeld  wrote:
> > >
> > > > What is your suggested solution to making XMPP easier to
> > > > contribute to?
> > >
> > > This is a very funny question from you. Because whatever one says
> > > can be opposed with "you're not a customer" argument.
> > >
> >
> > You've misunderstood what I've said. My opposition is not to ideas,
> > it's to the entitled way in which people put them forward. Ideas are
> > great; demanding that someone execute them for you is not.
>
> I think your position is hard to understand because you're juggling
> with the words. One can treat "Do not deprecate privacy lists" as an
> idea and it also can be treated as a demand depending on a person.
>

What I read was:

"We want to deprecate Privacy Lists because we think it's a bad spec."
"You'll have to write a good spec first!"
"A good spec would be nice. Do you (or anyone else in the community) fancy
helping write one?"
"No! You (XSF council / mystical XEP-writing fairies) have to do it. Don't
you dare deprecate Privacy Lists!"
"Yeah, developers shouldn't have to write specs. That's the project
manager's job. Developers just translate specs into code."

But I think my point has been made fairly clearly now and we've used up a
lot of screen space on a thread which I'm sure Sam had hoped would go more
smoothly. Sorry Sam, just on something of a crusade against entitlement
recently!

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 15:39:38 -0300
Ben Langfeld  wrote:

> On 12 October 2015 at 14:28, Evgeny Khramtsov 
> wrote:
> 
> > Mon, 12 Oct 2015 13:48:34 -0300
> > Ben Langfeld  wrote:
> >
> > > What is your suggested solution to making XMPP easier to
> > > contribute to?
> >
> > This is a very funny question from you. Because whatever one says
> > can be opposed with "you're not a customer" argument.
> >
> 
> You've misunderstood what I've said. My opposition is not to ideas,
> it's to the entitled way in which people put them forward. Ideas are
> great; demanding that someone execute them for you is not.

I think your position is hard to understand because you're juggling
with the words. One can treat "Do not deprecate privacy lists" as an
idea and it also can be treated as a demand depending on a person.

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 14:28, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 13:48:34 -0300
> Ben Langfeld  wrote:
>
> > What is your suggested solution to making XMPP easier to contribute
> > to?
>
> This is a very funny question from you. Because whatever one says can be
> opposed with "you're not a customer" argument.
>

You've misunderstood what I've said. My opposition is not to ideas, it's to
the entitled way in which people put them forward. Ideas are great;
demanding that someone execute them for you is not.

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 13:48:34 -0300
Ben Langfeld  wrote:

> What is your suggested solution to making XMPP easier to contribute
> to?

This is a very funny question from you. Because whatever one says can be
opposed with "you're not a customer" argument.

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 13:58:21 -0300
Ben Langfeld  wrote:

> My point is this:
> 
> 1. What appears to be a majority of the XSF does not believe that
> Privacy Lists should be promoted as the correct way to achieve the
> functionality it intended to provide.
> 2. The XSF has a tool to indicate this.
> 3. Your complaint is that for the XSF to make that indication public,
> someone must first write a replacement XEP.
> 4. You are not willing to write that XEP and further characterise
> other developers who are similarly unwilling as customers of the XSF.
> 
> I think, being fair, it's easy to see that your desire for an
> alternative XEP which provides the same functionality as Privacy
> Lists is appropriately treated as a request, but that you cannot use
> it as a demand for someone to do some work, or to block #1. Others
> have, earlier in this thread, made solid arguments for why a
> deprecation does not logically require a replacement.
> 
> I'm not trying to move the topic in any other direction. I'm trying
> to say "chill; ask don't demand; accept that maybe no-one will oblige
> your request and that that's ok and does not mean that the XSF is
> broken".

Well, if XSF solely decided to do what they think is right - it's OK.
But in this case I wonder why we have this list?
I also found the arguments as not solid. The only argument I saw is
that the XEP is too complex. But in that case they should deprecate
PubSub as well: it's also not widely adopted, probably even less adopted
than privacy lists.

Re: [Standards] Deprecating Privacy Lists

[Philipp Hancke]

I would say writing XEPs requires tons of effort: translating it into
English (for non-native speakers), arguing on the list, maintaining it,
etc.


But you usually get feedback in return for your investment.
Which, at least for me, makes it worth it.

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 13:42, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 13:03:52 -0300
> Ben Langfeld  wrote:
>
> > I'm happy with people reporting bugs against my open source projects.
> > When they come back and ask "is it done yet?", then I get mad.
>
> Your feelings are very interesting to know, but how this relates to the
> original problem about privacy lists replacement? Seems like you're
> trying to move the topic in another direction.
>

My point is this:

1. What appears to be a majority of the XSF does not believe that Privacy
Lists should be promoted as the correct way to achieve the functionality it
intended to provide.
2. The XSF has a tool to indicate this.
3. Your complaint is that for the XSF to make that indication public,
someone must first write a replacement XEP.
4. You are not willing to write that XEP and further characterise other
developers who are similarly unwilling as customers of the XSF.

I think, being fair, it's easy to see that your desire for an alternative
XEP which provides the same functionality as Privacy Lists is appropriately
treated as a request, but that you cannot use it as a demand for someone to
do some work, or to block #1. Others have, earlier in this thread, made
solid arguments for why a deprecation does not logically require a
replacement.

I'm not trying to move the topic in any other direction. I'm trying to say
"chill; ask don't demand; accept that maybe no-one will oblige your request
and that that's ok and does not mean that the XSF is broken".


> > "Has to" in the sense that in order to sustain standardisation, one
> > must write/edit standards. If you prefer to do something proprietary,
> > then of course you don't have to comply with the XSF's process. You
> > can't demand that the XSF does something and then say "but I won't do
> > it myself, YOU should do it".
>
> Yes, yes, I got your point: pay or do it yourself (GTFO, basically).
>

Those aren't the only options. Another is to simply be patient or to find
some other way in which to contribute. Your work on ejabberd is one of
those ways, and certainly has an important impact on XMPP. It can't be used
as a stick to demand someone write XEPs, though.


> The problem with such approach is that users tend to search for another
> project where developers don't treat them as complaining trolls.
> Though, this is also irrelevant to the current discussion about privacy
> lists :)
>

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 13:15, Vitaly Takmazov  wrote:

> > Take a look at the list of RFC and XEP authors for starters.
> That list is VERY short. And most authors have 15+ years of experience
> in related technologies.
> Indeed, there are some extensions from "beginners" but they are not
> widely adopted.
>
> > subscription for new ones to be written based on their requirements.
> "Subscription fee" for writing an XEP is **the time**.


I don't think you understood this.


> As I described
> in previous message -
> it is cheaper to write some domain-specific protocol from scratch,
> rather than adopt XMPP in that current outdated state.
>

What is your suggested solution to making XMPP easier to contribute to?


> > open-source entitlement.
> I have mention that now is 2015 - "you should use XMPP just because it
> is driven by open community"
> is not an answer in 2015: there are MANY open communities with open
> specs and opensource libraries.
> XMPP still lost it 2003.
> ---
>

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 13:03:52 -0300
Ben Langfeld  wrote:

> I'm happy with people reporting bugs against my open source projects.
> When they come back and ask "is it done yet?", then I get mad.

Your feelings are very interesting to know, but how this relates to the
original problem about privacy lists replacement? Seems like you're
trying to move the topic in another direction.

> "Has to" in the sense that in order to sustain standardisation, one
> must write/edit standards. If you prefer to do something proprietary,
> then of course you don't have to comply with the XSF's process. You
> can't demand that the XSF does something and then say "but I won't do
> it myself, YOU should do it".

Yes, yes, I got your point: pay or do it yourself (GTFO, basically).
The problem with such approach is that users tend to search for another
project where developers don't treat them as complaining trolls.
Though, this is also irrelevant to the current discussion about privacy
lists :)

Re: [Standards] Deprecating Privacy Lists

[Vitaly Takmazov]

> Take a look at the list of RFC and XEP authors for starters.
That list is VERY short. And most authors have 15+ years of experience
in related technologies.
Indeed, there are some extensions from "beginners" but they are not
widely adopted.

> subscription for new ones to be written based on their requirements.
"Subscription fee" for writing an XEP is **the time**. As I described
in previous message -
it is cheaper to write some domain-specific protocol from scratch,
rather than adopt XMPP in that current outdated state.

> open-source entitlement.
I have mention that now is 2015 - "you should use XMPP just because it
is driven by open community"
is not an answer in 2015: there are MANY open communities with open
specs and opensource libraries.
XMPP still lost it 2003.
---

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 12:17, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 09:51:28 -0300
> Ben Langfeld  wrote:
>
> > What else would you call it?
>
> You can stop bugtracker for your project then. There are only trolls.
>

I'm happy with people reporting bugs against my open source projects. When
they come back and ask "is it done yet?", then I get mad.

> Someone has to do this.
>
> So XSF created a standardization process and now tells us: someone has
> to do this.
>

"Has to" in the sense that in order to sustain standardisation, one must
write/edit standards. If you prefer to do something proprietary, then of
course you don't have to comply with the XSF's process. You can't demand
that the XSF does something and then say "but I won't do it myself, YOU
should do it".


> > XMPP is not perfect. Nothing is. It exists as a result of the good
> > will of those who contribute to it. We should remember that and be
> > grateful for it, not expect infinitely more.
>
> Common words.
>

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 12:25, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 09:48:07 -0300
> Ben Langfeld  wrote:
>
> > I'm afraid they'd be mistaken in this belief.
>
> Developers are bad, mmmkay.


Not mad, but lazy. This is one of the defining and some might argue
required traits of a software developer - it's what leads us to seek
one-time solutions for otherwise repetitious tasks. Unfortunately it boils
over into "that's someone else's job" sometimes, even when that "someone"
can't be identified.


> So what do you suggest? Teaching them to be
> better? I bet that's not the goal of XSF. I think the solution is to
> accept the fact developers do not want writing specs in general and act
> accordingly. As an example: do not deprecate XEPs when there is no
> replacement.
>

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 09:48:07 -0300
Ben Langfeld  wrote:

> I'm afraid they'd be mistaken in this belief.

Developers are bad, mmmkay. So what do you suggest? Teaching them to be
better? I bet that's not the goal of XSF. I think the solution is to
accept the fact developers do not want writing specs in general and act
accordingly. As an example: do not deprecate XEPs when there is no
replacement.

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 09:51:28 -0300
Ben Langfeld  wrote:

> What else would you call it?

You can stop bugtracker for your project then. There are only trolls.

> Someone has to do this.

So XSF created a standardization process and now tells us: someone has
to do this.

> XMPP is not perfect. Nothing is. It exists as a result of the good
> will of those who contribute to it. We should remember that and be
> grateful for it, not expect infinitely more.

Common words.

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 10:54, Vitaly Takmazov  wrote:

> > who complain about specs they want not existing believe is responsible
> for doing this for them at no cost, and why?
> Hi from 2015!


Hey there!


> There are number of options:
> 1) Get an existing protocol/library which is more suitable for the
> task. It can be "no cost", or much cheaper than fighting with
> inconsistent XMPP protocols and specs.
> 2) Develop protocol from scratch. It may cost developer time, but in
> most cases it is still cheaper. And you still can reuse existing
> ideas, specs, tools, experience, etc.
> 3) "Extend" XMPP without documentation and standartization, (whatsapp way)
>

And anyone is welcome to choose those options. If they do so, however, they
forfeit their right to complain that somehow they got "poor service" from
the XSF as if they were paying for it ;)


> And the counter question: who exactly these developers who want to
> contribute to XMPP community "at no cost"?


Take a look at the list of RFC and XEP authors for starters. As far as I am
aware, the XSF didn't pay any of them for their work, nor do the people who
rely on XMPP specifications pay for a license to use them, or a
subscription for new ones to be written based on their requirements.


> They already must be
> interested and motivated. How existing XMPP/XSF state (inconsistent,
> incomplete, absence of libraries, clients, name it) can motivate new
> developer to join it?
> ---
>

Maybe a sense of contributing to the greater good? Maybe for a head-start?
It doesn't really matter. If they choose to contribute, great! If they
choose not to then humble feedback is potentially useful, but complaining
and demanding is not. Unfortunately we seem to have got into a mentality of
open-source entitlement.

Re: [Standards] Deprecating Privacy Lists

[Vitaly Takmazov]

> who complain about specs they want not existing believe is responsible for 
> doing this for them at no cost, and why?
Hi from 2015! There are number of options:
1) Get an existing protocol/library which is more suitable for the
task. It can be "no cost", or much cheaper than fighting with
inconsistent XMPP protocols and specs.
2) Develop protocol from scratch. It may cost developer time, but in
most cases it is still cheaper. And you still can reuse existing
ideas, specs, tools, experience, etc.
3) "Extend" XMPP without documentation and standartization, (whatsapp way)

And the counter question: who exactly these developers who want to
contribute to XMPP community "at no cost"? They already must be
interested and motivated. How existing XMPP/XSF state (inconsistent,
incomplete, absence of libraries, clients, name it) can motivate new
developer to join it?
---

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 09:22, Evgeny Khramtsov  wrote:

> Mon, 12 Oct 2015 08:45:29 -0300
> Ben Langfeld  wrote:
>
> > If no-one is prepared to say why they won't do this but continues to
> > complain about the absence of XEPs then the assumption has to be that
> > they are trolling.
>
> So, if I complain there is no feature X in software Y and I'm unwilling
> to implement it, I'm trolling. Good point.
>

What else would you call it?


> > Could you share them?
>
> I would say writing XEPs requires tons of effort: translating it into
> English (for non-native speakers), arguing on the list, maintaining it,
> etc.
>

Someone has to do this. Who exactly do those developers who complain about
specs they want not existing believe is responsible for doing this for them
at no cost, and why?

XMPP is not perfect. Nothing is. It exists as a result of the good will of
those who contribute to it. We should remember that and be grateful for it,
not expect infinitely more.

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 09:35, Christian Schudt 
wrote:

> My explanation: Most developers just don't want to write specifications.
> They don't consider it to be their job.


I'm afraid they'd be mistaken in this belief. Note that we are not talking
about requirements documents here, we're talking about technical protocol
specifications.


> Similar like they also shy at writing documentation or even comments.
> Developers are lazy in this aspect.
>
> Developers just want to code, fix bugs, create a nice UI, apply logical
> thinking, etc...
>
> They are used to _read_ specifications and implement requirements, which
> usually come from *other* non-developers, e.g. "product owners, product
> managers", but not to _write_ them by themselves.
>
> Also nicely illustrated here:
> http://www.codefieber.de/images/geek_and_poke_coders-love-t.jpeg
> http://geek-and-poke.com/geekandpoke/2012/2/5/simply-explained.html
>
>
> >> I have some ideas why they don't do this.
>
> > Could you share them?
> >> I know a lot of developers
> >> from different projects who is unwilling to write XEPs. So my answer is
> >> "I don't know".
>
> > If no-one is prepared to say why they won't do this but continues to
> complain about the absence of XEPs then the assumption has to be that they
> are trolling.
>

Re: [Standards] Deprecating Privacy Lists

[Christian Schudt]

My explanation: Most developers just don't want to write specifications. They 
don't consider it to be their job. Similar like they also shy at writing 
documentation or even comments. Developers are lazy in this aspect.

Developers just want to code, fix bugs, create a nice UI, apply logical 
thinking, etc...

They are used to _read_ specifications and implement requirements, which 
usually come from *other* non-developers, e.g. "product owners, product 
managers", but not to _write_ them by themselves.

Also nicely illustrated here:
http://www.codefieber.de/images/geek_and_poke_coders-love-t.jpeg
http://geek-and-poke.com/geekandpoke/2012/2/5/simply-explained.html


>> I have some ideas why they don't do this.
 
> Could you share them?
>> I know a lot of developers
>> from different projects who is unwilling to write XEPs. So my answer is
>> "I don't know".
 
> If no-one is prepared to say why they won't do this but continues to complain 
> about the absence of XEPs then the assumption has to be that they are 
> trolling.

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Mon, 12 Oct 2015 08:45:29 -0300
Ben Langfeld  wrote:

> If no-one is prepared to say why they won't do this but continues to
> complain about the absence of XEPs then the assumption has to be that
> they are trolling.

So, if I complain there is no feature X in software Y and I'm unwilling
to implement it, I'm trolling. Good point.

> Could you share them?

I would say writing XEPs requires tons of effort: translating it into
English (for non-native speakers), arguing on the list, maintaining it,
etc.

Re: [Standards] Deprecating Privacy Lists

[Ben Langfeld]

On 12 October 2015 at 08:08, Evgeny Khramtsov  wrote:

> Thu, 8 Oct 2015 14:05:04 +0200
> Ralph Meijer  wrote:
>
> > Can you explain why people wanting to implement some feature couldn't
> > (begin to) write a XEP?
>
> I have some ideas why they don't do this.


Could you share them?


> I know a lot of developers
> from different projects who is unwilling to write XEPs. So my answer is
> "I don't know".
>

If no-one is prepared to say why they won't do this but continues to
complain about the absence of XEPs then the assumption has to be that they
are trolling.

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Thu, 8 Oct 2015 14:05:04 +0200
Ralph Meijer  wrote:

> Can you explain why people wanting to implement some feature couldn't
> (begin to) write a XEP?

I have some ideas why they don't do this. I know a lot of developers
from different projects who is unwilling to write XEPs. So my answer is
"I don't know".

Re: [Standards] Deprecating Privacy Lists

[Ralph Meijer]

On 2015-10-08 12:52, Evgeny Khramtsov wrote:
> Thu, 8 Oct 2015 12:21:41 +0200
> Ralph Meijer  wrote:
> 
>> If nobody comes up with a new specification for
>> functionality beyond XEP-0191, then my conclusion would be that there
>> is no sufficient interest
> 
> No. The conclusion also might be that people who want this
> functionality do not write XEPs.
> This is the same as with file-transfer. Obviously everyone wants it,
> but nobody is writing it (at least there is no XEP which fully resolves
> all FT possibilities I listed in previous threads).

Can you explain why people wanting to implement some feature couldn't
(begin to) write a XEP? I believe there are many people on this list who
would be more than happy to help out with such an effort. Peter
Saint-Andre has written dozens of XEPs based on people's first
back-of-the-envelope descriptions of a new protocol. It doesn't have to
be perfect on the first attempt, and it never has been, to be honest.
Once something is written down, it can be discussed and improved upon.

-- 
ralphm

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Thu, 8 Oct 2015 12:21:41 +0200
Ralph Meijer  wrote:

> If nobody comes up with a new specification for
> functionality beyond XEP-0191, then my conclusion would be that there
> is no sufficient interest

No. The conclusion also might be that people who want this
functionality do not write XEPs.
This is the same as with file-transfer. Obviously everyone wants it,
but nobody is writing it (at least there is no XEP which fully resolves
all FT possibilities I listed in previous threads).

Re: [Standards] Deprecating Privacy Lists

[Ralph Meijer]

On 2015-10-06 19:24, Evgeny Khramtsov wrote:
> Tue, 6 Oct 2015 11:35:58 -0500
> Sam Whited  wrote:
> 
>> and I doubt that
>> anyone's going to try and come up with a new thing *unless* the old
>> one is deprecated
> 
> The thing is nobody will come up even in the case the XEP is deprecated.
> There were several attempts to write SPIM related XEPs. None of them
> was widely adopted. So we may end up with servers with privacy
> lists disabled and their users unprotected from some sort of attacks.


A little background. After going draft, privacy lists as defined in
JEP-0016 were moved to the first XMPP IM specification (RFC 3921) and
thus deprecated as a JEP. Then, mostly because of the same reasons
(complexity and performance impact), it was dropped for the bis version
(eventually RFC 6121) and reinstated into JEP-0016 in 2006 [*1].

Initially, JEP-0191 (Blocking Command) was introduced as an alternative
that would go into the bis version of the RFC. However, it was decided
that the new RFC would just refer to both JEPs as ways to implement
blocking, as required by RFC 2779 (Instant Messaging / Presence Protocol
Requirements).

So basically, implementors have wanted to get rid of this stuff for
quite a while now.  If nobody comes up with a new specification for
functionality beyond XEP-0191, then my conclusion would be that there is
no sufficient interest. As I said before, the XSF does not generate
specifications that everybody then must implement. It works the other
way around: if there is enough interest in some feature, people will
work on a specification that can then be discussed and accepted by the
Council as a XEP.

Hopefully, such a specification is the result of ongoing experiments
around that feature. If interest dies down and/or fails to get proper
adoption, like happened with your SPIM XEP, it expires. While we can
attempt to steer implementors in a particular direction with Compliance
Suites [*2], even those are not a guarantee that things will get
widespread adoption.

I believe that dropping XEP-0016 is the way forward, and if there are
indeed pressing features that require an alternative, I hope people will
come and start a new, simpler, specification for just that feature and
work together with several implementors to get adoption.

Also note that Deprecated is not the same thing as Obsolete. Deprecation
just says we don't encourage new implementations. Obsolete says that a
protocol should no longer be implemented or deployed. We currently have
3 other Deprecated XEPs and 27 Obsolete ones.

[*1] This was around the same time of changing the naming of JEPs to
 XEPs along with the change of the JSF (Jabber Software Foundation)
 to the XSF.
[*2] Thanks, Sam, for picking that up again.

-- 
ralphm

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Tue, 6 Oct 2015 11:35:58 -0500
Sam Whited  wrote:

> and I doubt that
> anyone's going to try and come up with a new thing *unless* the old
> one is deprecated

The thing is nobody will come up even in the case the XEP is deprecated.
There were several attempts to write SPIM related XEPs. None of them
was widely adopted. So we may end up with servers with privacy
lists disabled and their users unprotected from some sort of attacks.

Re: [Standards] Deprecating Privacy Lists

[Sam Whited]

On Tue, Oct 6, 2015 at 7:10 AM, Evgeny Khramtsov  wrote:
> Not sure I understand the sentence. Wouldn't it be better to find
> "other ways" in blocking "unsolicited spam/flooding" *before*
> deprecating XEP-0016? Because after deprecation nobody will perform
> this task.

I don't agree that we should wait; people can continue to use the
existing functionality after it's been deprecated (like I said, it's
not going to dissapear from every server overnight), and I doubt that
anyone's going to try and come up with a new thing *unless* the old
one is deprecated and more servers are *considering* dropping
functionality.

—Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

Re: [Standards] Deprecating Privacy Lists

[Evgeny Khramtsov]

Tue, 6 Oct 2015 12:43:06 +0100
Kevin Smith  wrote:

> On 5 Oct 2015, at 14:42, Matthew Wild  wrote:
> > XEP-0191 is simple and efficient. It does one job, which is the one
> > that most users need and expect - blocking someone they not longer
> > want communication with. This operation is available on just about
> > every modern communication system they could be familiar with.
> > 
> > Other problems that XEP-0016 could be applied to, such as
> > unsolicited spam/flooding, should be taken care of in other ways,
> > instead of trying to solve everything (inadequately) with one
> > protocol.
> 
> I agree.
> 
> Deprecating 16 in favour of 191+the one extra common use case sounds
> good to me.
> 
> /K

Not sure I understand the sentence. Wouldn't it be better to find
"other ways" in blocking "unsolicited spam/flooding" *before*
deprecating XEP-0016? Because after deprecation nobody will perform
this task.

Re: [Standards] Deprecating Privacy Lists

[Goffi]

Le mardi 6 octobre 2015, 13:09:34 Florian Schmaus a écrit :
> I've started a Wiki Page to collect opinions, arguments and possible
> solutions at
> 
> http://wiki.xmpp.org/web/Server_Aided_Communications_Blocking
> 
> Feel free to contribute your arguments, opinions and solutions.
> 
> My summary so far is that blocking command does not support some use
> cases I consider important. Most prominent is the ability to block
> stanzas from entities they users is not subscribed to. This is required
> in order to prevent an attacker, to which the user is not subscribed,
> from draining a mobile users battery by sending stanzas to the users JID.
> 
> - Florian

Good idea, but the page is only talking about blocking, invisibility is in the 
same boat (it's not possible to be (in)visible to a roster group with 
XEP-0186).

Goffi

Re: [Standards] Deprecating Privacy Lists

[Kevin Smith]

On 5 Oct 2015, at 14:42, Matthew Wild  wrote:
> XEP-0191 is simple and efficient. It does one job, which is the one
> that most users need and expect - blocking someone they not longer
> want communication with. This operation is available on just about
> every modern communication system they could be familiar with.
> 
> Other problems that XEP-0016 could be applied to, such as unsolicited
> spam/flooding, should be taken care of in other ways, instead of
> trying to solve everything (inadequately) with one protocol.

I agree.

Deprecating 16 in favour of 191+the one extra common use case sounds good to me.

/K

Re: [Standards] Deprecating Privacy Lists

[Florian Schmaus]

I've started a Wiki Page to collect opinions, arguments and possible
solutions at

http://wiki.xmpp.org/web/Server_Aided_Communications_Blocking

Feel free to contribute your arguments, opinions and solutions.

My summary so far is that blocking command does not support some use
cases I consider important. Most prominent is the ability to block
stanzas from entities they users is not subscribed to. This is required
in order to prevent an attacker, to which the user is not subscribed,
from draining a mobile users battery by sending stanzas to the users JID.

- Florian





signature.asc
Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

[Matthew Wild]

On 1 October 2015 at 05:04, Sergei Golovan  wrote:
> On Wed, Sep 30, 2015 at 4:54 PM, Sam Whited  wrote:
>> This seems like a great candidate to add to the blocking command, and
>> something that we should persue if we think that it's a common enough
>> use case. However, I don't see it as a blocker to deprecating privacy
>> lists (it's not like deprecating privacy lists instantly means that
>> all clients and servers will stop supporting it; it's just the XSF
>> recommending that it not be implemented anymore for new
>> implementations).
>
> As long as server developers don't start removing Privacy lists
> support. And as we can see, Prosody developers might.

We're removing it from the default distribution, although the module
will still be available for people who still want to support it on
their server. That's fine.

Privacy lists are a pain on the server side. Having to iterate lists
of rules for every stanza, and the per-user and per-session
distinction, it just leads to complex code with many "what if"
scenarios and corner cases to think about. I think it's a bad
experience overall.

XEP-0191 is simple and efficient. It does one job, which is the one
that most users need and expect - blocking someone they not longer
want communication with. This operation is available on just about
every modern communication system they could be familiar with.

Other problems that XEP-0016 could be applied to, such as unsolicited
spam/flooding, should be taken care of in other ways, instead of
trying to solve everything (inadequately) with one protocol.

That said, this is just my opinion. I'm not going to stop anyone using
XEP-0016 if that's what they would prefer to do.

Regards,
Matthew

Re: [Standards] Deprecating Privacy Lists

[Sergei Golovan]

On Wed, Sep 30, 2015 at 4:54 PM, Sam Whited  wrote:
> On Wed, Sep 30, 2015 at 2:57 AM, Sergei Golovan  wrote:
>> Well, It's unfortunate, because XEP-0191 doesn't cover the following case
>> I'd consider important: it doesn't allow me to block all messages from
>> unknown contacts (contacts not in my roster). Recently, I received a
>> fair amount of
>> spam from random JIDs on public XMPP servers, so I had to block all
>> unknown JIDs. Is there any way to do that without privacy lists?
>
> That's a great use case; I can't say that I've ever used it myself
> (what client are you using that actually allows you to do this, by the
> way?), but I can see the value in it.

In my case it's Tkabber, but I think every client supporting XEP-0016
can block communications based on contacts subscription status.

>
> This seems like a great candidate to add to the blocking command, and
> something that we should persue if we think that it's a common enough
> use case. However, I don't see it as a blocker to deprecating privacy
> lists (it's not like deprecating privacy lists instantly means that
> all clients and servers will stop supporting it; it's just the XSF
> recommending that it not be implemented anymore for new
> implementations).

As long as server developers don't start removing Privacy lists
support. And as we can see, Prosody developers might.

Cheers!
-- 
Sergei Golovan

Re: [Standards] Deprecating Privacy Lists

[Christian Schudt]

> Hmm, not sure if you can translate this to xep191. What happens if a
> xep191 client removes a jid entry which was added by the server because
> the jid is the 'enemies' group?

The server should map in both ways, i.e. reflect changes to XEP-0191 into the 
privacy lists, and also reflect changes in privacy lists to block lists.
In this specific case, the server would modify the privacy list by adding a 
rule (before the old rule), which allows the removed JID:



The server would then allow traffic from this user, but would still block 
everyone else from the "Enemies" group.

Such mapping in both directions can probably be complicated, but it shouldn't 
be impossible with well defined mapping rules.

Generating a block list from a privacy list should be easy, because it's just a 
small subset.
Merging changes in a block list to an existing privacy list (as in the example 
above) is more tricky, but certainly doable.
 

Re: [Standards] Deprecating Privacy Lists

[Holger Weiß]

* Florian Schmaus  [2015-09-30 15:26]:
> On 30.09.2015 15:09, Holger Weiß wrote:
> > * Florian Schmaus  [2015-09-30 14:37]:
> >> What about XEP-191 § 5?
> >
> > This doesn't solve the issue:
> > http://mail.jabber.org/pipermail/standards/2014-December/029430.html
>
> It appears it could solve it: The client using xep16 generates an
> privacy list item as per xep191 § 5, and the server exposes this item as
> blocked jid item for clients using xep191. Maybe Sam or you could
> provide some details in this case: How does the privacy item look like
> which gajim does generate?

Gajim blocks everything but incoming presence:

  

  

  
  
  
   
  

  

> Does the server transform xep191 and xep16 entries?

Yes, but ejabberd considers a JID as "blocked" in the sense of XEP-0191
only if all stanza types are blocked in both directions.

> But I've not heard that that this is a problem. And I don't
> think it will be: The user used a xep16 client to generate the xep16
> rules and is therefore aware that they exist.

Please explain this to my users.  They press a "block" knob in Gajim.
Later they use Pidgin, where the blocked contact is marked as unblocked.
Their reaction is usually not like "oh sure, I remember how I used an
XEP-0016 client to generate an XEP-0016 rule last year.  My new client
just implements XEP-0191, so the behavior is obvious."  Instead, they
simply perceive this as yet another XMPP brokenness.

Holger

Re: [Standards] Deprecating Privacy Lists

[Florian Schmaus]

On 30.09.2015 15:29, Christian Schudt wrote:
> It's the server's responsibility to return an adequate block list, which is 
> built/mapped from a privacy list.
> E.g. if the privacy list contains a single rule:
>value='Enemies'
>   action='deny'
>   order='1'/>
> 
> The server would translate it to a block list, which contains all contacts in 
> the 'Enemies' roster group.

Hmm, not sure if you can translate this to xep191. What happens if a
xep191 client removes a jid entry which was added by the server because
the jid is the 'enemies' group?

But mapping plain jid xep16 items to xep191 entries and vice versa
should be sufficient (and easy).

- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

[Sam Whited]

On Wed, Sep 30, 2015 at 8:29 AM, Christian Schudt
 wrote:
> IMO, it's not a client interop issue, but a server mapping issue and a lack 
> of well specified mapping rules.

The problem is that privacy lists is almost too flexible, making it
both difficult to implement, and difficult to create that server side
mapping. Eg. you might map only action='deny', but then a client may
choose to block only a subset of stanzas from a client (maybe it still
wants to receive presence updates) using privacy lists. The server
won't see that as "blocked". It only works when all clients use the
exact same behavior for "blocked" (a behavior that must exactly match
that described in the Blocking Command XEP).

Having two specs that do roughly the same thing (or one doing a
superset of the other) will always cause client interop issues, and it
certainly does here. Work arounds on the server side can only get you
so far. Specifying the mapping rules would definitely work better, and
possibly mandating that clients MUST use those mapping rules if they
provide a simple "block" interface, but I suspect that that will only
uncover another little issue in which the two don't work so well
together.

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

Re: [Standards] Deprecating Privacy Lists

[Sam Whited]

On Wed, Sep 30, 2015 at 2:57 AM, Sergei Golovan  wrote:
> Well, It's unfortunate, because XEP-0191 doesn't cover the following case
> I'd consider important: it doesn't allow me to block all messages from
> unknown contacts (contacts not in my roster). Recently, I received a
> fair amount of
> spam from random JIDs on public XMPP servers, so I had to block all
> unknown JIDs. Is there any way to do that without privacy lists?

That's a great use case; I can't say that I've ever used it myself
(what client are you using that actually allows you to do this, by the
way?), but I can see the value in it.

This seems like a great candidate to add to the blocking command, and
something that we should persue if we think that it's a common enough
use case. However, I don't see it as a blocker to deprecating privacy
lists (it's not like deprecating privacy lists instantly means that
all clients and servers will stop supporting it; it's just the XSF
recommending that it not be implemented anymore for new
implementations).

—Sam

Re: [Standards] Deprecating Privacy Lists

[Christian Schudt]

> http://mail.jabber.org/pipermail/standards/2014-December/029430.html

> The problem is that it's unclear (to me) how to map XEP-0016 rules that
> block some kinds of stanzas but not others.

If that's all, I think XEP-0191 §5 only lacks a more precise mapping of 0016 
privacy list to block list.

It's the server's responsibility to return an adequate block list, which is 
built/mapped from a privacy list.
E.g. if the privacy list contains a single rule:


The server would translate it to a block list, which contains all contacts in 
the 'Enemies' roster group.

IMO, it's not a client interop issue, but a server mapping issue and a lack of 
well specified mapping rules.

- Christian

Re: [Standards] Deprecating Privacy Lists

[Florian Schmaus]

On 30.09.2015 15:09, Holger Weiß wrote:
> * Florian Schmaus  [2015-09-30 14:37]:
>> On 30.09.2015 10:47, Holger Weiß wrote:
>>> * Christian Schudt  [2015-09-30 10:38]:
 XEP-0016 is complex, but powerful. I see no reason to deprecate it, just
 because there's a similar XEP (0191).
>>>
>>> That's not the reasoning.  The reasoning is that they aren't compatible.
>>
>> What about XEP-191 § 5?
> 
> This doesn't solve the issue:
> http://mail.jabber.org/pipermail/standards/2014-December/029430.html

It appears it could solve it: The client using xep16 generates an
privacy list item as per xep191 § 5, and the server exposes this item as
blocked jid item for clients using xep191. Maybe Sam or you could
provide some details in this case: How does the privacy item look like
which gajim does generate? Does the server transform xep191 and xep16
entries?

It is my understanding that servers supporting xep16 and xep191 SHOULD
translate a xep16 privacy list item



simply into


  


as per xep191 § 5.

> The problem is that it's unclear (to me) how to map XEP-0016 rules that
> block some kinds of stanzas but not others.

You can't map those to xep191. After all xep16 is more powerful then
xep191. Therefore clients using just xep191 will never be aware of their
existence. But I've not heard that that this is a problem. And I don't
think it will be: The user used a xep16 client to generate the xep16
rules and is therefore aware that they exist.


- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

[Holger Weiß]

* Florian Schmaus  [2015-09-30 14:37]:
> On 30.09.2015 10:47, Holger Weiß wrote:
> > * Christian Schudt  [2015-09-30 10:38]:
> >> XEP-0016 is complex, but powerful. I see no reason to deprecate it, just
> >> because there's a similar XEP (0191).
> > 
> > That's not the reasoning.  The reasoning is that they aren't compatible.
> 
> What about XEP-191 § 5?

This doesn't solve the issue:

http://mail.jabber.org/pipermail/standards/2014-December/029430.html

The problem is that it's unclear (to me) how to map XEP-0016 rules that
block some kinds of stanzas but not others.

Holger

Re: [Standards] Deprecating Privacy Lists

[Florian Schmaus]

On 29.09.2015 22:02, Sam Whited wrote:
> Deprecating privacy lists will simplify the XMPP stack and 

...would remove the only way to for mobile clients to block
communication on server side based on the subscription type. Which is
currently the only way mobile clients can protect against a malicious
entities draining their battery by sending stanzas to the victims mobile
device.

Until there is no alternative which prevents this attack vector, xep16
can not be deprecated.

- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

[Florian Schmaus]

On 30.09.2015 10:47, Holger Weiß wrote:
> * Christian Schudt  [2015-09-30 10:38]:
>> XEP-0016 is complex, but powerful. I see no reason to deprecate it, just
>> because there's a similar XEP (0191).
> 
> That's not the reasoning.  The reasoning is that they aren't compatible.

What about XEP-191 § 5?

- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

[Dave Cridland]

On 30 September 2015 at 09:07, Florian Schmaus  wrote:

> Can you deprecate something without having an equal powerful alternative
> at hand?
>

>From a general standpoint, yes.

Simplifying and removing unused use-cases seems perfectly fine.

There are specific questions about whether there are important use-cases
enabled by Privacy Lists which are unavailable via '191 and '186; but there
is no general principle that every feature of a deprecated protocol must be
available in its successor(s), nor that there even are successors.

Also, deprecating a protocol doesn't mean you're not allowed to implement
or use it. Just that it shouldn't be expected anymore.

Dave.

Re: [Standards] Deprecating Privacy Lists

[Kevin Smith]

On 30 Sep 2015, at 09:07, Goffi  wrote:
> I think a XEP should not be deprecated if its features are not superseeded by 
> the new one(s).

Just addressing this one point, rather than the wider ‘privacy lists’ issue. I 
don’t think there’s any need to have a new XEP providing all the features of 
another before the other can be deprecated.

/K

Re: [Standards] Deprecating Privacy Lists

[Goffi]

Le mercredi 30 septembre 2015, 10:47:44 Holger Weiß a écrit :

> Interoperability between clients is broken today due to the use of two
> incompatible extensions.

Then the interop issue should be fixed.

I think a global invisible command like in XEP-0186 is a really bad idea: 
invisibility is useful with granularity. Of course you can send directed 
presences, but if I have 200 people in a roster group, I don't want to send 
200 directed presences, and keep it up to date if I add/remove people to/from 
that group.

I want to be able to:

- be (in)visible to one or several groups
- block people from one or several groups
- block people not in my roster

I think that's the basic requirement, and I would be happy with simpler XEP 
allowing these use cases (it would have been nice to update XEP-0186 but the 
last call for draft has expired, so I guess it's too late).
As long as it is not possible to do that, privacy lists should not be 
deprecated.

There are probably other use cases I don't think about right now, maybe other 
developers/users can point them out.

Goffi

Re: [Standards] Deprecating Privacy Lists

[Holger Weiß]

* Christian Schudt  [2015-09-30 10:38]:
> XEP-0016 is complex, but powerful. I see no reason to deprecate it, just
> because there's a similar XEP (0191).

That's not the reasoning.  The reasoning is that they aren't compatible.

> I don't care about Prosody, but why would one remove XEP-0016 entirely?
> It will break clients only.

Interoperability between clients is broken today due to the use of two
incompatible extensions.

Holger

Re: [Standards] Deprecating Privacy Lists

[Christian Schudt]

I agree to Florian, Goffi etc...

XEP-0016 is complex, but powerful. I see no reason to deprecate it, just 
because there's a similar XEP (0191). In our company we've had an requirement 
to be invisible to certain roster groups. This is not solvable with other XEPs.

The other mentioned use case -blocking users, which are not subscribed to my 
presence- is perfectly valid, too.

I don't care about Prosody, but why would one remove XEP-0016 entirely? It will 
break clients only.

- Christian
 

Gesendet: Mittwoch, 30. September 2015 um 10:07 Uhr
Von: Goffi 
An: "XMPP Standards" 
Betreff: Re: [Standards] Deprecating Privacy Lists
I'm strongly against deprecating XEP-0016: we are working a lot with groups,
and neither XEP-0191 nor XEP-0186 allow to block/be (in)visible only for a
group.

I think a XEP should not be deprecated if its features are not superseeded by
the new one(s).

thanks
Goffi

Le mardi 29 septembre 2015, 15:02:02 Sam Whited a écrit :
> I've brought up reconciling privacy lists and the blocking command in
> the past [1], but the discussion faltered and it never went before the
> council. It was brought up as part of a recent discussion again [2],
> and I'd like to formally propose that it be deprecated.
>
> I have made a pull request here: https://github.com/xsf/xeps/pull/104
>
> As I see it, privacy lists are complicated and don't work well with
> the blocking command in practice. As an example, if I block a user (on
> an ejabberd server) in Gajim (which uses privacy lists), and then view
> the same user in Conversations (which suports the blocking command),
> that user does not appear blocked because Gajim's privacy list is
> slightly different from what the server considers "blocked" so it's
> never mapped to the privacy lists.
>
> The majority of the functionality of privacy lists is covered by
>
> - XEP-0191: Blocking command
> - XEP-0186: Invisibility
>
> While privacy lists do have other functionality, it is rarely used.
>
> Deprecating privacy lists will simplify the XMPP stack and remove one
> more interop issue between clients which implement different
> protocols, and I'd like to request that it be taken up and discussed
> by the council.
>
> Best,
> Sam
>
>
>
> [1]: 
> http://mail.jabber.org/pipermail/standards/2014-December/029402.html[http://mail.jabber.org/pipermail/standards/2014-December/029402.html]
> [2]: 
> http://mail.jabber.org/pipermail/standards/2015-September/030358.html[http://mail.jabber.org/pipermail/standards/2015-September/030358.html]
 

Re: [Standards] Deprecating Privacy Lists

[Goffi]

I'm strongly against deprecating XEP-0016: we are working a lot with groups, 
and neither XEP-0191 nor XEP-0186 allow to block/be (in)visible only for a 
group.

I think a XEP should not be deprecated if its features are not superseeded by 
the new one(s).

thanks
Goffi

Le mardi 29 septembre 2015, 15:02:02 Sam Whited a écrit :
> I've brought up reconciling privacy lists and the blocking command in
> the past [1], but the discussion faltered and it never went before the
> council. It was brought up as part of a recent discussion again [2],
> and I'd like to formally propose that it be deprecated.
> 
> I have made a pull request here: https://github.com/xsf/xeps/pull/104
> 
> As I see it, privacy lists are complicated and don't work well with
> the blocking command in practice. As an example, if I block a user (on
> an ejabberd server) in Gajim (which uses privacy lists), and then view
> the same user in Conversations (which suports the blocking command),
> that user does not appear blocked because Gajim's privacy list is
> slightly different from what the server considers "blocked" so it's
> never mapped to the privacy lists.
> 
> The majority of the functionality of privacy lists is covered by
> 
> - XEP-0191: Blocking command
> - XEP-0186: Invisibility
> 
> While privacy lists do have other functionality, it is rarely used.
> 
> Deprecating privacy lists will simplify the XMPP stack and remove one
> more interop issue between clients which implement different
> protocols, and I'd like to request that it be taken up and discussed
> by the council.
> 
> Best,
> Sam
> 
> 
> 
> [1]: http://mail.jabber.org/pipermail/standards/2014-December/029402.html
> [2]: http://mail.jabber.org/pipermail/standards/2015-September/030358.html

Re: [Standards] Deprecating Privacy Lists

[Florian Schmaus]

On 29.09.2015 22:02, Sam Whited wrote:
> I've brought up reconciling privacy lists and the blocking command in
> the past [1], but the discussion faltered and it never went before the
> council. It was brought up as part of a recent discussion again [2],
> and I'd like to formally propose that it be deprecated.
> 
> I have made a pull request here: https://github.com/xsf/xeps/pull/104

> 
> As I see it, privacy lists are complicated and don't work well with
> the blocking command in practice. As an example, if I block a user (on
> an ejabberd server) in Gajim (which uses privacy lists), and then view
> the same user in Conversations (which suports the blocking command),
> that user does not appear blocked because Gajim's privacy list is
> slightly different from what the server considers "blocked" so it's
> never mapped to the privacy lists.

Can't that be solved without deprecating privacy lists? E.g. by defining
a privacy list item which exactly maps to a blocked xep191 user?

> The majority of the functionality of privacy lists is covered by
> 
> - XEP-0191: Blocking command
> - XEP-0186: Invisibility
> 
> While privacy lists do have other functionality, it is rarely used.

According to which analysis or to whom?

> Deprecating privacy lists 

Can you deprecate something without having an equal powerful alternative
at hand?

I don't think it's the right time to deprecate privacy lists. There is
no equal alternative available, nor, as far as I can tell, has there
been any effort attempting to solving the interop issues.

- Florian



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

[Sergei Golovan]

Hi Sam,

On Tue, Sep 29, 2015 at 11:02 PM, Sam Whited  wrote:
> I've brought up reconciling privacy lists and the blocking command in
> the past [1], but the discussion faltered and it never went before the
> council. It was brought up as part of a recent discussion again [2],
> and I'd like to formally propose that it be deprecated.

Well, It's unfortunate, because XEP-0191 doesn't cover the following case
I'd consider important: it doesn't allow me to block all messages from
unknown contacts (contacts not in my roster). Recently, I received a
fair amount of
spam from random JIDs on public XMPP servers, so I had to block all
unknown JIDs. Is there any way to do that without privacy lists?

Cheers!
-- 
Sergei Golovan

Re: [Standards] Deprecating Privacy Lists

[Kim Alvefur]

On 2015-09-29 22:02, Sam Whited wrote:
> I've brought up reconciling privacy lists and the blocking command in
> the past [1], but the discussion faltered and it never went before the
> council. It was brought up as part of a recent discussion again [2],
> and I'd like to formally propose that it be deprecated.

+1

Privacy lists support will be gone from the next major release of
Prosody.  It will ship with a Blocking command implementation instead.

-- 
Kim "Zash" Alvefur



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Deprecating Privacy Lists

[Yann Leboulanger]

On 09/29/2015 10:02 PM, Sam Whited wrote:
> I've brought up reconciling privacy lists and the blocking command in
> the past [1], but the discussion faltered and it never went before the
> council. It was brought up as part of a recent discussion again [2],
> and I'd like to formally propose that it be deprecated.
>
> I have made a pull request here: https://github.com/xsf/xeps/pull/104
>
> As I see it, privacy lists are complicated and don't work well with
> the blocking command in practice. As an example, if I block a user (on
> an ejabberd server) in Gajim (which uses privacy lists), and then view
> the same user in Conversations (which suports the blocking command),
> that user does not appear blocked because Gajim's privacy list is
> slightly different from what the server considers "blocked" so it's
> never mapped to the privacy lists.
>
> The majority of the functionality of privacy lists is covered by
>
> - XEP-0191: Blocking command
> - XEP-0186: Invisibility
>
> While privacy lists do have other functionality, it is rarely used.
>
> Deprecating privacy lists will simplify the XMPP stack and remove one
> more interop issue between clients which implement different
> protocols, and I'd like to request that it be taken up and discussed
> by the council.
>
> Best,
> Sam
>
>
>
> [1]: http://mail.jabber.org/pipermail/standards/2014-December/029402.html
> [2]: http://mail.jabber.org/pipermail/standards/2015-September/030358.html
>

Gajim implements both XEPs, but prefers (and uses) Privacy Lists if
server supports it, as already mentionned here [0], because it allows to
block a group. XEP-0191 doesn't have this feature.

[0]: http://mail.jabber.org/pipermail/standards/2014-December/029419.html

-- 
Yann