[JDEV] Groupchat and "secrets"

[David Waite]

jens at mac.com wrote:

> So I'm in the thick of implementing groupchat/conferencing in my client. Thanks to temas for pointing me to the latest docs so I didn't keep working off of the obsolete stuff in the JPG!
>
> My current head-scratcher is: the person creating a chat room can set a "secret" or password that's required to join the room. However, there doesn't seem to be any way in the protocol for a client being invited to the chat room to be told what the password is. As far as I can tell the only way is to go roundabout through the people involved, i.e. the inviter adds "the password is froolap" to the invitation message, and the receiver then has to read that and type "froolap" into a dialog box when accepting the invitation. Kind of awkward. Or did I miss something?
>

The stuff in JPG (Groupchat 1.0) is not obsolete; its not even 'legacy' yet :-)  The 2.0 'Generic Conferencing' proposal up at http://docs.jabber.org/draft-proto/html/conferencing.html is not yet finished.

I'm currently working on a new draft for 'Generic Conferencing', with a number of changes:
- Authentication against the room (room password, user account password, etc.)
- invitations are sent through the server; indicating the user within the room who invited you, as well as their real Jabber ID. It will also pass the room password automatically in the invitation (although there is of course the problem when the room's secret changes between the time the invitation is sent out and the user accepts it).
- Creating a room and Entering a room can either be two different tasks, or joining a non-existant room may create it (depending on the underlying system being used by the conferencing service).
- Non-anonymous rooms, being rooms where you are represented by your Jabber ID rather than some nickname or key.
- Extension for automatically creating (and joining) new rooms, to guarantee clients a unique room for a multi-user chat.

>
> I'm also not entirely happy with the security of a shared password, especially for a chat room that might be more-or-less permanent. As soon as someone spills the beans (or eavesdrops on someone joining the chat), the security of the room is compromised. Have there been any proposals for better security? For example, a simple improvement would be one-time passwords: the server makes up a different secret for every invitation and stuffs it in the invitation. The invitee has to echo the secret.

One of the things I'd also like to start rolling on is an 'invitation-only'-type room. There would be an invitation list maintained, and only people invited to the room could join. Deciding who can invite people (and hence add to the list) and who can revoke invitations later both will push this out beyond the draft I'm working on right now.

>
> Speaking of longevity of chat rooms, do they disappear when the last person leaves? If not, how do you get rid of one?

You could both have a non-persistant room in which the last person out turns off the light, or a persistant room which is always there in some form or another. A discussion forum like JDEV would be persistant; even if nobody was present it would maintain something like an ACL for participants in the room, and certain room information like a room description and a current topic, and show up as a search result.

I won't have that distinction in this next draft as well - just a note that rooms aren't required to disappear when everyone leaves. Eventually I'd like to see the persistant rooms have a singular "room owner" who can eventually destroy it, and server administrator functions to create or destroy these rooms.

-David Waite