Group chat - Githubissues

ameenross commented 10 years ago

To be a viable alternative to other clients/networks, groupchat is an important feature.

Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3038734-group-chat?utm_campaign=plugin&utm_content=tracker%2F622720&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F622720&utm_medium=issues&utm_source=github).

pravi commented 8 years ago

@daniele-athome, any updates? I wish this was usable as LibreSignal is practically dead.

https://github.com/LibreSignal/LibreSignal/issues/37

Once kontalk has groups, I can happily drop LibreSignal. It would be a good idea to invite LibreSignal folks to kontalk (comment on the above issue). We can easily counter moxie0 that easy to use xmpp is possible.

daniele-athome commented 8 years ago

@pravi the group chat branch is actively evolving although several bugs have been reported through Crashlytics so I've been using the last 2-3 weeks to fix those and release 3.1.9 just yesterday (3.1.9.1 right after because of a Huawei issue).

I'm trying to put as much effort as I could on the group chat feature because I also think that it's going to be a huge step forward.

zgrimshell commented 8 years ago

off-topic: just want to say thanks for this. Kontalk is becoming my main chat app on my phone (I am otherwise heavy mail user + IRC). With Signal becoming totally ignorant of freedom and it's not even usable (at all) for many of us atm - this is really beautiful piece of software.

You should probably go into creation of Kontalk Project (as community driven organization) so you could even get enough funds to make this your job.

daniele-athome commented 8 years ago

Thanks @zgrimshell, really appreciated. Unfortunately the project hasn't gained so much popularity yet that it could justify the creation of a real organization. I'm not going to list all the (possible) reasons, but IMO mainly because of 1) lack of adeguate publicity, 2) lack of an iOS client, 3) lack of group chats. As a matter of fact, user base has decreased in the last few months (user accounts are deleted after 30 days of inactivity, that is after uninstall).

zgrimshell commented 8 years ago

@daniele-athome I will defend my proposal. Lets go into historical account. I am from Debian community (my heart and soul is there) but lets travel to 1993: Debian was created. It became straight away a Project (it of course evolved since then but it is still the same good Project). It lacked publicity (it still does compared to other OSes), I think we still lack proper Debian installation on iOS ;) and we for sure lack things that majority would expect.

Going even further in past, 1983. GNU wouldn't be create if RMS was having same thoughts. Your software is beautiful, making it a community Project can mean nothing, but it also can bring few great people into it (not only devs) and you suddenly will have more publicity, maybe even faster reach iOS client and group chat. In Free software world the norm should be making the right thing as we aren't competing with time. :)

pravi commented 8 years ago

I would agree with @zgrimshell (btw I'm a DD too). @daniele-athome if you are open to working full time (you or some one else), then I can help with crowd funding (I have done a few and this will be appealing to a larger crowd). We crowd fund diaspora instance at poddery.com

1337sup3rh4x0r commented 8 years ago

I think that daniele is right with his hunch that especially the missing iOS client and group chat are a big obstacle for people to give kontalk a spin. The groups that I currently participate in are all mixed (iOS and Android). Before these two "little features" I would basically have no usecase for this app, but after that I would try my best and move everyone over. I already managed to do so from whatsapp to threema, but moving to kontalk would be a big milestone for me :)

Maybe the frustrated folks from LibreSignal would indeed be open to join in here and help? Still no iOS dev among them I fear ...

pravi commented 8 years ago

@1337sup3rh4x0r see https://github.com/ChatSecure/ChatSecure-iOS/issues/370 if ChatSecure adds kontalk support, that would solve missing iOS client issue.

1337sup3rh4x0r commented 8 years ago

I tried chatsecure some time ago with some friends and as far as i know, the're still not able to do push. That basically made it hard to convince people to use it.

daniele-athome commented 8 years ago

I can't move my efforts to Kontalk full time for personal reasons at the moment sorry. Let's see what happens after group chat is released. I'll also push some more publicity to help the project.

seifraja commented 8 years ago

Hello Kontalk developers and users, I first of all would like to thank you for the time spent in developing and supporting (even just installing and using) this great app. I firmly believe this project has the potential to attract a really huge number of users. I am personally sponsoring (sorry for that bad word, may be it sounds better… mmm… listing the benefits) of Kontalk to all the people I know, but actually the big obstacle to convince them to definitely replace any other messaging app they are using for Kontalk, is the lack of Chat Groups and iOS support (with the last less important than the first). Thank you for your efforts. Thank you for your support. Please keep considering these features as the most important obstacle to the further diffusion of this great project. ;-)

daniele-athome commented 8 years ago

Thanks @seifraja for your interest in the project. And yes I think "sponsoring" is the proper term :-) I too consider those two the biggest obstacles to Kontalk's spreading. I'm working on group chats and it should see the light of day during this summer (I don't know exactly when yet, sorry), but for iOS support it will be hard.

seifraja commented 8 years ago

Well, that's not a problem, once the Group Chat will be implemented, we will… give to iOS users the time they need to buy an Android device ;-)

Looking forward for the summer news…

Thanks again

daniele-athome commented 8 years ago

Ok folks, I'd like to share an idea with you. I'm almost done working on an initial version of group chat, but I'm at a showstopper: public key trusting.

As you might already know, Kontalk group chat protocol is client-side only, and it's based on the members being able to communicate with one another (e.g. for now they need to be subscribed to each other, though this will probably change in the near future - by the way @abika I'll send you a big email soon). The biggest issue is accessing the public key, which is allowed only when the user accepted the one-to-one chat invitation. The public key is used to encrypt outgoing messages to the user. But let's ignore the 1-to-1 invitation aspect right now, let's focus on trusting the keys.

In one-to-one chat this is addressed using a snackbar (a red bar covering the composing text entry) that should force you to handle the situation by either accepting the key or blocking the user entirely.

For group chat the situation is a little more complex. Let's say we use the same snackbar, but instead it opens the group information window:

screenshot_20160701-215148

I know it's a bit spartan, but it's a start :-) I have some ideas, but I'd like to read new one and have some feedback in general:

put a big warning icon (e.g. red triangle) next to users with trust issues (unknown/changed key); on click of the user list item, the identity confirmation dialog will appear (same dialog of 1-to-1 chats) - possible improvement: put untrusted users first in the list
... future ideas will come up here ... :-)

I'd like to keep it as simple as possible without compromising security too much. Please don't be afraid to be wrong or silly, all thoughts can be useful. Thanks!

webratte commented 8 years ago

What about we do just like you written. But instead the triangle we put beside all trusted users a green key Icon. And for all untrusted users a Red key Icon.

By click on the green key you can show the fingerprint with just a OK button just for Information.

By click on the Red key you can show the "accept/block dialog" like you use in one to one chat.

daniele-athome commented 8 years ago

By click on the green key you can show the fingerprint with just a OK button just for Information. By click on the Red key you can show the "accept/block dialog" like you use in one to one chat.

I don't think this would be clear. Imagine a user bumping into this screen for the first time (he never saw the 1-to-1 identity dialog because he didn't start any 1-to-1 chat yet, he goes directly to create group): what do the buttons mean? I mean we let the user take a decision in fact without really knowing what is doing.

seifraja commented 8 years ago

@daniele-athome, I personally like your Spartan idea, simple and effective and I'm in acxordance to maintain as much as possible a simple layout, similar to the current one. What do you think about the following proposals?

Proposal nr.1 -> no sign beside a trusted user and the same red sign of the 1to1 chat beside a new-key user. So, the same graphical layout we are currently experiencing.

Proposal nr.2 -> in order to obtain a bit more informative but still easy graphic, I would opt for the @webratte proposal of green and red icons, specifying that the icon could be a green closed-lock beside a trusted user and a red closed-lock beside the new-key users.

…and, as you said, with an identity confirmation dialog appearing by clicking on the untrusted users…

tetris4 commented 8 years ago

specifying that the icon could be a green closed-lock beside a trusted user and a red closed-lock beside the new-key users.

+1 to this, but I would go for an open-lock for the red icon to communicate the issue more clearly.

It could also be a green lock icon for trusted users, and a red exclamation mark for untrusted ones, which is often used as a sign of attention.

webratte commented 8 years ago

Maybe is could be a good idea to use the green and red signs (keys or locks or whatever) also in global contact list with the clickin action that I descripte.

Because there is currantly no way to check the trusted keys again whithout Block this user.

TheLastProject commented 8 years ago

I thought the snackbar only came up when the key changed? Not just whenever someone was new? I'd personally think TOFU (Trust On First Use) would work better. Trust everyone, and only warn when the key changed. This warning should probably just open the same dialog as in one-on-one chats to immediately trust a single person. An extra screen where someone has to figure out what to tap will just cause extra confusion

A lack of TOFU will make group chats horrible if you get invited to one with multiple unknown users.

daniele-athome commented 8 years ago

@seifraja wrote:

Proposal nr.1 -> no sign beside a trusted user and the same red sign of the 1to1 chat beside a new-key user. So, the same graphical layout we are currently experiencing.

I'm sorry I don't think I understand: do you mean using the current snackbar in the group chat? How do I do that in case of multiple untrusted users?

@webratte wrote:

Because there is currantly no way to check the trusted keys again whithout Block this user.

Yeah that's another issue to be addressed already :-)

@TheLastProject wrote:

A lack of TOFU will make group chats horrible if you get invited to one with multiple unknown users.

I think TOFU should be the last resort - although @TheLastProject your reasoning is valid. @abika what are your thoughts on this?

TheLastProject commented 8 years ago

TOFU is necessary. Without it, we're literally teaching users to mindlessly hit "accept" so they can chat and we're making it really hard for users to learn that key changes should be taken very seriously.

While on this subject, I feel we should have 3 security levels which we could indicate perhaps by colouring the nickname: Red: Untrusted key (can't chat until a warning is accepted) No colour: Automatically trusted key (TOFU) Green: manually trusted key

(Other ways would be possible too, but colouring the nickname is the easiest to consistently do in any screen, including all user lists, which is why I'm recommending it)

Currently, we will only be able to get red or colourless nicknames (when accepting a key change, the user most likely does not have the time to thoroughly check if the key is really trusted). To get a green username, the user will have to scan the other user's QR code or in some other way access the other user's key info and trust manually, additional functionality will be necessary for this.

seifraja commented 8 years ago

@daniele-athome, premising that I don't know how much work is needed to implement this update, what about to write in a single red snackbar the list of the key-changed users, similarly to the current one for 1to1 chat? Then, by selecting the red snackbar, give the possibility to choose which user to trust (don't know if this is possible in the same window or a new one is needed).

@TheLastProject, the TOFU philosophy would simplify the use while contributing to maintain high the attention for the users keys.

Summary: +1 vote for TheLastProject suggestion if the implementation of the TOFU concept won't delay the group chat update, in which case it may be implemented in a successive update, after having tested a little bit more the functionality.

seifraja commented 8 years ago

…addition to the Proposals to increase the privacy protection -> would it be possible to hide the telephone numbers of the participants to the group chat, in order to avoid to share the tel.number between users which don't necessarily know each other?

abika commented 8 years ago

@daniele-athome wrote:

(e.g. for now they need to be subscribed to each other, though this will probably change in the near future - by the way @abika I'll send you a big email soon)

ok, ill be prepared.)

@seifraja wrote:

@daniele-athome, I personally like your Spartan idea, simple and effective and I'm in acxordance to maintain as much as possible a simple layout, similar to the current one.

Yes! It is already good. And simple is definitely better.

@TheLastProject

TOFU is necessary. Without it, we're literally teaching users to mindlessly hit "accept" so they can chat and we're making it really hard for users to learn that key changes should be taken very seriously.

Your solution is even worse: We're not informing users anymore about a potential security risk. And as a result they don't even have a chance to accept or refuse a key. TOFU without any user interaction is bad and nobody coming from PGP is doing that.

Red: Untrusted key (can't chat until a warning is accepted) No colour: Automatically trusted key (TOFU) Green: manually trusted key

Having three states is a good idea! But please no colored user names, nobody will understand that.

My proposal: How about a "trusted" flag that can have the values {verified, ignored, not verified} for each key. New keys can already be used by setting them from not verified to ignored but they are not verified yet. This can be done in the confirmation dialog by comparing the fingerprint, QR code, whatever.

And now a bigger change: A "Contact screen" is required. It shows the status text, fingerprint and the already mentioned warning sign if the key is not verified (in this case the user can also open the confirmation dialog here). [More content can be added in the future.] This screen can be accessed

from the contact list
by clicking on a contact in the group info

Now, if a contacts key has not been marked as verified yet, this will be visible

in 1-to-1 chat as popup ("Contact key has not been verified." OR "Contact key changed.") and "Click here to open confirmation dialog."). We already have something similar now, but the third option is added now: The user can also ignore the warning and start chatting right away.
in group chat as popup ("Not all contact keys are verified, click here to open group info."). Again with the ignore option which will set all not verified keys to ignore.
in the contact screen as already said
maybe in the contact list: warning sign next to the contact name (not sure about this)

This will

give the security agnostic users (sadly the majority) the ability to use 1-to-1 and group chats right away
make it possible for security aware users to get informed about security risks and act accordingly before something bad happens (writing messages with not trusted keys)
solve the problem of checking trusted keys again

And for the user interface:

verified: green icon
ignored: gray question mark
not verified: red icon

But these are details and only another suggestion.

seifraja commented 8 years ago

@abika, like your detailed idea and as a user I can say I won't have problems to have a look to the keys, as all the users wih a little bit of knowledge about end to end encryption. Hope won't delay too much the update. ;-) …and what about to hide phone numbers between group chat members to protect users who don't know each others when they are participating to the same chat?

abika commented 8 years ago

@seifraja

…and what about to hide phone numbers between group chat members to protect users who don't know each others when they are participating to the same chat?

Phone numbers are not shared between users over Kontalk anyway. If you're in a group with somebody else who is not in your address book you won't see his/her phone number unless somebody explicitly sends it to you.

iNPUTmice commented 8 years ago

Phone numbers are not shared between users over Kontalk anyway.

This is not true.

and what about to hide phone numbers between group chat members to protect users who don't know each others when they are participating to the same chat?

This is not possible. In Kontalk your JID is your phone number (or very easily reversible hash there of). With a client side group chat feature where your client basically just broadcasts the message to everyone else your client has to know the JID and thus the phone number.

abika commented 8 years ago

@iNPUTmice well, totally true if you're referring to #497 : All hashes are known and they can be reversed. I didn't want to repeat that here.

iNPUTmice commented 8 years ago

@abika if you know that then

Phone numbers are not shared between users over Kontalk anyway.

is a very misleading statement to users like @seifraja who are obviously unaware of that fact.

Every time you communicate with someone on Kontalk - group chat or not - you are sharing your phone number with that person. That's a key design feature of Kontalk. I'm not saying it's a bad design decision. But I do think users should be aware of that.

Edit: Sorry I didn't mean to hijack your thread about group chats. I was just still subscribed to this thread for some reason and couldn't hold it in me. If you want to continue this discussion elsewhere you know where to find me :-)

seifraja commented 8 years ago

@iNPUTmice and @abika, you are right, I wasn't aware about how easily hashes can be reversed in Kontalk to obtain back a not visible phone number. Now I am, probably like many others reading. Thanks.

Said this, as a profane of programming code, how hard would be to introduce the concept of Web Of Trust in order to implement a sort of auto verification of users key signatures, considering Kontalk is based on PGP end to end encryption?

PS: for those who are mainly users like me, for Web Of Trust I mean this https://en.m.wikipedia.org/wiki/Web_of_trust

seifraja commented 8 years ago

…and sorry for this late add, but I still think that not to explicitly show phone numbers to everyone in a group chat could be a good thing to implement, independently from how easy can be to obtain it back from an hash…

TheLastProject commented 8 years ago

@abika Thinking of it a bit, I think your ignore suggestion may also be acceptable, as it does tell users there are ways to improve the security, although I am not a fan of using warnings to teach users about functionality, it just doesn't seem very user-friendly to me. Also, the "green name" to trust an user would depend on #456 being properly implemented.

I also agree something different from coloured nicknames would be fine, although we should be very careful that an user can't "fake" the verified status by using emojis anywhere, which is why I initially suggested colouring the nicknames. When all nicknames default to uncoloured and tapping a red nickname will show the untrusted key warning, I do think users will implicitly learn very quickly that "red nick is bad".

daniele-athome commented 7 years ago

Thanks for all your contributions. I'm inclined to follow the 3-states suggestion by @abika because, for better or worse, I think it's the best compromise between security and usability. I'll begin working on this and I'll have an (incomplete) alpha as soon as possible so we can all begin testing (it's been damn too long I know :-).

I'll begin implementing the colored icons thing in the group info screen first - the contact info screen (#456) will come after that (but before the final 4.0.0 release).

@iNPUTmice don't worry about stepping in, your comments are welcome as anyone else's. I agree we need to address that, not only from a technical point of view, but also as a user awareness issue.

P.S.: I'm back :-)

daniele-athome commented 7 years ago

Just for the followers of this issue, a very early preview:

http://astra.casaricci.it/public/Kontalk-4.0.0-alpha2-basic.apk http://astra.casaricci.it/public/Kontalk-4.0.0-alpha2-googleplay.apk

SHA-1 sums:

19bad9c3d6eb5a86bed82f7cb609aeef718a5b8a  Kontalk-4.0.0-alpha2-basic.apk
6d646d6cf8ca6e4e4f7e56bdaa83494b9923abf1  Kontalk-4.0.0-alpha2-googleplay.apk

It can be installed over version 3 and it will upgrade your existing installation (so no turning back but uninstalling). It has been roughly tested by 3-4 people so far, EXPECT BUGS and missing stuff. The above apks are not compiled with debug information and the Google Play version will connect to Crashlytics to automatically report crashes (if they should happen, I hope not).

I'd like you to provide feedback, especially for the group information window (reachable by opening the toolbar when inside a group chat) which is quite experimental - and the whole key approval process which is still rough.

EDIT: apks are signed with the Google Play certificate so sorry F-Droid people, you'll have to uninstall to try it and then reinstall again when 4.0 will be released on F-Droid :-(

webratte commented 7 years ago

I have just installed Version 4.0.0 alpha-2 There should be a more intuitive way to create a group. E.g. a Button "create new group" at the top of the contacts list.

And if I trie remove a groupmember -Kontalk crashed. I think crashlytics will inform you.

daniele-athome commented 7 years ago

There should be a more intuitive way to create a group.

I'm planning to introduce a show view to teach the user how to do so.

(FYI to everyone) Currently there are two ways to open a group chat:

long-press contacts in the contact list and use the compose button in the toolbar
while in a 1-to-1 chat, menu > add users

That will need improvement I know :-)

I think crashlytics will inform you.

Yes it did, thank you.

pravi commented 7 years ago

On Wednesday 17 August 2016 08:44 PM, Daniele Ricci wrote:

Just for the followers of this issue, a very early preview:

http://astra.casaricci.it/public/Kontalk-4.0.0-alpha2-basic.apk

I tried to install it on my Yu Yuphoria with Cyanogen Mod 12.1 (Android 5.1.1).

It just said application was not installed.

daniele-athome commented 7 years ago

@pravi:

EDIT: apks are signed with the Google Play certificate so sorry F-Droid people, you'll have to uninstall to try it and then reinstall again when 4.0 will be released on F-Droid :-(

webratte commented 7 years ago

|while in a 1-to-1 chat, menu > add users

Better then "add users" would be "add users to a group"

I know, it's a long sentence but better to understand

TheLastProject commented 7 years ago

Instead of adding a view to explain to users, I'd really like to urge to instead make the UI more logical. For example, when hitting the compose button in Telegram, it has "Create Group" entry at the top of the list, before the list of contacts, which when tapped on gives your contact list to allow you to select who you want to add to the group.

See https://www.youtube.com/watch?v=05V1ZHxb_oo. It's pretty self-explanatory in my honest opinion.

zgrimshell commented 7 years ago

@webratte just wanted to write exactly what @TheLastProject wrote. Instead "add users to a group" better UX would be create group. More generic for all, shorter.

daniele-athome commented 7 years ago

Telegram has another couple of choices too so I can say it's justified. But for a single button... I don't know, it seems like an "interruption" in the screen.

Looking around I was thinking of something more like this (watch only the button in the bottom right corner):

Screenshot

IIRC it was the Telegram way some time ago, wasn't it? Or was it Hangouts?

Another option would be a tabbed contact list (one for single chats and one for groups), but I think it would just be an overkill.

TheLastProject commented 7 years ago

While Google does allow that floating action button style, I'm not sure if it's better, because this way you're adding an extra click to start a conversation with a new contact, because you first need to click "Contact" as well. Although I personally find this an acceptable solution as it's much more discoverable.

A tabbed contact list is used by WhatsApp I believe, but I'm not a fan of that myself either.

daniele-athome commented 7 years ago

Alpha3, with lot of bugs of fixed and an experimental floating action button menu.

daniele-athome commented 7 years ago

People I got a crash from alpha3, if it's anyone of you, I got the stacktrace from Crashlytics but I need some information about context this time, thank you!

webratte commented 7 years ago

I think it was me. What I did:

-Created a group with two peoples (me and Alice) -Then I deleted Alice from this group -Then I deleted myself the same way (not using "leave group")

This was the point when Kontalk crashed.

BTW: I like the idea with the floating action button menu. :+1:

webratte commented 7 years ago

If I start from the scratch (importing key) with Alpha 3 (not upgraded) I can not chat with myself. Kontalk says I have not yet accepted my key. My own key should always accepted from myself.

webratte commented 7 years ago

Sorry, I meant not "not accepted the Key" but "not accepted the invitation".

And it's also after Upgrade from regular Playstore Version to current Alpha 3.

daniele-athome commented 7 years ago

-Created a group with two peoples (me and Alice) -Then I deleted Alice from this group -Then I deleted myself the same way (not using "leave group")

I'm on it.

Sorry, I meant not "not accepted the Key" but "not accepted the invitation".

Fixed in 78e3ece4b01b75095c5ecedb33f5bd88aeee170e.

kontalk / androidclient

Group chat #179