[Standards] Proposed XMPP Extension: Stanza Repeaters
dave at cridland.net
Thu Mar 20 09:31:41 UTC 2008
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
> | domain and then letting that fan it out by itself (rather than
> | something like the repeaters here) is that it means privacy lists
> | anything which works in a similar way to them, i.e. being able to
> | selectively stop presence going to roster items without changing
> | subscription) stop working at entirely, and I can't really see a
> | around that without using a concept such as repeaters where you
> | specifically telling the remote server who you want it fanned out
> It's a very XMPP-as-it-is point of view, but from an outsider's
> 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
> towards my non-friend to let him know that I no longer intend to
> him presence? Why do I asymmetrically keep on accepting his
> 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
> | hands, but at least with repeaters non-evil servers actually have
> | 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
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 Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards