[Standards] Proposed XMPP Extension: Stanza Repeaters
stpeter at stpeter.im
Tue Mar 18 02:18:22 UTC 2008
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.
> 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
> 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
Rosters can get out of sync. The roster at the remote host is not
necessarily to be trusted.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards