[Standards] Deprecating Privacy Lists

Matthew Wild mwild1 at gmail.com
Mon Oct 5 13:42:00 UTC 2015


On 1 October 2015 at 05:04, Sergei Golovan <sgolovan at nes.ru> wrote:
> On Wed, Sep 30, 2015 at 4:54 PM, Sam Whited <sam at samwhited.com> 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


More information about the Standards mailing list