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?
http://logs.jabber.org/[EMAIL PROTECTED]/2006-06-14.html
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:
http://mail.jabber.org/pipermail/standards/2006-May/011158.html
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
upon?
joe: 0033 did not turn out to work better than I expected :-)
p
