[Standards] XEP-0045: direct invitations
Wouldn't you have the same problems with the actual messages that come from the MUC, i.e., they would be blocked by the client? I am not familiar with how block list work, but no matter where the invite comes from, once the client joined the meeting, the client will need to unblock the room. Would it not be easier to send a set iq to the client telling it to expect an invite from a MUC of the specified name. The client, having you on its contact list, would get the IQ. The new client would then unblock the MUC JID for some time (1 minute), reply with result IQ indicating success, and then process the invite as normal. The old clients will fail as before, but the inviting client will get an error IQ from the old client that it does not recognize the set, and will be able to revert to the social technique. Just a though... Toly Michal 'vorner' Vaner wrote: Hello On Fri, Jul 20, 2007 at 09:04:11AM +0100, Ian Paterson wrote: Peter Saint-Andre wrote: Michal 'vorner' Vaner wrote: So just one last question - how does a client know, when to send direct or usual presence? Sends both? Perhaps. Inviting people to rooms happens infrequently enough that it's not a bandwidth issue. But it may be confusing for the receiving client to get two invitations. Then do we need some logic for checking duplicate invitations? Ick. This is definitely Ick. But the other options (Aunt Tillie decides or hardcode @gmail.com) are even worse. If the direct was not invite/, but something else, like directinvite/ - old clients that do not know it would ignore them as they do not know them (anyway, they would try to connect to the inviter, not the muc, by the from address). And client that knows would receive it, show it to user and while waiting, if the user accepts, the normal one could come, so it would take its' data as relevant instead of the direct ones. So old client without block would receive the normal one and throw the direct one away, new one without block receives both and acts according to the normal, new one with block gets only direct and old one with block is out of luck anyway no matter what we do. Right? It seems like that might work. :) /psa
Re: [Standards] XEP-0045: direct invitations
Peter Saint-Andre wrote: Michal 'vorner' Vaner wrote: So just one last question - how does a client know, when to send direct or usual presence? Sends both? Perhaps. Inviting people to rooms happens infrequently enough that it's not a bandwidth issue. But it may be confusing for the receiving client to get two invitations. Then do we need some logic for checking duplicate invitations? Ick. This is definitely Ick. But the other options (Aunt Tillie decides or hardcode @gmail.com) are even worse. I understand why Google Talk has this policy, so I'm not going to argue them out of it. But it does introduce complications. *Maybe* we need to consider addressing the valid reasons that Google Talk feels it needs this policy, rather than handling the symptoms of the policy? Can we solve the real problem? i.e. can we create enough anti-spim protocols and/or infrastructure to make Google (and everyone else) confident enough to relax this policy? - Ian
Re: [Standards] XEP-0045: direct invitations
Ian Paterson wrote: *Maybe* we need to consider addressing the valid reasons that Google Talk feels it needs this policy, rather than handling the symptoms of the policy? Can we solve the real problem? i.e. can we create enough anti-spim protocols and/or infrastructure to make Google (and everyone else) confident enough to relax this policy? Yes, let's look at the root causes. https://stpeter.im/?p=1989 talks about this a bit. Basically, it is quite easy to repeatedly join a chatroom and spam the room. You can even do this with a normal client, no need to automate the process. Spam the room until you get banned. Either move on to another room or create a new account and go back to spamming the room. We've seen this on some of the open MUC services already. I think we need a way to identify MUC joiners/occupants by IP address. But RFC 3920 forbids leaking of IP addresses (quite rightly). So we need a way to anonymize/obscure IP addresses. We could use HMAC-SHA256 but each Jabber server would have its own secret, so that would not guard against people/bots who create accounts on multiple domains. A better approach might be cryptopan: http://www.cc.gatech.edu/computing/Networking/projects/cryptopan/ I may write up a proposal along these lines soon. This does not necessarily address the concern that Google Talk has (I'm not sure what that is), but it would solve some of the problems we're seeing. And it would implemented server-side, so doesn't depend on updates to millions of clients (which couldn't be trusted anyway). Thoughts? /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] XEP-0045: direct invitations
Currently it is not possible to send room invitations directly from one person to another. That is, the invitation must go through the room. See: http://www.xmpp.org/extensions/xep-0045.html#invite This can cause problems with deployments that use privacy lists to block communications from entities that are not in your roster. In order to solve this issue, we need to modify the invite/ element in XEP-0045. Currently the flow is like this: 1. Occupant Sends an Invitation by Way of Room message from='[EMAIL PROTECTED]/desktop' to='[EMAIL PROTECTED]' x xmlns='http://jabber.org/protocol/muc#user' invite to='[EMAIL PROTECTED]'/ /x /message 2. Room Sends Invitation to Invitee on Behalf of Occupant message from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' x xmlns='http://jabber.org/protocol/muc#user' invite from='[EMAIL PROTECTED]'/ /x /message Notice that the invitation comes from the room and there is no way for the invitee to know which room to join other than by checking the 'from' address on the message/. For direct invitations we'd need to include a 'room' attribute, like so: message from='[EMAIL PROTECTED]/desktop' to='[EMAIL PROTECTED]' x xmlns='http://jabber.org/protocol/muc#user' invite room='[EMAIL PROTECTED]'/ /x /message Yes, this is basically just like jabber:x:conference. Hmm. Everything that's old is new again. BTW, I think the room itself should include the 'room' attribute too. That way you can just check the room attribute, not the 'from' address of the message/. Naturally, you could still send invitations through the room, but the ability to invite directly enables us to work around the privacy lists blocking issue. Thoughts? Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: direct invitations
Michal 'vorner' Vaner wrote: Hello On Thu, Jul 19, 2007 at 02:27:51PM -0600, Peter Saint-Andre wrote: Currently it is not possible to send room invitations directly from one person to another. That is, the invitation must go through the room. See: http://www.xmpp.org/extensions/xep-0045.html#invite This can cause problems with deployments that use privacy lists to block communications from entities that are not in your roster. In order to solve this issue, we need to modify the invite/ element in XEP-0045. Currently the flow is like this: Hm, just a question - how do you handle the tricks like adding the user to member list, adding a password to the invitation (that could have change since the occupant entered, so he does not know the new one, or his client does not) or room that does not allow you to send invites? You don't. I do not say the privacy lists are not a problem, I just thing this is an unhappy solution which brings many new problems. Privacy lists are great. Not being able to invite your friends to a groupchat room is not great. But of course there is always the social solution: Hey Michal, join the chat room [EMAIL PROTECTED], what client are you using? I think in your client you need to select File Join Chat and then type foo for the room name, chat.example.com for the server, and you can type anything you want for the nick. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: direct invitations
Hello, On Thu, Jul 19, 2007 at 03:34:25PM -0600, Peter Saint-Andre wrote: Michal 'vorner' Vaner wrote: Hello On Thu, Jul 19, 2007 at 02:27:51PM -0600, Peter Saint-Andre wrote: Currently it is not possible to send room invitations directly from one person to another. That is, the invitation must go through the room. See: http://www.xmpp.org/extensions/xep-0045.html#invite This can cause problems with deployments that use privacy lists to block communications from entities that are not in your roster. In order to solve this issue, we need to modify the invite/ element in XEP-0045. Currently the flow is like this: Hm, just a question - how do you handle the tricks like adding the user to member list, adding a password to the invitation (that could have change since the occupant entered, so he does not know the new one, or his client does not) or room that does not allow you to send invites? You don't. Wouldn't it be nice to be able to do something about it? For example send an iq to the MUC server to prepare the stanza for you and you just sent it out? Like ask it for an advice (optional)? iq to='[EMAIL PROTECTED]' type='get' advice xmlns='…' invite … /invite /advice /iq iq from='[EMAIL PROTECTED]' type='result' advice xmlns='…' invite … /invite /advice /iq You do not send client from sending an invitation, but as you said, you can say it to the other person the social way. This allows the other tricks at last. -- This message has optimized support for formating. Please choose green font and black background so it looks like it should. Michal 'vorner' Vaner pgpdz4xFg2NKZ.pgp Description: PGP signature
Re: [Standards] XEP-0045: direct invitations
Michal 'vorner' Vaner wrote: Hello, On Thu, Jul 19, 2007 at 03:34:25PM -0600, Peter Saint-Andre wrote: Michal 'vorner' Vaner wrote: Hello On Thu, Jul 19, 2007 at 02:27:51PM -0600, Peter Saint-Andre wrote: Currently it is not possible to send room invitations directly from one person to another. That is, the invitation must go through the room. See: http://www.xmpp.org/extensions/xep-0045.html#invite This can cause problems with deployments that use privacy lists to block communications from entities that are not in your roster. In order to solve this issue, we need to modify the invite/ element in XEP-0045. Currently the flow is like this: Hm, just a question - how do you handle the tricks like adding the user to member list, adding a password to the invitation (that could have change since the occupant entered, so he does not know the new one, or his client does not) or room that does not allow you to send invites? You don't. Wouldn't it be nice to be able to do something about it? Maybe. One solution is to say that if you send a direct invitation, you get reduced functionality. Sorry. BTW, I don't know of *any* password-protected rooms. Typically if we want to restrict access, we make the room members-only. But that's rare enough that the social solution tends to work (ping the room owner directly). For example send an iq to the MUC server to prepare the stanza for you and you just sent it out? Like ask it for an advice (optional)? Yes, we could define that it would be used precisely 3 times in the history of mankind. :) iq to='[EMAIL PROTECTED]' type='get' advice xmlns='…' invite … /invite /advice /iq iq from='[EMAIL PROTECTED]' type='result' advice xmlns='…' invite … /invite /advice /iq Sure, that's possible. If people really want that, we could define it. Understand that the main driver here is Google Talk. You can't receive messages in Google Talk unless you add the sender of the incoming message to your roster first. That doesn't work with random chat rooms, with the result that Google Talk users can't join chatrooms on the Jabber network. That's a shame. Direct invitations would enable us to work around that. Peter smime.p7s Description: S/MIME Cryptographic Signature
