[Standards] Proposed XMPP Extension: Stanza Repeaters

Pedro Melo melo at simplicidade.org
Tue Mar 18 12:59:24 UTC 2008


On Mar 18, 2008, at 2:18 AM, Peter Saint-Andre wrote:
> Pedro Melo wrote:
>> On Mar 17, 2008, at 4:28 PM, XMPP Extensions Editor wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>> Title: Stanza Repeaters
>>> Abstract: This specification defines an XMPP extension that enables
>>> optimization of interdomain traffic that is intended for delivery to
>>> multiple recipients, using the concept of a stanza repeater.
>>> URL: http://www.xmpp.org/extensions/inbox/repeaters.html
>>> The XMPP Council will decide at its next meeting whether to accept
>>> this proposal as an official XEP.
>> I'm sure there is some security implication that I'm missing, but  
>> why do
>> we need to make the hash of the repeater ID so tightly coupled  
>> with the
>> recipients list?
> We don't need to. That was one suggested approach.
>> I understand the need of keeping the ID unique but I fail to see what
>> else is gained by this complexity.
>> On the other hand, the use of an ID that doesn't change each time we
>> update the recipients list would be easier to work it in the  
>> presence of
>> multiple senders.
> Probably, yes.
>> Regarding the use of repeaters for <presence>, maybe we should  
>> just use
>> the domain of the users as a virtual repeater, like PEP is a virtual
>> pubsub at the users domain. This was suggested two years ago, btw.
> It was? I don't remember that.
> There may be privacy concerns related to presence repeaters (my home
> server should have control over how my presence is distributed -- it's
> not acceptable for my server to just send my presence off to another
> server for it to distribute however it pleases). In any case I  
> don't see
> presence as the key driver for repeaters -- IMHO, MUC and pubsub  
> are of
> greater interest.

This is a misconception in my opinion. The notion that you control  
your presence distribution after the stanza leaves your trusted server.

You just don't control how your presence will be distributed by  
remote servers, you assume that they will do the right thing. And  
most if not all will.

But nothing prevents a remote server from channeling all incoming  
presence to some external component for further study. I'll bet that  
this practice will become even more widespread as statistical anti- 
spim tools arrive...

But this is getting off-topic a bit. Yes, pubsub and muc are the big  
winners for this, and again, I think we should drop the complex hash  
generation, or at least drop the coupling with the recipients list.

>> The roster at the remote host could be used as the distribution  
>> list, no
>> need for costly updates. Just reverse-query the roster if your DB  
>> system
>> provides that (easy for SQL-based rosters, not as simple for LDAP- 
>> based
>> ones).
> Rosters can get out of sync. The roster at the remote host is not
> necessarily to be trusted.

Yes, true. But keeping the rosters in sync might be a worthy goal,  
probably for a new XEP. A small extension to the initial probe, with  
the current status... Anyway, off-topic in this thread.

Best regards,
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org

More information about the Standards mailing list