@sylvain XMPP chatrooms can be configured to be members-only and non-public.
This means that you don't see the room's name appear when you query the XMPP server for available rooms and you cannot join it if you're not on the members list.
I think these two settings together makes a room "private" in the sense that you mean.
Note however that the room's messages aren't encrypted. If you wanted to have encryption for the messages, we would have to implement support for OMEMO encryption inside chatrooms, which is a big task.
Assuming that we don't need message encryption (overkill IMO), and given that we can have private channels via configuration, I think the remaining challenge for this ticket is to come up with an intuitive UI.
Like Rocket.chat and Mattermost, we can have a "Private channels" section and when you create a channel under it, it's automatically members-only and non-public.
When someone is invited to the channel, they're then automatically added to the members-list (this is already done in Converse.js AFAIK).
We need to expose a way to remove someone from the private channel.
When someone joins a private channel, the channel automatically gets added to their bookmarks (we actually need this in general as well).
By JC Brand on 2018-03-27T22:50:00 (imported from GitLab project)
I agree encryption is not required on the short run, and maybe never will be.
Regarding your list of points, I realize that maybe we aren't clear on the fact that in our minds, the chat component is only the chat window.
What I mean by this is the white background part of Rocket Chat. So probably that the admin features you talk about to create a channel and eject someone from a private channel would be coded outside of the chat component.
I let @sylvain confirm this but this is my understanding.It doesn't mean we don't have to implement it, but it probably doesn't belong in the same component.
By Alexandre on 2018-03-27T23:26:58 (imported from GitLab project)
What I mean by this is the white background part of Rocket Chat. So probably that the admin features you talk about to create a channel and eject someone from a private channel would be coded outside of the chat component.
"coded outside of the chat component" is still very vague to me however. Who would code it, what should it look like and where and how will it be used?
By JC Brand on 2018-03-28T07:51:17 (imported from GitLab project)
Yes, that means it should probably be outside this component, and included somewhere else. We could have a dedicated component, but I don't think we need it right away.
In our business case, I think the channels will be created automatically when we create a project or a group in the system. I'm not sure if it should be done client side or server side. I guess for the alpha we can do it manually, and we'll decide that for the beta. We'll probably need more work on your side at that time.
So for this issue related to the chat component, I understand we only need some indication we're in a "member only" channel and a way to kick people.
By Sylvain Le Bon on 2018-03-28T11:34:34 (imported from GitLab project)
It's for me a bit unclear what I should do in this ticket.
The tasks, I've identified are:
Add a way to remove someone from the member-list
Identify whether a room is members-only
Identify whether a room is listed publically or not
Converse.js already indicates whether a room is members-only and whether it's public or not. It does so by showing the room features in the right sidebar.
However, you've asked that the right sidebar be hidden, so I don't know where to show those properties now. Can you please let me know what you have in mind?
Concerning the ability to remove someone from the member-list, this is not yet done, so I want to add the code for this, but again, the way I would do this would be to make the room occupants in the right sidebar clickable, which shows a modal in which you can then click to remove someone from the members list.
Here I have the same problem, because you want the right sidebar hidden, so in your chat component there is not place where all the room occupants are listed (and where they can be clicked).
Converse.js has a button for toggling the right sidebar, so that it can be shown or hidden by the user. Perhaps that's a solution rather than completely hiding the right sidebar?
Otherwise, I need some input regarding UI/UX here.
Thanks :)
By JC Brand on 2018-05-09T08:48:57 (imported from GitLab project)
Maybe we don't need anything more than that at this point. Maybe we can create channels with these settings and see what else we need for the beta. What do you think @alexandre?
I'm still not clear on how we create the channels. Do we do that directly on the server? Basically we need to have one channel per project and one per group.
By Sylvain Le Bon on 2018-05-10T04:05:52 (imported from GitLab project)
What about the members list? Can it also be managed from the back office of OpenFire ?
I asked Guus der Kinderen, OpenFire developer and he said yes, you can do so.
OK. If we do have this ability, then we will start with this and later on, push those features back into the client.
But it is probably good enough to start with if the back office allows it.
OK, then I close this ticket.
BTW, you can configure a room to be private and members-only via Converse.js, but currently the button to bring up the configuration form is hidden because we don't show the room header (see #23 (closed)).
Also, you can make someone a member by typing /member ${JID} in the room and you can remove it by typing /revoke ${JID}.
By JC Brand on 2018-05-14T09:04:48 (imported from GitLab project)