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 <m...@ruff.mobi>: > > > On 23.03.2017 14:18, Dave Cridland wrote: > >> On 22 March 2017 at 20:08, Ruslan N. Marchenko <m...@ruff.mobi> wrote: >> >>> On 22.03.2017 20:37, Sam Whited wrote: >>> >>>> On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger <aste...@lagaule.org> >>>> 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 _______________________________________________
