Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Peter Saint-Andre wrote: In the Council meeting just ended, Kevin Smith suggested that we might want to bring back the old jabber:x:conference namespace: message from='[EMAIL PROTECTED]/desktop' to='[EMAIL PROTECTED]' body You have been invited to the [EMAIL PROTECTED] room. /body x jid='[EMAIL PROTECTED]' xmlns='jabber:x:conference'/ /message Older clients already support that, so the suggestion seems reasonable to me. Seeing no objections, I've updated the proposal to use jabber:x:conference, see version 0.0.5: http://www.xmpp.org/extensions/inbox/direct-invitations.html /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Am 20.08.2008 um 01:01 schrieb Peter Saint-Andre: message from='[EMAIL PROTECTED]/desktop' to='[EMAIL PROTECTED]' x xmlns='http://jabber.org/protocol/muc#user' invite to='[EMAIL PROTECTED]' id='some-long-id-here'/ ^^ /x /message How about this instead? message from='[EMAIL PROTECTED]/desktop' to='[EMAIL PROTECTED]' x xmlns='http://jabber.org/protocol/muc#user' invite to='[EMAIL PROTECTED]' idsome_id (doesn't even need to be long)/id /invite /x /message Are you sure current implementations will not route that? For the clients, it doesn't matter if they ignore it, because that means they only support mediated invitations and not direct invitations. Only new clients will implement directed invitiations, and if we make the ID a part of that, they will implement it. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Mon, 18 Aug 2008 02:52:50 +0100 Matthew Wild [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. I'm leaning toward crossing that bridge when we come to it. My reason for bringing invite-only rooms was not to suggest they should be done, just that this protocol takes away the possibility to implement them (and it happens to be something I was thinking about a couple of weeks ago). We don't have invite-only rooms, but IRC doesn't have members-only rooms. I can't think of many cases an invite-only room would be called for, unless it is an admin doing the inviting, in which case it is easy to add invitees to the member list. That, or just use a password, as exampled in this XEP. But this must apparently by written by the inviting user. Matthew. -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Jonathan Schleifer wrote: Am 18.08.2008 um 22:52 schrieb Peter Saint-Andre: If a client receives multiple invitations to the same room (e.g., a mediated invitation as defined in XEP-0045 and a direct invitation as defined here), the client SHOULD present only one of the invitations to a human user. If a client receives an invitation to a room in which the user is already an occupant, the client SHOULD silently discard the invitation. What if we receive an invitation 5 minutes later? Maybe we clicked no and changed our mind and now want to join the room, thus we ask the inviter to invite us again. It would be discarded then as well. I'd recommend giving any invitation an ID. And if you receive an invitation with an ID you already got, ignore it. That will never give problems then. XEP-0045 doesn't say anything about this and client developers seem to have handled it just fine. But yes we could say something about timeouts, or add an ID to the invitations, or say that the client should match the inviter (both mediated and direct invitations will make it clear who invites you to the room). /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Peter Saint-Andre [EMAIL PROTECTED] wrote: XEP-0045 doesn't say anything about this and client developers seem to have handled it just fine. But yes we could say something about timeouts, or add an ID to the invitations, or say that the client should match the inviter (both mediated and direct invitations will make it clear who invites you to the room). I'm for adding an ID. That seems like the most safe option to me. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Am 18.08.2008 um 04:20 schrieb Peter Saint-Andre: Agreed. Members-only rooms seem much more natural than invite-only rooms, especially because we have authenticated identities. I think an invite-only room would be interesting for continued conversations over MUC. IIRC, ejabberd adds the invited user to the members list when an invitation is sent. This pretty much already makes invite-only possible. - -- Jonathan -BEGIN PGP SIGNATURE- iQIcBAEBAwAGBQJIqUU3AAoJEMtRg9d5cXHkX0YQAKDZKH/w32l/fSVpHhWHTphx TPMC5aTkc21ixFYkOXoAlFIF+r3GzuV9ayiHhF3D63vOBW6LYqfIP53fFc3FKPSk MMBT4CYHvkDE+tPd/glhEFKru1I4/V1clC2z1Mc7W/I5ForbKOuBAHX7qEA5eQ5u 0dUY9UG80sGFEu+v7TkiPRE34u51CFXZNmlJODTlEUQtnX/YeBYMxHrpIxWAFf9+ uL88NZ3IGEiALwgyPLq6rKjmF5Ucnktja/hEIfjOs/8w5tQBR9FsAaSVCStlIaCm D+/ZQO555FY96ushSp9H7/gvFQbQJOKLIrHWCHT1A2EscuvwD9zJjPjW7tYBfwtv kCQSuqVOy6xMO99J/VLcmVn6L5nCYnPum3dwfnqgNBK/mSLYNmcUbycIBA+g1Fq0 xgtW1XZfdNz/MFvtLIZRRZLdjvGlSCm6ecmq71319/rYR6FW2Z225cvwFU12ZB+V T5QkeIwbMXHp1B/nSfRHPRtrytV/EFJpcYlkDYymvoDvTXvnC/evXY4Rwf+HsTdX 0qIk+BI2wAffNz546El9YbT1GGfqYU+hru3qSzqJNAUkkzzqY7pT2o3qxMx1Hjoj KCRjl9uTbLYYDanxyjMqswoMUI9xhb5kArBeUypkB20q7iKun9KN042tkexMeM0b by5anRIb++q5qnhIajep =v7n1 -END PGP SIGNATURE-
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Mon Aug 18 07:14:00 2008, Johansson Olle E wrote: 18 aug 2008 kl. 04.20 skrev Peter Saint-Andre: Agreed. Members-only rooms seem much more natural than invite-only rooms, especially because we have authenticated identities. IRC doesn't have authentication, so they might need some kind of cryptographic invitations, but AFAICS that's overkill for XMPP. How do I know as a MUC administrator that all identities are authenticated properly? Participants may come from several jabber domains, over which I have no administrative insight. Well... You're right in that you can't definitively say a jid is authenticated, as such, if it comes from a foreign domain. However, you can say that on well behaved servers, that jid will have been authenticated on the server, and you *can* authenticate the domain within your local realm. For real authentication, you'd want to use SASL between the client and the MUC service, but if you did this, a rogue server could still intercept the normal MUC messages. So what you need to do is have integrity protected and encrypted messages, which effectively means needing either to establish MUC/XTLS, or else having per-stanza security. These are nice long-term goals, of course, but I don't think they're worth insisting on doing right now. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Jonathan Schleifer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Am 18.08.2008 um 04:20 schrieb Peter Saint-Andre: Agreed. Members-only rooms seem much more natural than invite-only rooms, especially because we have authenticated identities. I think an invite-only room would be interesting for continued conversations over MUC. IIRC, ejabberd adds the invited user to the members list when an invitation is sent. This pretty much already makes invite-only possible. In fact that's a members-only room, as currently defined in the XEP (nothing special about ejabberd there). The joining user doesn't present an invitation, instead the MUC service adds the joining user to the member list when the invitation is sent through the room, and then checks the member list when the person joins. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Peter Saint-Andre [EMAIL PROTECTED] wrote: In fact that's a members-only room, as currently defined in the XEP (nothing special about ejabberd there). The joining user doesn't present an invitation, instead the MUC service adds the joining user to the member list when the invitation is sent through the room, and then checks the member list when the person joins. Exactly that was my point. We already have invite-only, sort of :). But this will fail with direct MUC invitations :(. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Jonathan Schleifer wrote: Peter Saint-Andre [EMAIL PROTECTED] wrote: In fact that's a members-only room, as currently defined in the XEP (nothing special about ejabberd there). The joining user doesn't present an invitation, instead the MUC service adds the joining user to the member list when the invitation is sent through the room, and then checks the member list when the person joins. Exactly that was my point. We already have invite-only, sort of :). But this will fail with direct MUC invitations :(. Here are the options: 1. use mediated invitation, chatrooms fails for people with privacy lists (and all Google Talk users) 2. use direct invitation, chatroom join fails only for members-only rooms (if room owner/admin is too lazy to add the invitee to the member list first) 2a. define fancy protocol flow for handling members-only rooms I prefer (2) and it remains to be seen if (2a) is needed. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Dave Cridland wrote: For real authentication, you'd want to use SASL between the client and the MUC service, but if you did this, a rogue server could still intercept the normal MUC messages. So what you need to do is have integrity protected and encrypted messages, which effectively means needing either to establish MUC/XTLS Yes I was thinking about that over the weekend. :) These are nice long-term goals, of course, but I don't think they're worth insisting on doing right now. Agreed. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Another idea would be to send both, directed and via the server. We'd just need to find a way to only display that once. Maybe give the invitation an ID? That way, the invited user will be added to the members list AND be able to join, even if there's a privacy list blockig the invitation from the server. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Jonathan Schleifer wrote: Another idea would be to send both, directed and via the server. We'd just need to find a way to only display that once. Maybe give the invitation an ID? That way, the invited user will be added to the members list AND be able to join, even if there's a privacy list blockig the invitation from the server. Right. They are different protocols. If the client receives a direct invitation to the room and a mediated invitation to the room, it pays attention to only one of them and joins. They may arrive in any order so a client needs to be able to handle that. How do clients now handle receipt of two invitations (both mediated)? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Thu Aug 14 19:03:24 2008, Matthew Wild wrote: IRC has the concept of invitation-only rooms. Although this isn't implemented in any MUC server that I know of, today's protocol leaves the option for implementation open, while this one doesn't. Why not do what we discussed in ages past? Leaving off the domains to make my typing less - and because I can't spell shakespeare: 1) Crone requests an invitation ticket from Dark Cave: iq from='crone1' to='[EMAIL PROTECTED]' type='get' invite xmlns='...' tohecate/to /invite /iq 2) Dark Cave returns one. iq from='[EMAIL PROTECTED]' to='crone1' type='result' invite xmlns='...' tohecate/to fromcrone1/from ticket[hash output, maybe HMAC]/ticket timestamp[Timestamp]/timestamp /invite /iq 3) Crone1 now sends this invitation to Hecate - privacy lists are still okay (I can't be bothered typing, so I'll leave out the data itself, but it's simply copied): message from='crone1' to='hecate' invite conference/ to/ from/ timestamp/ ticket/ /invite /message 4) Hecate joins the MUC room using the invitation: presence from='hecate' to='[EMAIL PROTECTED]/hecate' ... invite/ /presence Now the MUC can *at this point* verify that the ticket is valid, and add Hecate to the membership as needs be. Worth noting that this also allows Hecate to know if the invitation was genuine. This doesn't preclude leaving off the ticket fetching part, of course, when not needed or supported by the MUC, so we've a nice easy upgrade path. ANd MUC implementations don't need to store any additional state - in fact, if Hecate doesn't want to join, then that means he won't even be listed as a member. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Peter Saint-Andre [EMAIL PROTECTED] wrote: How do clients now handle receipt of two invitations (both mediated)? They show two invitations and give a message that you are already joined on the second one. We could add a phrase to the directed MUC invitation like The directed invitation should ONLY be processes if no mediated invitation with the same ID has been received yet!. That would pretty much fix it, I guess. Or instead of an ID, we could tell the clients to ignore invitations for rooms for which they already got one in the past 5 minutes or so. Dunno. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Jonathan Schleifer wrote: Peter Saint-Andre [EMAIL PROTECTED] wrote: How do clients now handle receipt of two invitations (both mediated)? They show two invitations and give a message that you are already joined on the second one. We could add a phrase to the directed MUC invitation like The directed invitation should ONLY be processes if no mediated invitation with the same ID has been received yet!. That would pretty much fix it, I guess. Or instead of an ID, we could tell the clients to ignore invitations for rooms for which they already got one in the past 5 minutes or so. Dunno. Done: http://www.xmpp.org/extensions/inbox/direct-invitations.html#impl If a client receives multiple invitations to the same room (e.g., a mediated invitation as defined in XEP-0045 and a direct invitation as defined here), the client SHOULD present only one of the invitations to a human user. If a client receives an invitation to a room in which the user is already an occupant, the client SHOULD silently discard the invitation. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Dave Cridland wrote: On Thu Aug 14 19:03:24 2008, Matthew Wild wrote: IRC has the concept of invitation-only rooms. Although this isn't implemented in any MUC server that I know of, today's protocol leaves the option for implementation open, while this one doesn't. Why not do what we discussed in ages past? snip/ Right. That's what XEP-0235 was until we morphed it into something OAuth-specific, perhaps it makes sense to bring that back under a different number? See here: http://www.xmpp.org/extensions/attic/xep-0235-0.2.html /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Pavel On Sat, 16 Aug 2008 20:08:55 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 15:47:17 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Oh sure, one example is [EMAIL PROTECTED] :) /psa But that means we have some sort of room authorization :). And we should know what happens if you invite someone to a room that's members-only and he's not a member. Because just sending a direct invite is no good. Making him a member and sending a direct invite seems natural to me. I've added an implementation note about that. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. I'm leaning toward crossing that bridge when we come to it. My reason for bringing invite-only rooms was not to suggest they should be done, just that this protocol takes away the possibility to implement them (and it happens to be something I was thinking about a couple of weeks ago). We don't have invite-only rooms, but IRC doesn't have members-only rooms. I can't think of many cases an invite-only room would be called for, unless it is an admin doing the inviting, in which case it is easy to add invitees to the member list. That, or just use a password, as exampled in this XEP. Matthew.
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Matthew Wild wrote: On Mon, Aug 18, 2008 at 2:21 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: Ok, just... couldn't this be at least partially automated (not to have the sure check himself)? If it's not possible, never mind. Sure it could. I'm not sure if we really need that, given that members-only rooms are relatively uncommon, but we could presumably define a data form or ad-hoc command for the automated flow if we really need to. I'm leaning toward crossing that bridge when we come to it. My reason for bringing invite-only rooms was not to suggest they should be done, just that this protocol takes away the possibility to implement them (and it happens to be something I was thinking about a couple of weeks ago). We don't have invite-only rooms, but IRC doesn't have members-only rooms. I can't think of many cases an invite-only room would be called for, unless it is an admin doing the inviting, in which case it is easy to add invitees to the member list. That, or just use a password, as exampled in this XEP. Agreed. Members-only rooms seem much more natural than invite-only rooms, especially because we have authenticated identities. IRC doesn't have authentication, so they might need some kind of cryptographic invitations, but AFAICS that's overkill for XMPP. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Fri, 15 Aug 2008 15:47:17 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Oh sure, one example is [EMAIL PROTECTED] :) /psa But that means we have some sort of room authorization :). And we should know what happens if you invite someone to a room that's members-only and he's not a member. Because just sending a direct invite is no good. Making him a member and sending a direct invite seems natural to me. Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Pavel Simerda wrote: On Fri, 15 Aug 2008 15:47:17 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Oh sure, one example is [EMAIL PROTECTED] :) /psa But that means we have some sort of room authorization :). And we should know what happens if you invite someone to a room that's members-only and he's not a member. Because just sending a direct invite is no good. Making him a member and sending a direct invite seems natural to me. I've added an implementation note about that. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Pavel Simerda wrote: On Thu, 14 Aug 2008 11:27:22 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Well that's what we had in the old days (jabber:x:conference), but then we made something fancier in XEP-0045. Fancier isn't always better. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Sure, conference is fine with me. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. I agree. But that's something we should define in XEP-0045 -- or even deprecate password-only rooms in favor of members-only rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Maybe. I'm not sure how useful MUC authorization is. A members-only room is an authorized MUC room - the list of members becomes the list of authorized entities. But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Thu, 14 Aug 2008 11:27:22 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Well that's what we had in the old days (jabber:x:conference), but then we made something fancier in XEP-0045. Fancier isn't always better. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Sure, conference is fine with me. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. I agree. But that's something we should define in XEP-0045 -- or even deprecate password-only rooms in favor of members-only rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Maybe. I'm not sure how useful MUC authorization is. A members-only room is an authorized MUC room - the list of members becomes the list of authorized entities. But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Peter -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Pavel Simerda wrote: On Fri, 15 Aug 2008 08:55:28 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. I don't think the concept of an invitation-only room makes much sense, especially because we don't have ways of delivering secure invitations (right now invitations are more social interactions, not technical interactions, and I think we might want to leave it that way). But i thought I've seen some members-only rooms. Oh sure, one example is [EMAIL PROTECTED] :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
Pavel Simerda wrote: On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Well that's what we had in the old days (jabber:x:conference), but then we made something fancier in XEP-0045. Fancier isn't always better. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Sure, conference is fine with me. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. I agree. But that's something we should define in XEP-0045 -- or even deprecate password-only rooms in favor of members-only rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Maybe. I'm not sure how useful MUC authorization is. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Thu, 14 Aug 2008 11:27:22 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Well that's what we had in the old days (jabber:x:conference), but then we made something fancier in XEP-0045. Fancier isn't always better. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Sure, conference is fine with me. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. I agree. But that's something we should define in XEP-0045 -- or even deprecate password-only rooms in favor of members-only rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Maybe. I'm not sure how useful MUC authorization is. A members-only room is an authorized MUC room - the list of members becomes the list of authorized entities. But then what is an invitation for? You have to make someone a member and send him an invitation message. But for this, you have to be able to add members. This needs a deep poke into the MUC and I didn't post yet other stuff I promised. /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
[Standards] Proposed XMPP Extension: Direct MUC Invitations
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Direct MUC Invitations Abstract: This specification defines a method for inviting a contact to a multi-user chat room directly, instead of sending the invitation through the chat room. URL: http://www.xmpp.org/extensions/inbox/direct-invitations.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
XMPP Extensions Editor [EMAIL PROTECTED] wrote: URL: http://www.xmpp.org/extensions/inbox/direct-invitations.html Just spotted that typo: The venue/ element is REQUIRED, whereas the password/ and reason/ elements are OPTIONAL. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
