Michal 'vorner' Vaner typeth: | I'm strictly against this kind of relying. I must trust my server and | the recipient's server. But I do not have to trust any other server and | let it know I'm sending something to some other server, even if I sent | the same think to someone on this server too.
It's fine to be strictly against it, if you're running a standalone server and do not trust anybody. If you trust a few people, than developing a trust metric that allows a heterogeneous network to build up multicast trees is still a tricky endeavour. But there is also a totally trivial scenario. If all servers are run by a single company, the trust issue is inexistent. Considering that the current repeaters proposal already slashes down presence traffic on a single route to its half (see fippo's stats), employing true Multicast (with a big M to avoid confusion with 0033) should bring about another 50% optimization on the network as a whole (wild guess). Considering that presence makes up >70% of stanzas on XMPP (http://mailman.jabber.org/pipermail/standards-jig/2006-May/011158.html) reducing that figure to a third or fourth means to reduce overall XMPP to a half of what it is currently. And I haven't even started considering MUC and PubSub multicasting. | ? How to make sure there are no cycles. "Multicast by repeaters" is a top-down approach where the original sender decides whom to put in charge of what. There are no cycles by design. Making intentional use of cycles has potential, but I presume that would be beyond what is good and useful for XMPP, not talking about the huge effort adapting the protocol for that.
