[Standards] Proposed XMPP Extension: Stanza Repeaters
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
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
> 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