Re: [Standards] Fwd: Meeting minutes 2010-02-15
Peter Saint-Andre wrote: [...] 4. This indeed is the worst of IRC brought to XMPP. Nice! What's needed to bring the *best* of IRC to XMPP? Does the co-authors welcome from http://mail.jabber.org/pipermail/council/2010-February/002757.html also apply to old IRC folks? philipp
Re: [Standards] Fwd: Meeting minutes 2010-02-15
Dave Cridland typeth: | Let me also clarify - if we could send IM presence once over a link | and have fan-out controlled by a foreign domain, I'd be happy with | it. But I don't think that's a practical option, given that it | requires greater trust between domains, and prevents various other | forms of control. FWIW, the same applies to PEP versus general | PubSub, I think, and these are the same protoclo, but with different | controls. It's trivial to modify a server in such a way that it will report all presence of all peers of its users to an administrator or to modify a server in such a way that it reports probes from wannabe-invisible users. So you already *are* trusting other servers. Having the recipient server manage subscriptions instead of you remote controlling them is no new security issue. The security issue is elsewhere. In order to deliver presence to the right people the server must additionally store subscription acknowledgments from the peers (presence type=subscribed) and not let the local user or client infiltrate other people's presence slaves (in a multicast master/slave architecture) by fiddling with subscription state=to. Any server implementor who adds multicast to her server must also provide for this subscription safety mechanism, including silently removing a recipient, if this is what the peer expects. 'stanza repeaters' seems to be the right kind of approach here with all the special requirements XMPP presence has. - _// Carlo v. Loesch _// http://symlynX.com/
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On 2/24/10 2:31 PM, Philipp Hancke wrote: Peter Saint-Andre wrote: [...] 4. This indeed is the worst of IRC brought to XMPP. Nice! What's needed to bring the *best* of IRC to XMPP? Does the co-authors welcome from http://mail.jabber.org/pipermail/council/2010-February/002757.html also apply to old IRC folks? Sure, why not? Co-authors, competing proposals, etc. I probably won't have time to work on distributed MUC because of other responsibilities, so I'm looking for people to carry the idea forward. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Fwd: Meeting minutes 2010-02-15
Dave Cridland wrote: [...] 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? Not for presence as a whole, no. For chatrooms, I think it's worth looking at, especially if we can gain some levels of resilience out of it as well. Sorry, but by trying to combine two arguments, you are muddying the waters and confusing two cases which I don't think are the same. Let me also clarify - if we could send IM presence once over a link and have fan-out controlled by a foreign domain, I'd be happy with it. But I don't think that's a practical option, given that it requires greater trust between domains, and prevents various other forms of control. No. IIRC this is explained in detail in draft-ietf-simple-view-sharing-02 It does require a quite challenging protocol for subgroup managment. But this is no different from MUC actually. [...] No doubt. But those properties also mean that the traffic pattern is similar to a SPIM or flood attack, making those undistinguishable. Okay, I can go along with this, but I also suspect it's again much more of an issue with chatroom (and PubSub) traffic than it is with general presence (and PEP), which in general terms has an established relationship involved as well. Luckily, this is very similar division to the trust issue - fan-out of chatrooms and pubsub nodes is, I think a lot more likely to be practical without any changes to the trust model we have. Getting experience with that and postpone presence is fine with me. 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. I don't think that's the only goal. I think shared state to provide resilience is useful and important too, but I think we can require a formalized trust relationship there. Resilence makes sense for some use-cases, but there are some security implications - such as people forcing your slave room to go to split mode and then harassing users. 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 ;-) Sure, from some perspectives. I just think that thanks to various other features of the architecture, doing this blindly will lead to problems. Of course. Doing that is nearly impossible when there is more than one domain pair per s2s link. But I'm pretty sure you understand my perspective on this - you pointed out in private IM that the moderator which uses a slave needs different information from the master than the average user - things like jid disclosure, etc, may indeed mean that a simple master/slave isn't suitable for all cases, and we'll need to consider that carefully. That was actually just one of many examples why distributed MUC is every bit as painful as presence. philipp
Re: [Standards] Fwd: Meeting minutes 2010-02-15
Kevin Smith wrote: [...] 8) Distributed MUC http://xmpp.org/extensions/inbox/distributedmuc.html Accept as XEP? Kev offers to send around a mail about an alternative approach to possibly update this proposal with. Kev, Matt and Ralph had no objections to publishing as-is, further discussion about approaches to happen on-list. 1. This proposal has unacceptable liabilites (sync issues). See http://logs.jabber.org/coun...@conference.jabber.org/2006-06-14.html at 15:28 2. Compression makes multicast structures unnecessary. Jack may remember the argumentation... 15:28:19 in the same meeting log. 3. This proposal does not disprove current experience - 15:30:12 in the meeting log. 4. This indeed is the worst of IRC brought to XMPP. Unfortunately, I could not find the minutes of that meeting. philipp
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On 2/18/10 6:44 AM, Philipp Hancke wrote: Kevin Smith wrote: [...] 8) Distributed MUC http://xmpp.org/extensions/inbox/distributedmuc.html Accept as XEP? Kev offers to send around a mail about an alternative approach to possibly update this proposal with. Kev, Matt and Ralph had no objections to publishing as-is, further discussion about approaches to happen on-list. 1. This proposal has unacceptable liabilites (sync issues). See http://logs.jabber.org/coun...@conference.jabber.org/2006-06-14.html at 15:28 Are you being facetious or serious? 2. Compression makes multicast structures unnecessary. It does? A lot of people are skeptical about the argument oh don't worry about how verbose this is, compression will solve the problem. 3. This proposal does not disprove current experience - 15:30:12 in the meeting log. 4. This indeed is the worst of IRC brought to XMPP. Nice! What's needed to bring the *best* of IRC to XMPP? Unfortunately, I could not find the minutes of that meeting. Kev sent out minutes. It's the logs that are non-functional at the moment. The jabber.org admin team needs to fix that, or the XSF insfrastructure team needs to enable logging at muc.xmpp.org. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Fwd: Meeting minutes 2010-02-15
Peter Saint-Andre wrote: 2. Compression makes multicast structures unnecessary. It does? A lot of people are skeptical about the argument oh don't worry about how verbose this is, compression will solve the problem. Indeed. Does anyone have statistics? I think we should rely on statistics to make a decision, no? A lot of people are skeptical is not an argument :P -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On Thu, Feb 18, 2010 at 14:51, Peter Saint-Andre stpe...@stpeter.im wrote: 2. Compression makes multicast structures unnecessary. It does? A lot of people are skeptical about the argument oh don't worry about how verbose this is, compression will solve the problem. Maybe that's true from a C2S bandwidth consumption point of view, but from a server routing mechanism perspective, it makes sense, if not mandatory for scalability. I wouldn't be completely sure about that. 4. This indeed is the worst of IRC brought to XMPP. Nice! What's needed to bring the *best* of IRC to XMPP? At least, by reproducing netsplits, the folks over there would feel confortable like at home. Is this what we need to bring their strength and support to an open federated network? Or else, ther's also the Poezio XMPP client, a console-based software that completely mimics the IRC-styme anonymosity and channels (no one-to-one chat, no presence, no roster, etc.): http://codingteam.net/project/poezio -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On Thu Feb 18 13:44:02 2010, Philipp Hancke wrote: Kevin Smith wrote: [...] 8) Distributed MUC http://xmpp.org/extensions/inbox/distributedmuc.html Accept as XEP? Kev offers to send around a mail about an alternative approach to possibly update this proposal with. Kev, Matt and Ralph had no objections to publishing as-is, further discussion about approaches to happen on-list. 1. This proposal has unacceptable liabilites (sync issues). See http://logs.jabber.org/coun...@conference.jabber.org/2006-06-14.html at 15:28 2. Compression makes multicast structures unnecessary. Jack may remember the argumentation... 15:28:19 in the same meeting log. 3. This proposal does not disprove current experience - 15:30:12 in the meeting log. 4. This indeed is the worst of IRC brought to XMPP. 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. 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 for this proposal - but the distinction of trust delegations means different solutions may apply. 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. 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 placed to find a reasonable solution, and in this case, where trust 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. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On 18.02.2010, at 14:51, Peter Saint-Andre wrote: 2. Compression makes multicast structures unnecessary. It does? A lot of people are skeptical about the argument oh don't worry about how verbose this is, compression will solve the problem. It doesn't make multicast structures unnecessary. Using multicast structures you can avoid to generate/serialize/parse quite some XML stanzas. So you have less volume to compress and at the other side it's less XML to parse. Sure the multicast handling takes some CPU too but that's minimal compared to general purpose compression. Tobias smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On Thu Feb 18 14:47:22 2010, Tobias Markmann wrote: On 18.02.2010, at 14:51, Peter Saint-Andre wrote: 2. Compression makes multicast structures unnecessary. It does? A lot of people are skeptical about the argument oh don't worry about how verbose this is, compression will solve the problem. It doesn't make multicast structures unnecessary. Using multicast structures you can avoid to generate/serialize/parse quite some XML stanzas. So you have less volume to compress and at the other side it's less XML to parse. Sure the multicast handling takes some CPU too but that's minimal compared to general purpose compression. We're not seeing any bottleneck on CPU at this time on our deployments, I have to say. I do, personally, have a bottleneck on implementing stuff, though... :-) Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On Thu, Feb 18, 2010 at 11:24 AM, Kevin Smith ke...@kismith.co.uk wrote: 2) Pubsub. Votes outstanding from Dave, Matt, Ralph and Remko. Discussion about iq stanzas for delivery, how they don't give guaranteed delivery, and how XEP-0198 is a solution to the guaranteed delivery problem. Ralph -1 on the changes because of the iq issues. There is no log of the discussion yet, isn't it? If so does anybody has the log saved on the disk? I fear there is some misconception about the use cases where iq/s are needed (basically: it's not about reliability, but about having an immediate ack of delivery and XEP 198 does not solve this). -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Fwd: Meeting minutes 2010-02-15
On Thu, Feb 18, 2010 at 4:29 PM, Fabio Forno fabio.fo...@gmail.com wrote: On Thu, Feb 18, 2010 at 11:24 AM, Kevin Smith ke...@kismith.co.uk wrote: 2) Pubsub. Votes outstanding from Dave, Matt, Ralph and Remko. Discussion about iq stanzas for delivery, how they don't give guaranteed delivery, and how XEP-0198 is a solution to the guaranteed delivery problem. Ralph -1 on the changes because of the iq issues. There is no log of the discussion yet, isn't it? If so does anybody has the log saved on the disk? I fear there is some misconception about the use cases where iq/s are needed (basically: it's not about reliability, but about having an immediate ack of delivery and XEP 198 does not solve this). There was, but only to the (publicly logged) council list. I have now remedied! /K
