[Standards] Proposed XMPP Extension: Stanza Repeaters

Dave Cridland 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  
> 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:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list