<p dir="ltr">I still use in some installations the old converse plugin with ejabberd or openfire (the second look more advanced ldap side). The plugin need to be changed for sure but you want to change the server too?</p>
<div class="gmail_extra"><br><div class="gmail_quote">Pe 21.11.2016 11:35, "Aaron Seigo" <<a href="mailto:aseigo@mykolab.com" target="_blank">aseigo@mykolab.com</a>> a scris:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Hot on the heels of WOPI and CloudSuite support, we have begun work on bringing instant messaging features to Kolab.<br>
<br>
Usual project/git repo links:<br>
<br>
<a href="https://git.kolab.org/project/view/209/" rel="noreferrer" target="_blank">https://git.kolab.org/project/<wbr>view/209/</a><br>
<a href="https://git.kolab.org/diffusion/KC/" rel="noreferrer" target="_blank">https://git.kolab.org/diffusio<wbr>n/KC/</a><br>
<br>
They are both VERY empty at the moment. That is because we completed initial requirements definitions this past week and will begin development proper this week. We have spent a lot of time looking at the various options, doing some small prototypes, and decided on what I consider to be a brave, but correct, course.<br>
<br>
And I'd love your feedback!<br>
<br>
Looking at the various XMPP servers out there, we realized a handful of things:<br>
<br>
a) they were big and complex beasts ... scalable and very competent, yes, but not simple things. The simpler options were not scalable / manageable enough for our needs.<br>
b) integrating IM type features into the various Kolab clients (Roundcube, Kube, Kontact, ..) was going to be non-trivial<br>
<br>
So we looked at alternative concepts. One that rose to the top quickly was the Phoenix Framework's PubSub which includes channels (named pub/sub entities that can be authenticated, filtered, etc.) and presence out of the box in a very sophisticated and scalable way. The developers of it have managed to get 2.000.000 simultaneous connections actively chatting on *one* physical server with normal performance (e.g. actually usable for chat). Which is pretty insane. It is also clusterable (including self-healing on split/rejoin), supports presence across multiple devices (or web browser tabs) correctly, etc.<br>
<br>
But while Phoenix PubSub solves the hard parts we need for chat, it has (obviously) zero client support as it is intended to be used by applications internally. We really want XMPP support.<br>
<br>
So we spent time scouring the XMPP RFCs. Turns out that for basic XMPP support (auth, roster and chat), that's actually a very manageable project in terms of complexity to add on top of Phoneix PubSub.<br>
<br>
With such a solution we would be able to:<br>
<br>
* have perfect integration with Kolab's auth system (today and in future)<br>
* provide a chat system with as close to "zero config" as possible<br>
* provide the integration we really want to see<br>
<br>
So .. what do I mean by "integration we really want to see"?<br>
<br>
In the immediate, we want to provide the ability to have not just one-to-one and group text chat, but also WebRTC video chat (one-to-one, to begin with). Slightly longer term, we want to bring proper end-to-end encryption for the chat (reusing prior work done in e.g. libsignal), well integrated file send/share, chat alongside document editing, chat links from contacts and identities (e.g. From: labels in emails) in Kolab clients, chat room scheduling from calendar events, etc.<br>
<br>
Our current development roadmap for this is broken into three stages, with the third stage being a bit open-ended (I expect us to break it out into further milestones once we get through stage II):<br>
<br>
I.<br>
<br>
Feature set:<br>
- authenticate against Kolab<br>
- Basic http auth<br>
- think about generic component for Kolab auth<br>
- setting user presence status and receiving other users status<br>
- notifications<br>
- person-to-person chats (<a href="https://github.com/chrismccord/phoenix_chat_example" rel="noreferrer" target="_blank">https://github.com/chrismccor<wbr>d/phoenix_chat_example</a>)<br>
- single page web application that shows contacts list and you can start chats<br>
- How to start a chat, set presence, display presence?<br>
- How to define/start a group chat? invitations?<br>
- "Chat window" layout<br>
- group chats<br>
- webRTC<br>
<br>
II.<br>
<br>
Feature set:<br>
- Roundcube integration<br>
- Current user presence indicator in the toolbar, with possibility to set status<br>
- A way to start a chat by clicking a user name/email address/status icon in the email view and addressbook<br>
- Other users status on contacts list<br>
- How to start a chat from UI?<br>
- How to show the chat "window"?<br>
- Jabber bridge (internal organization communication)<br>
- Kube integration<br>
- UI customization<br>
<br>
<br>
III.<br>
<br>
- Server-side chat state (e.g. which group rooms you are in)<br>
- Files exchange<br>
- End-to-end Encryption<br>
- Multi-user video chats<br>
- Federation (communication between Kolab servers)<br>
- Server-side chat history<br>
<br>
<br>
Our goal is to make stage I a xmas present for ourselves :) It will certainly be a "minimum viable product" type result, but that will allow us to vet the tools we have chosen further, test our assumptions, and give us a springboard for the bigger goals in milestone II.<br>
<br>
Participation is welcome, as always. If you want to learn some Elixir, help with front-end web development, be a bleeding-edge tester ... don't hesitate. The project repo and workboard will be shaping up throughout the week, and we'll be here to discuss as we go.<br>
<br>
-- <br>
Aaron Seigo<br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@lists.kolab.org" target="_blank">devel@lists.kolab.org</a><br>
<a href="https://lists.kolab.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">https://lists.kolab.org/mailma<wbr>n/listinfo/devel</a><br>
</blockquote></div></div>