[Standards] Proposed XMPP Extension: Stanza Repeaters

Peter Saint-Andre stpeter at stpeter.im
Tue Mar 18 02:18:22 UTC 2008

Pedro Melo wrote:
> Hi,
> 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.

> 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.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080317/cd301b58/attachment.bin>

More information about the Standards mailing list