[Standards] Council on Stanza Repeaters without Multicast

[Philipp Hancke]

Dave Cridland wrote:
[...]
> Sure, I think everyone here does. I sincerely hope so, anyway - we will 
> have significant impact here in the future.

We agree that messages should be sent only once per link?

[...]
> You do, however, raise a very interesting point - you've said that in 
> the current MUC case, there's no gain in using repeaters.

There are situations where there is no gain:
* user joins
* muc service modifies repeater
* users leaves
* muc service modifies repeater
two repeater modifications for nothing. Separating the repeater
modification from the actual protocol steps is something I dislike
about repeaters.

[...]
> The result of solving them would be that PubSub would almost 
> spontaneously grow directed acyclic routing, and this would be virtually 
> transparent to clients, and to a large degree, transparent to servers. 
> Note that this is more powerful than repeaters, as well as simpler.

As long as the local server (slave) rewrites the address to that of the
"master". Otherwise you have a usability problem ("but I want to join
jdev at conference.jabber.org, not 12431AFA at myserver"). Make it transparent
to the client.

> Again, we gain a lot from this. It's a simple design, and one that can 
> potentially get us some resilience to failure, which is nice. And again, 
> not my design, and not a particularly new suggestion.

IRC is there, you can't really come up with something brilliant new
that can't be interpreted as "irc does it almost the same" ;-)

> If we solve scalability in MUC and PubSub - and I think we can *without* 
> repeaters, and I think that repeaters are not well understood, and may 
> cause greater harm than good - then I think this is way beyond good 
> enough. I believe that for both MUC and PubSub, using a slave entity 
> which passes on subscriptions to a master entity, and manages 

may pass on for "open" nodes ;-)

> redistribution backwards, will yield equal or high efficiency, with much 
> simpler implementation, fewer security issues (in implementation or 
> design), and will give us all the benefits of a tree-based heirarchical 
> distribution without breaking any trust models.

You can apply the same master-slave design to presence.
The recipient list modification operations will be different for the
three use-cases, but the plan stays the same.

> I don't think we'll have a problem scalaing presence, because I don't 
> think it really needs to be scaled - it's neither low-hanging fruit, nor 

Buy two, get one free.

[...]
> Not least of which is that, if this went ahead, we'd probably feel under 
> some obligation to use it in a MUC and/or PubSub scalability effort, and 
> I happen to think it's entirely the wrong design for that - there are 
> much cleaner designs.

I am going to curse you at night (in binary xmpp!) if I have to
reactivate our old master/slave rooms and map them to XMPP!


p