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
The importance of leaking a human-typed sentence may usually be bigger than the simple "is online".
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?
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?
The biggest issue with simply directing presence stanzas to the remote domain and then letting that fan it out by itself (rather than using something like the repeaters here) is that it means privacy lists (or anything which works in a similar way to them, i.e. being able to selectively stop presence going to roster items without changing your subscription) stop working at entirely, and I can't really see a way around that without using a concept such as repeaters where you are specifically telling the remote server who you want it fanned out to.
Of course an evil server could still forward it to people you have not told it to but that will always be so as as you say its out of your hands, but at least with repeaters non-evil servers actually have an idea of where you want the presence stanzas to go.
Richard
