Hey Derek, Andrew,
This can't happen with XMPP in Jitsi. It wouldn't even work on the interface
level. My guess is that you simply started a chatroom where you were only
talking to one person and then another one joined. (But it uwas a Multi-User
chat from the start).
A one-to-one XMPP chat in Jitsi cannot become a multi-user one.
Actually, Andrew appears to be right, as I see the Invite button in
the one-on-one chat window which opens a windows which says "Select
the contacts you would like to invite to this conversation".
Guys, you are right. Indeed, inviting a third person to a chat will indeed lead to the problems Andrew described. I am not sure exactly what I was thinking. I apologise!
We need to make these rooms invitation-only by default and then we need to fix room configuration, so that the organiser can further transform them if necessary.
Could you guys please open a ticket?
also a Create a Conference Call option under Tools which brings up the
The Conference Call option does not use MUCs in any way so this is quite different. Security for conference calls is indicated separately so I don't believe the problem applies there.
Neither indicate that the security will be lost and a
possibly unencrypted chatroom will be created and suggest that
invitees will be invited to join "this" conversation. It also only
seems to list contacts associated with the profile being used for the
one-on-one chat, so with my gmail account which I have two contacts
under (one jit.si and one gmail) they're listed, whereas with my
jit.si account which only has one contact, only that is listed, which
doesn't seem to make much sense if I'm creating a public, unencrypted
chatroom which anyone can join.
Regardless of the privacy settings for a room, you can only send invitations to people that are part of your account roster. There's no way around this.
We support end-to-end encryption only for one-to-one chats in Jitsi.
Multi-User Chats (MUCs) only rely on whatever protection the transport
channel provides (typicall client-to-server TLS).
I'm not really sure what that means, so can you clarify please? If I
create a MUC using my gmail account and invite a gmail contact and a
jit.si contact, what encryption will be used?
The connection between you and your server will be protected by TLS. The connection between your peer and their server will be protected by TLS.
The administrators of both servers will be able read your messages.
Gmail does not support TLS for server-to-server connections so the communication between the two servers will not be protected.
TLS only encrypts between you and your next hop. It tells you nothing about what the situation for the rest of the route is. That's where an end-to-end encryption mechanism such as OTR is different.
We don't support end-to-end encryption for chat rooms.
Does this make things clearer?
Likewise, if I create a
MUC using my jitsi account and invite the same contacts, what
encryption will be used.
That's pretty how a Jitsi user would currently handle this.
As I understand it though, the MUC password feature isn't currently
It is operational and you can join password protected MUCs. I do this every day. What isn't operational is the MUC configuration form that allows you to set a password on a MUC. We'll fix this.
so they couldn't handle it this way but to be clear, are
you saying that when it is operational, that on inviting contacts to a
password-protected MUC, a new window will open and any contacts
already in one-on-one chat that have been invited to the MUC will have
to join this manually using the password, whilst the one-on-one chat
window/conversation will remain active?
No, there would be no passwords in the auto-upgrade case. The MUC will be invitation-only.
On 20.07.13, 13:40, Derek Moss wrote: