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: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
