Group chat

[ameenross]

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).

[daniele-athome]

Thanks for reporting. Group chat is expected for stable 3.0. I'm linking this to the server ticket kontalk/tigase-extension#5.

[ameenross]

Aw, too bad this is delayed... I really want a viable alternative to Whatsapp, which I've been worried about using from the beginning (privacy concerns etc). More worried ever since Facebook acquired them.

[daniele-athome]

I'm not really sure about delaying it to 3.1, it depends on how 3.0 feedbacks will drive development efforts. I'll try to introduce something in 3.0 in a "preview" form or a future beta version. It might even happen that groups will be added to 3.0.5 (let's say) or a future 3.0.x.

[ameenross]

I'm quite happy either way. Just hope it can happen sooner rather than later :)

[dev-mb-zz]

Hi! First of all, thanks for your great effort. To give some feedback: Group chat is, besides an IOS version, one of the main features which need to be present for greater adaption with "normal" users. Thanks again and best regards.

[sim6]

Oh no! It's postponed again :(

[daniele-athome]

@sim6 sorry but material design changes involved also stuff needed for group chat so I preferred to do it first. But don't worry, @abika has already begun working on the protocol side and something is already underway.

[sim6]

Thanks for the summary but, as you know, this is an important feature.

[sim6]

How could we help you to get this feature more quickly?

[webratte]

@sim6 It seems you have developing skills. Why not clone the repository and help with PRs?

It's not a joke ;-)

[sim6]

Thanks. Could you be more specific?

[webratte]

Sorry, but I work only as translator. But I'm sure @daniele-athome will answer to you very soon.

[webratte]

Just a (stupid?) idea: What about take a look to other open issues? Maybe there is some things to do for you.

I belive every closed issue is a step closer to group chat.

What do you think?

I wished I could coding :-\

[sim6]

I care about getting this fixed, so I'm offering a bounty. https://freedomsponsors.org/issue/736/group-chat You can also join me and throw in a few bucks there and we'll get it fixed faster :)

[daniele-athome]

Thanks for your offer @sim6. Any reason in particular for using freedomsponsors.org? We already have everything set up with Bountysource, what do you think about it? I know bounties are indipendent of the sponsoring entity, but I just wanted to know if it would be good for us to support freedomsponsors.org instead.

[sim6]

http://freedomsponsors.org codebase is free software.

[daniele-athome]

That's good to know, but at least Bountysource comes in as a mediator for the money involved. Anyway, it's not mandatory so... whatever :-)

[h-2]

Maybe you could cooperate with the conversations people on this? -> siacs/Conversations#1372

This would of course require #538 but maybe it would make sense to go this way directly and not engineer an extra solution. [I know users always think that cooperation will solve things and that its more difficult to integrate other code and/or work with other people in reality, but I still think it would be cool :) ]

[daniele-athome]

@h-2 we have different objectives. We won't support MUC, we'd like to create a client-driven protocol for group chats, a bit different from MUC, which is just IRC channels ported to XMPP. The XMPP foundation is trying to solve this problem by creating some sort of a "next version" (e.g. MUC2), but we are taking a different approach. We want to try this approach and see how well/bad it works; if we'll have the data to provide a replacement for MUC, we will go forward to the XMPP folks with a XEP proposal. As for the encryption part, we would benefit from group OTR though, that we could and will use.

[h-2]

@daniele-athome because it popped up in #567 I wanted to post here again... As far as I understand siacs/Conversations#1372 is not about implementing another server-side chat, but that they actually want to use OMEMO's specific multi-device support to facilitate a mostly client-based group chat. Also the same limitations are discussed there (not too many users supported et cetera). Maybe indeed it would make sense to work together on this? More eyes and ears and more coders ;)

[daniele-athome]

Thanks @h-2 for pointing this out. A group chat protocol should also support non-encrypted chats. Does OMEMO supports that?

[h-2]

Hm, I am not sure if that should be required for Kontalk, as all chats are encrypted by default anyway. But I would think that the Conversations people would want non-encrypted, too? Maybe @iNPUTmice can shed some light on their current plans?

[daniele-athome]

Well it is on our side, at least when chatting with non-Kontalk users. Besides, if we want to push such a group chat protocol to the XMPP community, we must address both encrypted and unencrypted situations.

[iNPUTmice]

Our group chats will be MUC2 based and will support both unencrypted and OMEMO encrypted messages.

If I were you @daniele-athome I would probably get involved with the XMPP community and try to get your use cases covered by MUC2. I don't see much success in coming up with your own solution that will only be supported by your client. While agreeing on standards might be a rocky road it'll probably be worth it as it gives you interoperability with others.

[abika]

I presume that MUC 2 will be independent from any encryption mechanism, only that encryption in general is possible might be important. So, Conversations and Kontalk need exactly the same standard for the same use-case: mobile IM.

@iNPUTmice is there already some proposal open for comments? All I found is this one thread on the mailing list: http://mail.jabber.org/pipermail/standards/2015-February/029587.html

[daniele-athome]

If I were you @daniele-athome I would probably get involved with the XMPP community and try to get your use cases covered by MUC2

Well, I didn't even know about MUC2 existance until a couple of months ago. I admit I can't find the time (or will) to actively participate in a internet-based discussion group (for various reasons that I'll skip now, mainly for the lack of time and I also think that when too many people talk it's hard to reach a decision - just watch the latest flame that arised around deprecating privacy lists - that means spending even more time which I can't spend, sorry). But if you @iNPUTmice want to share some spec draft, I'll be happy to read and discuss it with you.

Talking to the rest of the XMPP community: I prefer to be seen as a user for now (I want to stress the for now part) of what the XSF produces, so surely I won't blame anyone for putting decisions on protocols design. That said, I really can't wait for the XMPP community to draft a new MUC proposal - unless, as I said, @iNPUTmice has something written that can be studied and eventually improved if needed. Eventually, when MUC2 will become a XEP, Kontalk will surely switch to it and propose any improvement if needed by our project use cases.

[sim6]

I don't want to wait for the perfect protocol. Please, go ahead with something functional. If a protocol has consensus in the future it could be adopted.

[TuningGuide]

@sim6 I aggree. If Kontalk is a working programm with encrypted group chat functionality I don't need interoperability. But of course we could present our learnings to the XMPP community and show which things worked and which dont.

[maxlinux2000]

+1

Please, add the group chat, and if possible the user avatar soon.

[FranBran]

+1

[pravi]

What is the current status of this issue? Would adding more money to freedomsponsors bounty help make it faster?

[daniele-athome]

I honestly don't know. At the time I'm the only one working on Kontalk and I've been having some life issues so I couldn't work on it. I'm taking advantage of the holidays free time to do some stuff. Expect some pre alpha version relatively soon.

[susobaco]

The MUC-2 is out https://xmpp.org/extensions/xep-0369.html

[pravi]

@daniele-athome now that MUC2 is out, can you consider it? It will save a lot of effort in federating with rest of xmpp later.

[daniele-athome]

@pravi I don't think so, not at the beginning at least. I want to see how it develops first. Besides, we would really prefer something not completely handled by servers - more of a p2p approach, like the one we are proposing. So I guess for the moment we'll stick to our custom XEP, sorry.

By the way, some good news: I've been focusing on group chat lately, I hope to have a pre-alpha version ready in a couple of weeks with some very basic support for groups. I haven't dediced yet if I will publish it on Google Play alpha channel though. News will come soon.

[pravi]

@daniele-athome Signal already has server-less groups. It would be a good idea to study their implementation.

[daniele-athome]

They don't use XMPP but yes probably some ideas could be useful, especially for encryption - although we are implementing this first version with OpenPGP encryption, no OTR yet.

[pravi]

The current Signal implementation is unusable for large groups in slow/unreliable connections. It is unbearably bad, you get delivery failed messages very often, even when a it is failing for a single member, when you send it again, those who already received gets multiple copies. In short, it is a total mess. I'm sure Kontalk will have to reimplement the same painfull wheel. I strongly believe we should implement server side MIX (MUC2) while we perfect the client side groups. With more diaspora services supporting xmpp, interoperable groups with xmpp users is very important. It is really painfull to maintain 3 apps (kontalk, conversations, signal) just to be able to talk to all your friends and we have to create multiple groups.

https://mobile.twitter.com/jackerhack/status/704211046077050880

I strongly believe whether the group is server managed or client managed should be a choice left to the user. It can be client side by default, but server side groups should be allowed for large/public groups.

[daniele-athome]

Thanks for the feedback @pravi. But I think it's a bit premature to talk about this: the choice might be useful, but those two methods must be implemented first :-) we will discuss this when we'll begin thinking about MUC-light.

[FranBran]

why not using omemo like Conversations does?

[daniele-athome]

omemo is not a group chat protocol, it's an encryption protocol.

[pravi]

@daniele-athome its a month since your promised good news on groups :) Any update?

[abika]

@pravi please don't get impatient. Current progress is in the "group-chat" branch. If you need this feature urgently you're welcome to contribute.

[pravi]

@abika I was just reminding about an update he promised here https://github.com/kontalk/androidclient/issues/179#issuecomment-183227489

[daniele-athome]

I'm sorry if I can't keep up to all my promises exactly - in fact I should stop making any - but I do care about several aspects of this project on my own - and I have a full time job, so you must forgive me if sometimes I'm not precise on estimates. You know what: you should add +50% to all my estimates from now on :D

Ok being serious now: I'm currently running the latest feature/group-chat commit on my phone with a few friends and the results are promising, but it's too soon to be released as a public alpha. You're welcome to build it and try it yourself of course.

About that guy offering help on group chat: I sent him an e-mail with what was needed several days ago, but at this time he didn't reply yet. In the meantime, hoping that I would get some feedback from this guy, I went back to maintaining the current 3.1 branch with some bug fixes - in order to not appear dead as a project to our users.

[gnuanu]

Tried building the "feature/group-chat" branch but the build failed. I'm using a 32bit PC running Kubuntu 15.10 and Java8.

I'm aware that, google have limited their support towards Linux, only to x86_64. Is there anything specific I can do to get it built on a 32bit PC?

[TheLastProject]

It may be useful to at least supply logs. They exist for a reason, after all. Hard to tell with so little info if it's even 32-bit related or not.

On 21 March 2016 13:54:58 CET, Anoop Panavalappil notifications@github.com wrote:

Tried building the "feature/group-chat" branch but the build failed. I'm using a 32bit PC running Kubuntu 15.10 and Java8.

I'm aware that, google have limited their support towards Linux, only to x86_64. Is there anything specific I can do to get it built on a 32bit PC?

---

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kontalk/androidclient/issues/179#issuecomment-199258812

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[daniele-athome]

@gnuanu I actually gave up building on 32-bit, sorry. Reverting some SDK tools to a previous versions had other unexpected side effects, I didn't do much research after that.

[pravi]

@daniele-athome just tested the group feature with apk built by @gnuanu. I can invite more people to a chat and broadcast messages. They receive it as direct messages.

[daniele-athome]

@pravi yes that's how old clients are seeing those messages for now. Anyway, the latest commit is going under some refactoring so it might not work at the moment, sorry.