[Standards] Proposed XMPP Extension: Stanza Repeaters

Philipp Hancke fippo at goodadvice.pages.de
Tue Mar 18 15:31:03 UTC 2008

Peter Saint-Andre wrote:
>> 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.

Did you reread the smart unicast (I still prefer version 0.0.3 version
- http://smarticast.psyced.org/jep-smart-presence.html, but the 0.0.4
version in the editors inbox has it's merits, too) and
address-lists (http://www.xmpp.org/extensions/inbox/address-lists.html)
proposals and the reasons why they were rejected by the council?

> There may be privacy concerns related to presence repeaters (my home

The importance of leaking a human-typed sentence may usually be bigger
than the simple "is online".

> 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

Your server loses control once it sends to the remote domain.
Do you think it makes a difference for the evil server if you send the
stanza once or repeat it multiple times?

 > In any case I don't see presence as the key driver for repeaters --
 > IMHO, MUC and pubsub are of greater interest.

All them of the have a group concept. And - as Matthias pointed out -
the number of presence stanzas exceeds the number of message stanzas:

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

How is keeping the roster in sync more difficult than keeping the
list at the repeater in sync?
The advantage in using the roster (or a subset thereof) is that the
repeaters server knows that the recipient intends to receive the
message. This is a key hint for trusting the sender.
How is your new proposal going to work in 'the public network'?
What else could the trust of a repeater for a remote entity be based

joe: 0033 did not turn out to work better than I expected :-)


More information about the Standards mailing list