On Thu Mar 20 00:15:38 2008, Carlo v. Loesch wrote:
Richard Dobson typeth:
| The biggest issue with simply directing presence stanzas to the
remote
| domain and then letting that fan it out by itself (rather than
using
| something like the repeaters here) is that it means privacy lists
(or
| anything which works in a similar way to them, i.e. being able to
| selectively stop presence going to roster items without changing
your
| subscription) stop working at entirely, and I can't really see a
way
| around that without using a concept such as repeaters where you
are
| specifically telling the remote server who you want it fanned out
to.
It's a very XMPP-as-it-is point of view, but from an outsider's
point
of view I'd like to mention that the XMPP notion of polite presence
silence might feel morally hypocritical: Why can't I have the
honesty
towards my non-friend to let him know that I no longer intend to
send
him presence? Why do I asymmetrically keep on accepting his
presence,
instead? A technological step that makes it harder to implement such
asymmetry, seems to be a leap towards fairness.
Whether that's true or not, protocols do not make political or moral
statements, and nor should they. Protocols just enable what people
want to do, whether you agree with that or not. There's a name for
organizations which dictate moral stances and attempt to enforce
them, and whilst we've already got the sainthood, I'd rather not be a
cardinal of XMPP. :-)
| Of course an evil server could still forward it to people you
have not
| told it to but that will always be so as as you say its out of
your
| hands, but at least with repeaters non-evil servers actually have
an
| idea of where you want the presence stanzas to go.
I wouldn't call a server "evil" that undermines hypocrisy by
letting its users know when they are being presence-abused.
It's not a question of evil or not. The protocol does what people
want. Conceptually, the information a user transmits, or causes to be
transmitted on their behalf, should be under their control. I have no
more moral right to your presence information than I do to your
messages, or your bank card's PIN code.
If there's to be any moral impact of the protocol design, it is
simply that we should enable the user to enforce that their outgoing
information conforms to their own set of moral values - we cannot do
the same in reverse, because - morally - we cannot allow people to
enforce their moral views on others.
It's a hard life, trying to be morally neutral.
Repeaters are a technological improvement, although the XEP should
mention the people who made such type of suggestions in the first
place - and dropping the morally doubtful concept of privacy lists
for a more fair and efficient strategy, would be even better.
But XMPP is no arena for drastic measures. Let's wait a few more
years... until repeaters are too expensive for scalability.
I'm not yet convinced that repeaters *are* a technological
improvement, quite yet, so this is, to a degree, quite encouraging
talk. I'll write another message on this, though.
It strikes me as a happy coincidence for you that your moral stance
happens to yield an efficient method of moving presence fan-out off
the user's server. I feel I ought to point out that this doesn't make
it any "more moral".
If we consider a case where no privacy lists were in use, and if we
handle roster synchronization, and if we ignore directed presence,
and if we assume that users could and must trust (or, are morally
obliged to trust) remote servers (quite a bunch of ifs, there), we
could perform remote fan-out of presence based on the remote server's
roster data.
I would point out that if (like us, as it happens) users' rosters are
stored in a per-user file, that reverse roster lookup is going to be
exceedingly painful. It's not too bad if you're using SQL or LDAP,
either of which can just use an index and be done with it - although
of course the more indexes there are, the slower simple
addition/removal operations will be, as well as increasing contention.
So sure, there's a protocol efficiency gain to be made here, but it's
important to consider the impact it'll have on servers, as well as
the impact on the security model.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
