XMPP chat integration about mailpile HOT 35 CLOSED

I'd been hoping you'd make an appearance. Exciting!

On 2013/08/07 14:57, JC Brand wrote:

Hi guys,

I'm very excited by the promise that Mailpile holds, especially in
light of the open development model and the great ideas that are
coming out of this issue tracker.

I see one of your stretch goals is built-in support for XMPP chat.

I'm the main author of Converse.js, an XMPP chat client similar to
GTalk,written fully in Javascript and which can be integrated into
any
website.

http://conversejs.org [1]

I have experience integrating it into a large Python (Plone) site
(with single signon/session support), and I'd be happy to contribute
to this project as well.

Regards
JC

Reply to this email directly or view it on GitHub [2].

Links:

[1] http://conversejs.org
[2] #55

from mailpile.

an xmpp chat client inside mailpile would be great, especially if it supports encryption like pidgins off the record plugin

from mailpile.

I just backed this project yesterday, and integrated chat is my top wishlist item. This is exciting, thank you!

from mailpile.

Very interesting! We will have to sit down and think hard about how exactly we want to implement XMPP in order to make everything work smoothly (technical backend, integration with the search engine, UI, etc.), but we'll definitely want to organize a call with you or throw some e-mails back and forth within a few weeks when things slow down a bit. Thanks!

from mailpile.

@tethra and @lisabrewster thanks for the positive feedback.

@W4RH4WK Converse doesn't yet support OTR, but it's one of the top items on the wishlist. Another thing I'm excited about is video support via the Jingle extension for XMPP and WebRTC.

These guys made something that could be integrated: https://github.com/ESTOS/strophe.jingle

@BjarniRunar A call sounds great. I realise things are hectic for you at the moment. In the meantime I can use the time to familiarize myself with Mailpile's architecture to see how XMPP could be integrated.

from mailpile.

@BjarniRunar had a good UX suggestion for chat integration: transparent switching between PGP email (retention and no perfect forward secrecy) and OTR chat (perfect forward secrecy and no retention). Which is used depends on social expectations. #79 (comment)

Is this something we would want to do?

from mailpile.

Just an update on this. The master branch of converse.js now supports OTR.

It's not yet released, but I plan on doing so in the near future. In the meantime, if you're looking for a live demo, you can test it here: https://chat.opkode.com (note debug output is on and scripts are unminified).

from mailpile.

Just now I was actually writing about communications security and the introduction of XMPP and OTR at one of the crazy business endeavors I'm in bed with, and got distracted and checked out a couple of GitHub issues. So awesome to see this was updated 21 hours ago—I've been looking for something like that for the past three months.

Thanks a lot for doing the work, it's a great step forward for web and communications security. Much appreciated!

Will be following this.

from mailpile.

@uktu Good point. Do you think that a notification to make the user aware which messages are PFS and which are not would be enough, or would you prefer that the two conversations be kept separate?

from mailpile.

It would be great to have a built xmpp client. In my review would also be nice to be able to connect to IRC networks, even if the xmpp client can connect to multiple servers could be fixed with a transport

from mailpile.

when can we see chat feature in mailpile, i mean any expected date or some thing.

from mailpile.

The answer is as soon as someone does the integration work. From my side, there is no set date for integration.

At the end of last year I made an effort to add OTR (off-the-record encryption) support for converse.js, so that it will be more attractive for the more privacy-minded Mailpile folks, and I would love for it to be integrated into Mailpile.

But currently I'm on a backpacking trip and don't have the facilities, time or motivation to do the integration work myself.

I would however offer advice and support for anyone willing to give it a shot. It's not that hard and there are docs available: https://conversejs.org/docs/html/index.html

from mailpile.

Jabber-based chat which was well-integrated into Mailpile would be an awesome feature.

Jabber support which was anything but well-integrated could be an okay feature, or could be confusing and counter-productive. Any Jabber support shouldn't interfere with email support. Folks should be able to use Mailpile easily without Jabber. Mailpile's main development shouldn't be unduly delayed in order to add Jabber support.

Smart support for well-integrated Jabber (like combined OTR/GPG key-exchange*) might have architecture implications which should be considered earlier, but not at the expense of large delays in a version of Mailpile which supports email.

• this may or may not be a good idea, it's just a guess

from mailpile.

From an ecosystem point of view, it would be valuable to consider integrating cryptocat codebase from @KAepora

from mailpile.

Yes, perhaps the Mailpile team should consider Cryptocat integration? :-)

from mailpile.

@KAepora that would be wicked sweet, my dream is to have ALL THE CHATS & EMAILS in one place. Does Cryptocat use XMPP underneath?

from mailpile.

@brennannovak Yes, Cryptocat uses XMPP. I'd be happy to work with the Mailpile team on crafting a specific branch of Cryptocat suitable for Mailpile integration.

from mailpile.

@KAepora #awesomesauce come by our IRC chan #mailpile on freenode and lets make this happen, soon!!!

from mailpile.

If Mailpile implements XMPP, users should be able to bring their existing account(s), and XMPP federation should work.

Cryptocat isn't a general-purpose XMPP client. Using XMPP under the hood doesn't change that. From the perspective of a Mailpile user, Cryptocat looks like a walled garden: you can't bring or export accounts, or talk to people not using Cryptocat. That doesn't seem like the right choice for Mailpile's IM integration.

from mailpile.

Cryptocat's model offers several clear advantages over regular XMPP.

Since Cryptocat doesn't need usernames and passwords, Mailpile users can be offered a button to quickly switch from email to a Cryptocat IM. I think this is really the most productive user experience we can offer out of a collaboration.

Mailpile would show "Alice is also using Mailpile and is currently online! Start a chat!" Bob pushes a button, and Alice is offered the opportunity to launch a Cryptocat-powered chat between both.

from mailpile.

That's similar to the way we are going to integrate CryptoCat within GlobaLeaks https://docs.google.com/a/apps.globaleaks.org/document/d/1L8yVgarISeIxIvsFgoT3cF1MYzhEa6YyZzOAsAvR-yY/edit#heading=h.uy6v6v4hhyt4 .

However within the MailPile context, it would make sense to adjust it in a way that it can use the existing "identities" in order to provide persistency of keys.

Is it required a major rework of cryptocat or just minor changes here and there to do that?

from mailpile.

Cryptocat and XMPP support aren't necessarily mutually exclusive, right? I'm not a cryptocat user, but I can see why it would come in handy to be able to easily start a secure conversation via cryptocat.

At the same time, it could be just as easy to implement XMPP with OTR and / or GPG-Support. There are Python implementation of OTR around, and while I have not checked for XMPP GPG Libraries for Python, it should be possible to implement one if there aren't any around.

So, why not add support for Cryptocat AND regular XMPP?

from mailpile.

@KAepora that sounds like an excellent use case & would definitely be a great addition to the Mailpile user experience! Re: next steps to make this sort of thing happen, email us or hop on IRC once you're ready to hash out more details!

from mailpile.

Any news on the ConverseJS XMPP chat client integration? Would be awesome!

from mailpile.

Sorry, no news. We're severely resource constrained at the moment (just me, and I only just got back from my honeymoon), and still struggling to get the basic mail client working. This is not happening until post-1.0, unless some third party steps up and contributes the code. Anyone interested in working on that should find me on IRC!

from mailpile.

conversejs.org looks a bit outdated, it would be much better to see something like Slack built into Mailpile with support for various chat protocols, XMPP, IRC and etc.

Email, instant messaging, it's all about communication, I don't see why these should be separated.

Each chat session could be just another thread, where each message - just another mail message. This way we could have unified communication experience where difference between writing an email or instant message would be very thin.

This unification would let us to treat all chat session as regular mail threads, with possibility to tag, search, filter, etc.

A chat session should be a session where delay between messages is quite short. If no messages are written in say 8 hours, new message would create new chat message.

Chat sessions should be possible for both private chatting ant for chatting in a group (channel).

Also, chat sessions (threads) can be intermixed with emails. For one could replay to a message, select another From: account, and replay would go as email.

That would be awesome.

If you think, that this idea is logical, I would be willing to contribute some code. I can write backend Python code, but I would like to stay away from the frontend.

from mailpile.

@sirex I'm glad that this feature is getting some attention, but I don't think rebuilding chat and e-mail is the solution here. ConverseJS is a working client that can be added to any web page, so it is a simple solution that should not require too much implementation.

from mailpile.

I'm not suggesting to rebuild chat and email. I just suggesting to move chat implementation to the backend, instead of introducing new UI functionality in the frontend detached from all the rest functionality of Mailpile.

ConverseJS only supports XMPP, there are requests already about supporting IRC, Facebook Chat, Text Secure and probably other protocols.

ConverseJS is completely separated solution from Mailpile, it means, messages will not be stored encrypted as all emails, there will be no possibility to search for messages using Mailpile search engine, there will be no possibility to use tagging and organise message sessions in the sidebar, no integration with contacts.

I think it is much better, to leave whole Mailpile user interface as it is now, with very small additions. Here are the additions to the UI that I see would be needed:

• In account settings form, it should be possible possible to select protocol. After selecting protocol, account settings possibly can have slightly different protocol specific options.
• New way to reply to the email messages should be introduced. Message should be sent on Enter press and when replaying, quoting should be turned off by default. Something very similar as in Facebook Chat.
• It should be possible to pin chat sessions to the sidebar as it is done in Slack.

That is it. All functionality available in Maiplie, that works with emails, should also work with chat messages, because chat messages would be stored as emails.

In the backend, alongside POP3, IMAL, new protocols could be added: XMPP, IRC, etc...

There are Python libraries for all the protocols already:

https://pypi.python.org/pypi/sleekxmpp
https://pypi.python.org/pypi/irc
https://pypi.python.org/pypi/fbchat/

Here is example of full workflow for adding XMPP:

1. From Home screen I press Add account button.
2. Select XMPP protocol, and fill the form (needs UI improvement).
3. When new message is received you will see Inbox (1), unless you specified different tag to direct messages to.
4. When you open Inbox (1) you will see your new chat session thread.
5. When you open chat session thread, you can reply to it by filling reply input field and message will be sent by pressing Enter (needs UI imrovement).
6. You will be able to pin chat session to the site bar in order to be able to see, that new instant message received, usually you want to reply to instant messages faster than to email.
7. You can tag, search, filter, organize, encrypt, sign, configure, replay to instant message using different account and do everything what you can do with emails.

For all this to work, backend should be able to handle multiple protocols. Currently backend supports IMAP and POP.

Interesting thing, if an account would be configured to receive messages from XMPP, but sent using SMTP, then you could reply to all instant message using email... :)

from mailpile.

@sirex The kind of seamless chat integration you're talking about sounds great. The question is, who's going to do all the hard work of writing the software required to make it a reality? Are you going to do it, or are you just the ideas guy? ;)

from mailpile.

@jcbrand I could dedicate few weekends on this, only on the backend part.

from mailpile.

Hello @jcbrand, @sirex. :)

A small technical note; if you treat every single chat message as an e-mail, you will break Mailpile. One of the core assumptions of the app is that a user has a "reasonable" amount of mail, message counts in the hundreds of thousands or low millions can be handled by our current design on commodity hardware. If you treat every single line of a chat conversation as a full message, you break that assumption, increasing the "message count" by approximately two orders of magnitude and fundamentally break Mailpile in the process.

So the design you've drafted above, @sirex, is a non-starter. It won't work without a bunch more work to handle scalability, either by merging conversations into individual "messages" (doable) or revamping the entire message catalogue/search engine (hard).

Further, I am increasingly of the opinion that chat and e-mail are quite different.

E-mail is an exchange of long-form documents and there is an expectation that messages are archived and have a long lifetime. Chat and conversations on the other hand are more ephemeral, recording every word that is said and storing forever in a search engine may go against reasonable user expectations. OTR is cool because it mathematically preserves the implicit ephemerality of a conversation. Being able to have an ephemeral conversation is a useful tool. If we design our chat in such a way that everything is logged and searchable, we have broken that tool.

Food for thought, hm? :-)

from mailpile.

Well if current search index is not scalable enough to handle single person's instant messages, then I guess search index should be fixed in first place.

Combining all conversation session to single "email message" is also an option. Gmail currently combines conversations to single message, and I really like that they are searchable.

The question is, is it aright, if single searchable message will be updated frequently, by appending new instant messages to it?

from mailpile.

@sirex as per @BjarniRunar comments, I did some experiments
towards this goal that could be beneficial if you were serious
about putting in a few weeks of work. If you were, I would be
keen to help here and there UI wise, as I'm reaching "peak
mesaging clients" and it's making me come unglued slightly- any
given day, I have Mailpile, Pidgin, Pond, TextSecure, Peerio,
Twitter, Slack, and IRC open... it's kinda ridiculous.

This page on our wiki is a suggestion of something that wouldn't
break Mailpile by offering an email-esque approach to saving
bunches of chat messages

https://github.com/mailpile/Mailpile/wiki/Social-Messaging

I had worked on a little script that saves a users Facebook
messages and attachments formatted in this fashion as emails in
the above format

https://github.com/bnvk/social-archiver

Bjarni's points about OTR does hold weight. However, clients like
Pidgin also break this assumption by allowing logging of OTR
chats. Seems like a respectful compromise, would be make your
chat client sent an automated message saying "this chat is being
saved by SuperChatPile" or what have you :-)

from mailpile.

Hi @BjarniRunar, I generally agree with you about messages being more ephemeral.

If it was up to me, I'd definitely pick the low-hanging fruit. Integrating converse.js would immediately provide a lot out of the box.

The whole UI is already done, so nothing needs to be added there, at least not for an MVP.
All you need to do is to load converse.min.js in your HTML and then call converse.initialize.

On the server side, what's left is to store the user's XMPP credentials in the Mailpile DB and to create an authenticated session.

Mailpile uses Django, right? There already is Django integration for converse.js. See here: https://github.com/TracyWebTech/django-conversejs

That's it. That would be an MVP.

Granted, it would not provide the level of integration @sirex is talking about, but it would provide chat at a miniscule fraction of the effort that would be required to implement what he's talking about.

from mailpile.

@bnvk

if you were serious about putting in a few weeks of work.

Not few weeks, but few weekends.

I just looked at the code, mailpile/mail_source/local.py does not look very complicated. So I guess, I will try to experiment with a very simple xmpp mail source implementation some time this month and will see where it leads.

from mailpile.