Re: [Standards] Deprecating Privacy Lists (again)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 ___
[Standards] Deprecating Privacy Lists (again)
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 ___
