Dave Cridland wrote:
Ah, gotcha, you're referring to smart presence distribution, and ironically comparing the reaction of the council. How witty.
;-)
1) Without trundling back to the threads to remind myself what the sync liabilities are, I suspect this refers to assymetric rosters, which have remained a problem (and the current resolution is to respond to probes on a case-by-case basis to re-symmetrize - if that's a word - the rosters, which'd entirely break with "smart" presence distribution). Distributed MUC is specifically designed (one hopes) to handle synchronization of relevant state data, and is allowed (specifically) to do all manner of weird things to mitigate the liabilities therein.
Simple chatrooms actually do not need shared state and control. All you need is smarter routing.
2) S2S compression remains our best solution to the matter of inter-domain presence bandwidth, but I'd note we have nothing like the issue that other protocols have. I do have some research I need to carry out on this, but I currently lack the time. In any case, I've read this proposal as an attempt to tackle resilience rather than efficiency as the primary goal, so I'm not convinced this argument is worth revisiting
In http://mail.jabber.org/pipermail/muc/2010-February/000144.html you say "Another distinction between the two approaches is what the core aims are - in PSA-style, it's to provide resilience between servers, whereas in KD-style, it's largely to reduce redundant message traffic from being repeated redundantly repeated." So you changed your mind already and think reducing redundant redundancy is no longer worth revisiting?
for this proposal - but the distinction of trust delegations means different solutions may apply.
One fabulous side effect of "smart" distribution techniques, where you let the receiving server know who's to receive things from somewhere is the amazing way how this protects you from SPIM. If the protocol is all built on unicast, there is hardly a way to detect SPIM. If a message has to go to all recipients of a certain context, be it a distributed chatroom or a person's presence, multicast SPIM leads to unsubscription from the "infected" source whereas unicast SPIM is obviously illegal and doesn't need to be delivered to the recipient. So having proper multicast structures actually strengthens trust and solves not only the effeciency issue.
3) I'm not sure exactly what Matt Miller intended to mean at this point, but I suspect it relates to Peter's suggestion to get hard data. See above - on the subject of inter-domain presence (and, for that matter, inter-domain MUC traffic), I'm intending doing some measurements when I can on actual field data, although my measurements based on more theoretical cases seemed to hold up, and the observation that the bulk of bandwidth consumption is highly self-similar, and thus should compress well, is still valid.
No doubt. But those properties also mean that the traffic pattern is similar to a SPIM or flood attack, making those undistinguishable.
4) I understand this proposal is aimed at bringing simple resilience for chatrooms across heterogeneous XMPP networks, very much like IRC. I'd be interested in seeing how you'd do it. I do think you're much better
lynX will post to muc@ about that.
placed to find a reasonable solution, and in this case, where trust
Unfortunately, there is no single "reasonable solution". The only common pattern is "at most once per link".
relationships are explicitly configured, I'd expect the kinds of solutions you're likely to propose to be more acceptable to us annoying folk in the XMPP world.
Beware, I still consider sending stanzas without a 'to' attribute the most elegant approach ;-) philipp
