Fabio Forno wrote:
> (sorry for the delays, but in the last two days of many standards_ml
> mails went into the spam folder :( )
Hopefully I just put an end to that!
> I agree with the fact there is no general abstraction for privacy
> lists and there complexity is far beyond the capabilities of the
> average user (the psi interface for example is of little help if you
> don't know basic xmpp concepts, and even if you know building them is
> pretty along task). What I was meaning is just that between adding a
> new namespace (such as in xep-186) or reusing something already
> present (xep-126), I prefer the second one. If haven't missed a
> discussion where xep-126 has been definitely turned down, the main
> obstacle of a "simple" privacy list approach is that there is no
> agreement between client developers in naming the lists associated to
> basic blocking or invisibility operations, and about when keeping them
> active (if there are more issues, please point me to the correct
> discussion, I'm new in this subject, since I've just started studying
> it for our mobile clients, where we really need fine grained temporary
> invisibility or unwanted packet blocking).
So this is interesting. In the resource generation thread, we have
people trying to fix something that's not broken. In this thread, we
have people trying to prevent anyone from fixing something that *is*
broken. Human psychology is endlessly fascinating. :)
Privacy lists were unnecessary even in the very beginning to solve the
problem we thought they needed to solve, which is essentially the
following points from RFC 2779:
5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL
from subscribing.
5.2.3. It MUST be possible for B to prevent A from receiving
notifications, even if A is ordinarily permitted to see such
notifications.
5.4.10. B MUST be able to prevent A from sending him messages
These requirements could have been solved with simple communications
blocking (XEP-0191) instead of privacy lists (XEP-0016), but privacy
lists were the hammer we had at that time so we decided to bang the nail
with that hammer rather than building something simpler (in part because
we misunderstood the requirements from RFC 2779).
I submit that the same reasoning applies to invisibility (which was not
even a requirement from RFC 2779).
Given that so many developers find privacy lists so confusing (not to
mention end users!!!), I would very much like to use XEP-0191 and
XEP-0186 for blocking and invisibility because they are much simpler for
everyone to grok ("block this user", "go invisible", what could be
easier?). If people then feel they need privacy lists for some more
advanced functionality, we have the technology ready to use. But I see
no good reason to keep hitting these two particular nails with the big
sledgehammer we created back in 2002 (does anyone here remember "zebra
lists"?) when much simpler tools can do the job.
Peter
--
Peter Saint-Andre
https://stpeter.im/
