[Standards] Deprecating Privacy Lists

Evgeny Khramtsov xramtsov at gmail.com
Mon Oct 12 20:54:57 UTC 2015

Mon, 12 Oct 2015 22:21:38 +0200
Ralph Meijer <ralphm at ik.nu> wrote:

Technical arguments, finally :)

> 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.
> ...
> 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.

The arguments are convincing, I admit. I hope XSF will find a solution
for blocking messages from unsubscribed users before the XEP moves to
obsoletion state.

More information about the Standards mailing list