Some people would say that's a good thing. I think the more important point is that it's 100% under the control of the organization or users who deploy it.
If you disabled or drastically resized the avatars and put the usernames not in a separate line, the window could hold a lot more content for single-line conversations like that.
If they wanted to borrow from Slack (as they have for so much of the UI), they could make that toggleable. Slack lets you disable avatars entirely and/or switch to a single-line view.
I'm curious how E2E encryption (OTR e.g.) could be implemented with a client like this (preferably without having the keys leaked all over the place), it's the only interesting feature I miss from a quick glance.
Unfortunately, this won't improve your security. The client code comes from the server, so you need to trust it anyway. While it is possible to implement OTR or PGP in the client, the server admin could poison the implementation code and leak your private keys.
> The client code comes from the server, so you need to trust it anyway.
Sure, but we have TLS for that. E2E is still needed to cover everything else (e.g., I trust the server now, but I don't want to have plain-text logs on it in case the feds seize it).
OTR also breaks Message Archive Management (MAM) and Carbons - the two features making multi-client operation any useful, and highlighted in the article. And with MAM, there actually are plain-text logs of your conversations on the server.
The call is still open on end-to-end encryption over XMPP when multiple devices (or more than two parties) are involved.
The issues you list (message archive being plain text, key management when multiple recipients are involved, maybe even transparently) don't seem to be XMPP specific.
Is there any chat system out there with end-to-end crypto and reasonable support for multiple devices?
They aren't XMPP specific, but OTR as implemented in e.g. Pidgin goes above and beyond in making them bad – archiving is either plain text or disabled, keys cannot be changed at all (so not even manually syncing them is possible), and session handover doesn't work (there's a session management implemented, but it doesn't do anything except silently eating messages).
In my opinion, it doesn't matter if it looks like Slack. What matters is that I can deploy it on an existing infrastructure and still have control over the service instead of handing over control to a third-party.
"Familiar", eh? To me it's still "that weird new hipchat competitor people keep talking about", but it's still something operating at a couple of degrees' remove: I've never used it or met anyone who uses it or heard of any reason to use it, and the one time I went to the website it wasn't clear that there was any way for random people to sign up for it. I'm curious why you see it as the established standard - isn't it basically brand new?
Slack built up $11m in annual revenue in a really short time, and is adding $1m in contracts every 11 days. At what's about $7/person/month, that's a lot more than no one.
Let's chat is really neat, I've played with it a lot but I have to say that the combination of not supporting OTR & The fact that it relies on MongoDB put me off using it in production to replace our existing chat server.
> What matters is that I can deploy it on an existing infrastructure and still have control over the service instead of handing over control to a third-party
And its nice to be able to choose which apps you want to use on all the different platforms; and choose differently than everyone else. The app that works for me isn't necessarily the app that works for others, but I still want to be able to talk to them using the app I want.
Besides of the ones referenced in the article, there is also ChatSecure [0] for Android and iOS (with a strong focus on security) and Xabber [1] and yaxim [2] for Android (I am the maintainer of yaxim).
Not sure about ChatSecure, but xabber provides MUC (group chat) support out of the box, and for yaxim there is a beta APK you can get here: https://yaxim.org/muc
The beta's limitations are:
* rather broken invitation handling user interface
Also Conversations doesnt allow for customer server IP address so it's unusable for me. Yaxim does which is why I will have to stay with it. Custom IP server addresses are important if you have DNS/NAT complications within your internal network compared to outside.
In my experience, prosody has an easier to configure (and thus harder to fuck up) LDAP integration, and while ejabberd's core is solid, the modules vary wildly in quality (I never managed to get mod_shared_roster_ldap to work, e.g.).
Actually we (most of the XMPP network) switched over to mandatory encryption last May and IMHO it's been pretty successful so far. Google is welcome to join the party anytime! :-)
Can you explain, or point me to an explanation of, _in detail_, exactly what GTalk broke in terms of federation?
I find that in practice I can _sometimes_ communicate with _some_ users from _some_ clients, but it seems like it's flaky and there's not a clear pattern to it. Do you have any deeper insight?
Most of the XMPP network switched last year to REQUIRING encryption for one server to talk to another server. Google doesn't support encryption at all for server-to-server links, and thus servers like jabber.org (of which I'm the admin) can't talk to Google anymore. See more at https://github.com/stpeter/manifesto/blob/master/manifesto.t...
It's not hard to get a UI like Slack's. The actual chat window is just like what IM clients have used for decades. One side has the contact and chat room (channel) list combined instead of in a separate window. Like in IRC instead of XMPP and other chat systems. Put the settings and away management in a header or footer and you've got slack.
It's not like it's revolutionary. They put two and two together in the only reasonable manner for a single-page application.
I'm planning on setting this up for myself later today but a few questions before I do that:
- Will this stay connected to my account and the history will be there if I close the tab / browser / computer in the meantime?
- Is it possible to replace certain strings with images? This is not at all an important feature but just something I got used over the years. (Example: :string: replaced with image.png and displayed inline. That's possible with Adium but I'd really like to replace Adium)
I don't think that applies. Unless I misunderstood the GP.
I understood the question as "will I be able to receive messages while the tab isn't open" (offline messages) and "will I be able to read my history on a different device later on" (MAM). Carbons serve a different purpose and sync connected clients (i.e. you chat on your desktop, but your phone receives the same messages as a carbon copy to stay in sync).
I think this is great. If there were more people pushing clients like this, not only will it push the guys who already make money off of it, but we can do a better job coming up with new communication ideas as a whole.
I'm ONLY using Hangouts because they don't allow group messaging in any other client. I'd like to see that change!
OK, my bad: The oldest RFC is just "experimental" while the newer ones are "informational", and explicitly stating "It does not specify an Internet standard of any kind."
No wonder its not standardised, considering that almost any server out there uses a different, partly incompatible set of extensions (for server-to-server communication, at least), depending on which servers it was forked from (very few are not in some way derived from the original ircd[0]).
There's also http://matrix.org ; though it's not going down the RFC route (at the moment at least).
</blatant self-promotion>
There seems to be this general assumption at the moment that a) XMPP is the only open chat protocol about and b) its dead, so everyone decides that the only logical course of action is to write and use custom proprietary protocol. This, of course, massively sucks from a UX perspective where I end up having 100s of identities and apps and logins that I use (semi-)regularly to not just chat with people, but also comment on articles, discuss things on mailing lists etc.
(Long time lurker, only a reader till now)
I've been looking for something like matrix for quite some time now (albeit probably in the wrong direction) and it seems like a really cool project. I've been wanting to build a chat application on top of a chat protocol like that for ages! Its a big boost to finally get started. Thanks!
Edit: whoops, I had commented once before, it was just so long ago that I forgot about it!
Maybe this only matters to me, but my biggest gripe with IRC as a protocol is the lack of embedded newline ability. Take away newlines and now you've prevented atomic code snippets and killed newline sensitive markup suck as Markdown.
I deeply appreciate the history and communities available on IRC, but as a protocol, good riddance to it.
screen + ssh + irssi (+ bitlbee, if you need xmpp) > any web based solution. Why? Because I can see it on my phone and on my laptop, and it's as lightweight and simple as a `ssh -t irssi.myDomain.foo screen -DD -R` and I'm all caught up.
This is, ofc, my $0.02. Stuck in the old way of doing things, I guess.
Except for being almost unusable on smartphones (or barely usable on devices with qwerty keyboards), and bitlbee's arcane syntax for joining MUC chatrooms, this is the exact setup I am using.
I don't have any trouble at all using Colloquy on iOS and connecting back to my bouncer. It's about as seamless as you could expect all things considered.
Does your bouncer let you view the full scrollback from multiple clients, without having to keep them constantly connected (and preferably without lagging out one's mobile client when it connects and the bouncer deluges it with old messages)?
There are a few different solutions for this out there, especially clients that run some custom protocol between the GUI and the bouncer, like Quassel and Smuxi - but I've tried both, and each both (a) has poor mobile support and (b) once you get used to it, turns out to just suck in general. (These opinions are a few years out of date, though.)
Thankfully I don't actually care much about mobile support: I don't use IRC for time-sensitive discussions, and for recreational purposes, trying to participate in a real-time conversation where everyone can type several times faster than you is, IMO, a pain; I'm faster at typing on iOS than I used to be, but it's still just not comparable to a real keyboard. Better to save the chatting for when I have one. But I find ssh+screen an unacceptable solution: partly because of issues with notifications (i.e. out of the box, there are none) and copy+paste, though both can be fixed in theory, but mainly because of the latency. When the letters I type don't appear for 100ms or more, it really trips me up and I make a lot more typos. I could find a server with less latency at home, but that wouldn't help when traveling, especially on an unreliable connection - even though there is no fundamental reason chat should be latency sensitive in the slightest. Tried mosh (ssh + prediction) as a compromise for a while, and it works better, but it has some issues and doesn't fully hide the latency.
These days I'm using Glowing Bear, the web-based remote for weechat (that uses yet another custom protocol). Latency's gone, and like other web-based clients it has the neat feature of embedding YouTube videos and images, so I'm finally pretty satisfied with my IRC setup. (And I can be paranoid about security and run it on localhost rather than using their website directly.) But there are disadvantages: Glowing Bear is somewhat feature poor, it (again like other web-based clients) is relatively slow to render, and there is no native iOS weechat remote. (Guess I could still use weechat as a regular bouncer, or perhaps try Glowing Bear from mobile Safari...)
No, nothing I use supports synchronizing scroll buffers beyond ZNC's behavior of dumping the scroll buffer to whichever client is connected (Colloquy on iOS, Textual on OSX). I've not found the dumping behavior to be that terrible, but I don't frequent very popular channels so it's generally not pumping out thousands of lines every time I open the app. For the most part that doesn't inconvenience me, I can respond to any pings or queries as necessary and catch up on conversation. If I need to review anything outside of ZNCs buffers it's a super quick task to just go and read the logs from disk. The main critical feature is not losing private messages and pings when moving between client, which ZNC achieves without fail.
Like for you IRC isn't anything beyond recreational for me, so quirks in the workflow are just fine to work around. If it was my primary method of communication I'd be looking into improving it I suspect.
How do you get notifications, particularly on your phone? With e.g. AIM I have an equally lightweight experience on the laptop (just browse to the URL), a functional app on my phone, and, crucially, push notifications that alert on my phone.
Me neither. This is the first client that actually piqued my interest… but useful E2E encryption is still an unsolved problem, it seems. (OTR is a usability nightmare.)
What prevents me from adopting XMPP for my team is the lack of push notifications to my phone. I don't want to have an app constantly maintain a connection and slowly drain my battery.
The Conversations app for Android works pretty well. I've used it for a few weeks with a handful of persistent rooms on a Nexus 5 and I haven't noticed any battery issue.
Some years ago I built an Android SDK that did background location and had an XMPP channel open for push notifications. This was before Android had Cloud Messaging available. Battery drain was minimal/negligible.
There has been a deluge of web chats lately (which is a good thing).
Has anyone tried Let's Talk, Shout, Echoplex, and/or Kaiwa in practice and have some experiences to share? Stability, searchability, general functionality?
No mention of OTR. :-( When your client is a Web app on a trusted server (i.e. OTR key on the server), you could avoid multi-client issues by having only that on XMPP client that you connect to from multiple browsers.
Came here to say just this. I've been looking for a replacement for our Openfire server for some time now, but there just hasn't been anything that's quite there yet.
141 comments
[ 2.9 ms ] story [ 260 ms ] threadcentre is basically a copy of hipchat...
Sure, but we have TLS for that. E2E is still needed to cover everything else (e.g., I trust the server now, but I don't want to have plain-text logs on it in case the feds seize it).
The call is still open on end-to-end encryption over XMPP when multiple devices (or more than two parties) are involved.
Is there any chat system out there with end-to-end crypto and reasonable support for multiple devices?
Besides, it is not available for non-Apple devices.
TextSecure/Signal has a robust crypto system, and they are working on multi-device support.
How about hosting E2E js lib somewhere like on Github and include them there?
Or you can always map to local js files.
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
http://www.businessinsider.com/slack-growth-after-one-year-2...
[1] https://talqee.com
hillarious way to advertise, chum.
And its nice to be able to choose which apps you want to use on all the different platforms; and choose differently than everyone else. The app that works for me isn't necessarily the app that works for others, but I still want to be able to talk to them using the app I want.
[0] https://chatsecure.org/
[1] http://www.xabber.org/
[2] https://yaxim.org/
The beta's limitations are:
* rather broken invitation handling user interface
* cumbersome MUC joining user interface
* impossible to downgrade to non-beta builds
Is there a reason why you chose Prosody over MongooseIM or ejabberd?
1: https://github.com/otalk/otalk-im-client/compare/master...di...
I find that in practice I can _sometimes_ communicate with _some_ users from _some_ clients, but it seems like it's flaky and there's not a clear pattern to it. Do you have any deeper insight?
It's not like it's revolutionary. They put two and two together in the only reasonable manner for a single-page application.
- Will this stay connected to my account and the history will be there if I close the tab / browser / computer in the meantime?
- Is it possible to replace certain strings with images? This is not at all an important feature but just something I got used over the years. (Example: :string: replaced with image.png and displayed inline. That's possible with Adium but I'd really like to replace Adium)
Thanks!
I understood the question as "will I be able to receive messages while the tab isn't open" (offline messages) and "will I be able to read my history on a different device later on" (MAM). Carbons serve a different purpose and sync connected clients (i.e. you chat on your desktop, but your phone receives the same messages as a carbon copy to stay in sync).
I'm ONLY using Hangouts because they don't allow group messaging in any other client. I'd like to see that change!
Haven't they heard about IRC (RFCs 1459, 2810–2813)?
https://www.ejabberd.im/mod_irc
[0] http://en.wikipedia.org/wiki/IRCd#/media/File:IRCd_software_...
That and the use of hashtags to group things together on Twitter, etc.
I guess it's just a "thing" now.
</blatant self-promotion>
There seems to be this general assumption at the moment that a) XMPP is the only open chat protocol about and b) its dead, so everyone decides that the only logical course of action is to write and use custom proprietary protocol. This, of course, massively sucks from a UX perspective where I end up having 100s of identities and apps and logins that I use (semi-)regularly to not just chat with people, but also comment on articles, discuss things on mailing lists etc.
Edit: whoops, I had commented once before, it was just so long ago that I forgot about it!
MSN Messenger's protocol was submitted to the ECMA in 1999, but MS made changes to their implementation almost immediately that were never documented.
I deeply appreciate the history and communities available on IRC, but as a protocol, good riddance to it.
This is, ofc, my $0.02. Stuck in the old way of doing things, I guess.
Still pretty cool, particularly the deploy on DO.
There are a few different solutions for this out there, especially clients that run some custom protocol between the GUI and the bouncer, like Quassel and Smuxi - but I've tried both, and each both (a) has poor mobile support and (b) once you get used to it, turns out to just suck in general. (These opinions are a few years out of date, though.)
Thankfully I don't actually care much about mobile support: I don't use IRC for time-sensitive discussions, and for recreational purposes, trying to participate in a real-time conversation where everyone can type several times faster than you is, IMO, a pain; I'm faster at typing on iOS than I used to be, but it's still just not comparable to a real keyboard. Better to save the chatting for when I have one. But I find ssh+screen an unacceptable solution: partly because of issues with notifications (i.e. out of the box, there are none) and copy+paste, though both can be fixed in theory, but mainly because of the latency. When the letters I type don't appear for 100ms or more, it really trips me up and I make a lot more typos. I could find a server with less latency at home, but that wouldn't help when traveling, especially on an unreliable connection - even though there is no fundamental reason chat should be latency sensitive in the slightest. Tried mosh (ssh + prediction) as a compromise for a while, and it works better, but it has some issues and doesn't fully hide the latency.
These days I'm using Glowing Bear, the web-based remote for weechat (that uses yet another custom protocol). Latency's gone, and like other web-based clients it has the neat feature of embedding YouTube videos and images, so I'm finally pretty satisfied with my IRC setup. (And I can be paranoid about security and run it on localhost rather than using their website directly.) But there are disadvantages: Glowing Bear is somewhat feature poor, it (again like other web-based clients) is relatively slow to render, and there is no native iOS weechat remote. (Guess I could still use weechat as a regular bouncer, or perhaps try Glowing Bear from mobile Safari...)
Like for you IRC isn't anything beyond recreational for me, so quirks in the workflow are just fine to work around. If it was my primary method of communication I'd be looking into improving it I suspect.
Quick google found https://github.com/paddykontschak/irssi-notifier/blob/master...
I don't bother with it though. If I'm away from a computer, I don't need to see it.
I love to receive feedback (of any kind), as it's the only way we know what we're doing right and wrong!
I think that should say "servers" plural.
Has anyone tried Let's Talk, Shout, Echoplex, and/or Kaiwa in practice and have some experiences to share? Stability, searchability, general functionality?
If I remember correctly, "Kaiwa", was the codename for the first Macromedia's Flashcom Server (before Adobe's acquisition).
Flashcom Server at that time made it possible to run 2+ ways multi-threaded communication (audio/video) via the Flash Player (2003-ish).
lolnope