[Standards] Proposed XMPP Extension: Stanza Repeaters

Pedro Melo melo at simplicidade.org
Tue Mar 18 23:25:06 UTC 2008


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/council@conference.jabber.org/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  

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  

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: melo at simplicidade.org

More information about the Standards mailing list