Hi,
On Mar 18, 2008, at 6:03 PM, Richard Dobson wrote:
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.
The repeaters concept doesn't solve the privacy list interactions
either.
If multiple senders have different privacy lists, how is the repeater
to know that.
But personally, I'm OK with that... I don't believe privacy lists and
multicast-style delivery of presences will ever work together
efficiently.
I won't be outraged in anyway if a future version of this proto-xep
states that "this concept bypasses all privacy list processing,
except if they target the stanza repeater JID itself".
But getting back to presence-fan-out on the remote side:
1. I would bet that most users don't use privacy lists so on the
general case, this would be a welcome solution;
2. if a privacy list is active, bypass this optimization.
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.
I like the concept of remote fan-out of messages. Both for pubsub and
muc use cases. And apart from the SHA1-based-on-destination-list
thing, I like this XEP.
But I think we have better solutions for presence.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
