[Standards] Deprecating Privacy Lists

Ralph Meijer ralphm at ik.nu
Mon Oct 12 20:21:38 UTC 2015


On 2015-10-12 21:20, Evgeny Khramtsov wrote:
> Mon, 12 Oct 2015 16:04:43 -0300
> Ben Langfeld <ben at langfeld.me> 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
<https://trac.gajim.org/ticket/3357>. 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 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.

I sincerily hope that this sheds some light on why things are done this
way at the XSF, so that we can help you work towards solving problems. I
don't like to deal with hypotheticals much. If you see a gap in our
building blocks with actual user demand, with Privacy Lists is no longer
considered the best approach, please help us find a suitable new
building block to cover that case.

-- 
Cheers,

ralphm


More information about the Standards mailing list