Open Sourcers Race to Build Better Versions of Slack
wired.com
wired.com
Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts?
Some sort of open protocol.
Urgh, I've been working on this lately and the entire field is depressing. Between one side that doesn't understand the legitimate need for open protocols, and another side that doesn't understand why IRC isn't the end-all-be-all of group chat (and why UX matters), it's just people talking past each other.
Every new attempt at making "the slack killer" makes this problem worse, because it comes with its own protocol. Its own users. Etc.
PS: If somebody has free time to work on an open source multi-protocol group chat gateway, email me, I have something started.
Even federated networks eventually gravitate towards a large degree of centralization once the tech becomes mainstream (see email). If any servers are used at all in a privacy-minded app, they need to be zero-knowledge as far as I'm concerned, for actual user data at the very least, if not metadata as well (I realize the latter is an unsolved problem).
How does Actor handle user data and message storage?
Also we had Tor-enabled client, but Tor is not suitable for mobile apps.
At least that's how I read Slack's security page (https://slack.com/security-practices) that only talks about "Data Encryption In-Transit" (i.e. server-to-client) and Mattermost's About page (https://about.mattermost.com/) that also talks (only) about encrypted "client-server data transmission".
I do agree that end-to-end encryption is important, but at least Matrix is aware of this and they are working on it (https://matrix.org/jira/browse/SPEC-162).
I definitely appreciate that the Matrix team is aware of and actively working on E2E encryption, but it doesn't change my stance that Matrix is not a feasible building block for privacy-minded apps until that work is complete.
Now, a more interesting privacy concern is that Matrix doesn't and can't protect metadata currently - see https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E... for details. So if you want both encrypted contents as well as obfuscated metadata, go check out Ricochet or Vuvuzela or Pond or something for now :)
For now, building a great federated chat protocol that allows users to fully control their own data should take priority over just about everything else, because once users are in control of their own data, they're no longer locked to a single platform. So if another protocol comes along that does everything Matrix gets right and adds metadata protection, users can simply export their data and import it to the next great app/protocol (which is hopefully also federated). Until we have a great federated protocol that everybody is using, the friction associated with moving between chat apps/protocols is going to continuously inhibit real innovation in the messaging apps space by favoring apps that stand on the strength of their network effects over apps that stand on their own merits.
On the topic of fully distributed apps, I really like what replikativ is doing in this space:
https://github.com/replikativ/replikativ
It's a CRDT-based data replication library for building fully distributed applications. They envision replikativ being used as an open data exchange whereby users fully control their own data, and can specify any number of applications to have access to that data, instead of the status quo where user data is kept in closed, per-application silos. Their README has a much more comprehensive overview of the library and their vision.
I'm hoping it's still on some sort of roadmap.
It looks like an interesting platform, but I was a bit surprised by what I found at:
https://developer.actor.im/docs/encryption
"MTProto v2 Rev3 enables encryption support to replace or enchanse TLS one." So far so good - here's someone that's built on top of NaCl and built a legacy-free encryption system on top of well tested, known primitives, I thought.
But: "Actor encrypts message with US encryption and then again encrypt with Russian encryption that in result guarantee absolute encryption streight" (sic).
Uh. This sounds like applying a "political" reasoning to layering security: AES might be backdoored by NSA, GOST(?) might be backdoored by the FSB -- but using both, only double-agents will be able to foil our encryption!
While the truth is probably that you're know vulnerable to buffer overflows or other more mundane software errors in the now double-sized encryption code -- and get none of the (potential) benefits of a clean, modern architecture on top of just NaCl?
In addition, it appears you also use curve25591, possibly an implementation derived from NaCl:
https://developer.actor.im/docs/securing-server
"For secure communications Actor Server have to be configured with Curve25519 keys. To generate them, use actor-cli util:"
So that's three codebases worth of bugs, rather than one. Any plan to simplify this part?
US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementation can contain bugs, yes, but i can guarantee that there are no timing or overflow attacks possible. Even when we will have broken russian layer, us layer will be safe. Also we are on the way to make everything verified by 3rd parties and seal cryptography parts.
For key exchange we use curve25519. Implementation is taken directly from Signal and this app is trusted by majority.
We
[ed: Oh, and here I go, proving that non-cryptographer should be careful about what they say wrt encryption, apparently AES isn't a feistel cipher? http://crypto.stackexchange.com/questions/10605/why-is-aes-n... ]
> Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform.
It's a pretty strong claim to say that you take three different encryption primitives, implemented by other people in java, and translate them to other languages -- and can also be sure there are no timing attacks? (Or oracles, or resulting errors)?
Surely it would be easier to stick to as few lines and layers as possible if you want it to be easy(er) to audit?
(So simple there's obviously no mistakes, vs so complex there's no obvious mistakes and all that).
It's a bit like saying you made a boat out of wood for buoyancy and filled it with sand in case the wood catches fire. Sure, a plank of wood doesn't sink, but too much sand can make it sink, and sand won't be of much help if there is a fire. A wooden boat is better than one filled with sand.
I'm not sure how the fact that the boat was made in Java is relevant, either. If anything, it makes it harder to prove that there is no timing attack, as the JIT could do unexpected things, long after the program has started.
How do other servers know how to reach me?
What about Spectrum http://spectrum.im/ ? I am successfully using Spectrum as gateway to Skype (except groupchats ATM, some bugfixing pending) and IRC from my XMPP client apps.
What about XMPP in the whole? It looked depressing few years ago, but times have changed, I can help you to catch up with nice novelties.
I'm personally working on Movim, a nice-looking "Social-IM" client fully based on XMPP (https://movim.eu/). The main goal of the project is to show that we have now all the tools to build a decentralized, standard and universal IM (and also social !) network without reinventing the wheel again and again.
You can have a look at our latest release-note as well https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e3122... (this blog post has been published/edited using Movim and XMPP ;)).
And Movim is also compatible with Spectrum to offer interconnection with other networks ;)
Can you recommend a few? I haven't looked into XMPP in detail for a while, because the clients I've been using are "good enough and I didn't bother with mobile), but it seems like I'm missing out on good things ;)
For the desktop there is no real "modern" client yet, unfortunately. But I've ported Movim using Electron :) There is already a Ubuntu/Debian version and the package is here https://github.com/edhelas/movim_electron.
XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…
XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.
This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.
The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.
Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'.
Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support).
I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.
XEP-0313 is a modern replacement, focusing on just the things that people actually need. It's implemented in many servers and clients already (see https://www.zash.se/mam.html ). It's still under development, but it's already in active use by many people.
This is why nobody wants to touch XMPP with a ten-foot pole.
Honestly, there's some days I wonder if there's any way to win.
And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd
You'll see that on the server side at least XMPP is very well catered for.
Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment.
It also does need at least 512MB RAM which rules it out on embedded devices.
It's a real damn shame because XMPP is pretty awesome. It's open for one, can be made super secure with OTR (client-2-client encrypted chats), has numerous protocols and implementations for stuff as diverse as message archiving, Audio/Video signalling, file transfer, chat (of course), presence and an absolute boat load of other stuff: http://xmpp.org/extensions/index.html.
There are two big issues as far as I can see with XMPP which really hurt it:
1. XMPP was incredibly poor at handling high latency, intermittent network connections (like cellular). Connections would time out, reconnections would take ages and all in all it really hammered battery life. As a consequence mobile app developers moved very quickly onto REST/JSON (yes there was XEP-0198 - Stream Management - but implementations of it were thin on the ground and even then it wasn't perfect).
2. There just isn't any interest amongst new developers or newer projects at least in an XML based chat protocol when REST/JSON is so attractive. Anyone who has had to write a god damned XML parser knows what I'm talking about.
Things are a whole lot better now. XMPP has fixed a lot of session and battery life issues since then but to be honest I'm just not feeling it when I go to XMPP meetups. Feel like I'm attending a wake for an old friend and it really is sad because if there was ever gonna be one protocol to rule them all XMPP was far and away the best candidate.
Who knows, a couple years from now large companies and governments might finally wake up to the fact that they have 100 different sucky (probably) REST based APIs amongst all their apps which are not remotely compatible and offer poor archiving and retrieval (like they did in the 90s when they forced Microsoft to open up their Office document format). XMPP might come to the fore again then (wouldn't put money on it though). More likely something similar (and not XML based) will take its place.
It's anyone's guess really, suffice to say the present situation does feel like a complete and utter mess and will really start biting us in the ass when compliance asks 'how do I archive/retrieve this pot pourri of data'.
What are your thoughts on Matrix?
Reminds me of what the Layer guys were trying to do (at least in their initial mission statement). https://layer.com
Pros of Matrix are that it looks like they have full chat support, are working on adding end to end encryption, and of course have federation which is super important for interoperability.
Only concerns with Matrix are that I don't see any large projects or companies spearheading it. Also seem resource constrained. For example it looks like they planned on rewriting their existing basic server side app in C and then ended up just writing a proxy. So clearly it's still a small project. Also see verbs in their URIs...I'm not super up to date on REST best practices but isn't that a no-no?
Anyways early days - and it's easy to nit pick. Matrix certainly looks compelling enough that I'd be interested in trying it and seeing them succeed. God knows we need something like it and soon.
In terms of resources: a bunch of us are paid by our dayjobs to work on Matrix fulltime, and meanwhile there's a pretty active wider community surrounding the project. However, the 'core' project of building a spec, reference server, reference+glossy web and native ios/android clients, as well as loads of bridges really is a significant amount of work, and we're going as fast as we can. https://www.openhub.net/p/matrixdotorg gives an idea of progress (although only seems to spider a few of the core projects). I wouldn't really call Matrix a 'small' project :)
In an ideal world we'd stop the world and take N months to entirely rewrite Synapse (~40KLOC of rather dense Python/Twisted) to Go/Rust/C++/Java/Node/whatever, but that's N months we don't have right now. It's not really the lack of resource, but the fact that the window is rapidly closing to provide an interoperable fabric between all of these proprietary communication apps (be they open source or commercial licensed), and we want to get a stable solution out there before it's too late and we end up in a world where the silos have won (c.f. social networks).
Hence the pragmatic decision to do an incremental migration from Synapse to Dendron, which is our next-gen homeserver written in Go (not C). Dendron is indeed mainly 'just' a proxy for now, but this is actually incredibly cool as it can act as a Matrix-aware loadbalancer across multiple Synapse backends. The horizontal scalability and HA this gives is a huge deal. Meanwhile, it gives us a way to gradually migrate endpoints from Synapse into Dendron and provide a way to replace the Synapse codebase without having to do a stop-the-world rewrite. Personally, I think this pragmatism is ftw.
In terms of verbs in URIs... we've been pragmatic rather than religious about REST naming conventions; if someone can give concrete reasons to rename endpoints before we freeze the spec, please tell us! Bugs to http://matrix.org/jira/browse/SPEC and PRs to http://github.com/matrix-org/matrix-doc please ;)
And whatever, please do come hang out on #matrix:matrix.org and #matrix-dev:matrix.org eitherway if you want to find out more and help us escape beta!
Well, it failed to be the preferred solution for its problem domain, and is universally ignored by big players.
Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).
For example, suppose you want to send an IM to your friend. You believe in XMPP or some other open/federated protocol, but you don't know which friends use the protocol. Piggyback off email. Note that identities are backed by email. Also, if any identity-providers refuse to join the federation, then route through a trusted fallback service (Trent.com). Pseudocode:
function send_im(toEmailAddr, messageText) { // See if the user's domain already supports OpenChatProto. if (nslookup(toEmailAddr.hostname, 'SRV', 'OpenChatProto')) return OpenChatProto.deliver(toEmailAdrr, messageText);
// If user's domain doesn't support it, see if the user has
// registered+authenticated with a trusted third-party.
var proxyAddr = http.get('https://trent.com/proxyAddr?email='+toEmailAddr + authCode);
if (proxyAddr) {
return OpenChatProto.deliver(proxyAddr, messageText);
}
// If the user doesn't exist in OpenChatProto, then
// fallback to email.
var emailText
= messageText
+ "To continue this discussion in real-time chat, go to:"
+ "https://trent.com/setup?email=" + toEmailAddr + authCode
+ "To block messages from this person, go to:"
+ "https://trent.com/optout?email=" + toEmailAddr + senderEmail + authCode
+ "To opt-out of all messages, go to:"
+ "https://trent.com/optout?email=" + toEmailAddr + authCode
Email.deliver(toEmailAddr, emailText);Note: It's most efficient if members of the federation agree on the identity of trent.com, but it's not required. Any outbound MTA could use a different Trent, but that fragments the brand and identity databases.
This feels pretty obvious, so maybe it's already being done or I'm missing something...
Google Talk, Facebook Chat, Origin (EA), Playstation, Cisco WebEx, WhatsApp all use/used XMPP for instant messaging.
That sounds like it's the preferred solution for realtime messaging, with vendor lock-in and NIH syndrome decisions being the major reasons that it isn't used in even more situations.
> and is universally ignored by big players.
As evidenced by the above list of major deployments, it is absolutely not "universally ignored". The problem (as someone else pointed out) is that for many of the "big players" a federated protocol is not what they want, so they don't allow federation, and don't allow/publicise the use of standard XMPP clients.
> Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).
This is a reason to stop using Google services, not a reason to claim XMPP is ill-suited to the task at hand.
Now we have more bandwidth, and sending XMPP as a server is negligible.
I just would prefer JSON to XML. :-)
Our service Sameroom (https://sameroom.io) is a commercial solution to the chat incompatibility disaster, not too different from an AC adapter thingy with a bunch of different plugs, one or two per continent.
After implementing the protocols of quite a number of these systems (~20), we're seeing a scary acceleration toward further incompatibility. It's good for our business, but really pretty bad for the world.
We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(
We provide a ridiculously expensive way to connect, say, Slack to Skype, which is ==great for Skype==, from almost every possible angle. It means Skype users can stay on Skype instead of switching to someone else's Slack team.
Email is much better in this way, since everyone gets a copy.
With Sameroom you essentially retain the carbon copy semantics of email, but with real-time collaboration. So, I'd argue that it's great for Slack.
By the way, well done on sameroom. I came across your product while working on the stuff I mentioned and it looks like an incredibly useful thing. I really wish you would open source it, though. (Or at least open source some libraries for talking to the protocols you deal with. Especially Hangouts.)
We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse.
That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.
Can I ask you some details on how you went about working with Skype and Hangouts? Did you do the reverse engineering yourself? These are protocols several popular open source projects have been trying to support for years and haven't succeeded.
Can I also ask you about your tech stack/languages you used for Sameroom?
Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time.
The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two years (https://medium.com/@abs/what-we-learned-from-sponsoring-an-o...).
Our frontend doesn't really matter as much, since it's just a dashboard, but we use TypeScript with Flux and React (it's been great).
http://www.theverge.com/2014/4/21/5635488/msn-messenger-vs-a...
https://sfconservancy.org/copyleft-compliance/principles.htm...
Unfortunately working on GPL compliance is expensive, I would encourage anyone who cares about copyleft to support the Software Freedom Conservancy's efforts.
Nobody is getting sued yet, and Pidgin supports all of them nowadays.
And all IRC implementations are "interoperable" in the sense that a single client that implements the protocol can connect to any of them, this chart seems to be padding things a lot by calling every IRC server network a "chat service". A number of them also have or have had interconnects with each other in the past.
Good luck, you are working on an important problem.
Thank you!
About getting fired - not if we sell our solution to your IT :) They might like it, actually, since they can a) provide something useful to their user base and b) get a better handle on the chat situation.
Especially Jabber/XMPP was created to fix that issue by standardizing the protocol. The idea is that IM would be like email - no central server.
Others (GTalk, Facebook, WhatsApp, HipChat to name few) started implementing it but did not enable server to server communication (ok GTalk did, but as soon as they became popular they intentionally broke it with Hangouts).
So now we have bunch of services that use same protocol but still can't communicate with each other, the XMPP seems like it is dying.
A while ago there were plenty of server-side transports to help migrate to XMPP, but it doesn't seem like they are no longer being developed.
I don't understand why no one cares anymore about decentralizing and standardizing IM.
(We have SMTP, a must-have.)
There is no such thing as a "nice-to-have" universal protocol.
The problem is non-techies do not understand why email is good while messaging is bad. There is no indication as to where these problems would come from, and they have no insight into why the problem happens in the first place, while they gleefully eat up iMessage / Facebook Messenger / Skype / Hangouts / Whatsapp.
The real difficulty is convincing grandma that she needs to leave "AOL".
Also, running torrents is different from getting all the DNS set up and forwarding all the ports. And even then, where I live, out of the 10 or so fiber providers I can choose, I know that only 2 allow me to do anything with port 25.
It can be a Pita.
https://xmpp.net/directory.php
Similarly how it's done with mail.
People do care, it just seems as though they care about their pet peeves more.
* This eliminates the whole issue for users (I don't want to have to remember 40 million passwords, and I don't want to rely on Google as my SSO).
* It helps the developer because all he has to do is implement one protocol (rather than make 8 different accounts to register passport.js with).
* It helps the tin-foil hatters like me, because I can revoke access from any source at any time & if my account gets compromised I call my buddy Bill hosting the IDP and invalidate my credentials.
I've been working on this problem on and off for about 10 months, the last 4 of which have been fairly rigorous. I've got a solution for the "buddy" willing to host the IdP. https://github.com/bergie/passport-saml is a low friction add-on to your node app for the developers. The last piece of the puzzle is dev adoption (i.e., getting traction on par with LetsEncrypt) to actually spend 5 minutes for that passport-saml stuff.
The other issue is developing an easy solution (easier than SSO with Google) done by mobile App authentication. User-flow is basically: you click "Login with <name>", the IdP forwards the message to your mobile via APN, and you swipe left or right to auth. That's the last technical barrier (user adoption is 80% of the problem). I need to take ~3 mo off and pony up high-five, low-sixes in fees re: getting a great UX guy (I'm abysmal [[if you're great at UX, contact me]]), lawyers, liability insurance, a security firm to audit, etc (there's already a monetization model for this venture, though the whole thing will be GNU AGPL[3] / free for universities / research institutions, etc.)
[0] Like, in the formal mathematically proven sense, both in concept, and implementation (though which one slips my mind).
[1] http://wso2.com/library/articles/2010/07/saml2-web-browser-b...
[2] Encryption is basically a subset of privacy, which I think we have a constitutional right to, though other people object.
[3] The whole point is to do this first as a human good, but profiteer off expensive licenses a la Exchange modules, et al. I don't really want to shop around Sandy Hill but if any of you successful Angels (who are historically privacy advocates, I'd give Karsten Nohl or DJB (or hell, PG if you're reading this message haha, 30% and 2 seats in a second, but Larry Ellison could offer 3MM for .1% and that meeting would conclude rapidly) are interested, e-mail me me -- we'd be able to go to market a lot quicker with 2 or 3 FTE's. I'm going to complete this anyways, but we're fighting cryptowars again so there might be a rush.
This is the thing. If nobody owns it, nobody can exploit it; if nobody can exploit it, it can't get VC funding.
Thanks for giving it a shot, at least. It's getting to the point where if I wanted to keep in touch with most of my friends all the time, I'd need to carry two or more devices (thanks for keeping iMessage closed, Apple).
Have you written a stand alone library which communicates with skype?
The IRC protocol is old. It predates HTTP. Some things are possible in theory, but pointless if no client supports them.
Look into ircv3 (http://ircv3.net/), they're writing new specs for the IRC protocol to build exactly what you're talking about. It's very promising, although IMHO too little, too late - Matrix looks like it's going to take the crown eventually.
If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?
IRCv3 fixes all that.
This is a problem bouncers are already solving best they can, and it still sucks. It's not good enough to compete with slack.
I didn't say anything about competing with slack.
"Oh, Johnson isn't online? better send him an email. /message acmebot email johnson@acme-supply.co Get your ass to mars!" chat bot sees the command and sends him the email.
Sorry if I'm coming off as cynical it's just that I see a trend of the entire community trying to fix problems that aren't real problems.
Chats have an important place because they allow us to say small things, quickly. What you suggest will result in no viable chat for mobiles, only emails. We can probably make a chat app that looks and feels like whatsapp but actually sends an email for every message. Dunno what problems this might have.
You could argue that some of the characteristics we find in chat are not useful, counter productive, etc. And there is probably some truth to that. But that is a different argument than what you made.
The tech is all there. It just sucks to set it up yourself and should just work out of the box.
Obligatory xkcd reference: ... ok, never mind, you probably all know which one I mean.
Laziness.
JSON in, JSON out. HTTP codes tell you what response you got. TLS on an https connection for secure communications. WebRTC for voice calls, and you just query the API for the signaling server to use.
Semi-related:
IRCv3 is an advance in the right direction, but I wish they would make huge breaking changes now - instead of introducing new standards to manage a migration to "later IRC".
Two things I want to see are IRC encoded as JSON, and TLS-only servers in the standard as a requirement. They added message tags which I think just makes IRC ridiculous to parse - if the objective is to extend IRC and add ancillary data to the message they should just use JSON already. I think it's a bad move to allow some intermittent migration path if we all know the end-game is IRC encoded as JSON. It'd be dirt-simple to autodetect if you're receiving JSON or traditional IRC, too. You don't need a CAP exchange to tell you "oh look, it's gonna be fucking json, m8".
An example a feature IRC would need to change for is the ability to edit messages. Slack lets you go back and correct already-submitted messages. You don't have this ability in IRC - and there are ethical reasons to not support it. Personally I'd be in favor of IRC having a command for editing messages, and then clients keeping the entire history of edited messages - so you can always see the original. It's not like the server can take that data back - it's jsut assumed clients would show only the latest, revised version of a message.
I could also see having the IRC server support a virtual DCC user to upload files to - so then you could emulate file attachments like you have on Slack. This is something that can be abused though - file uploads are a security and DoS concern. Slack can support certain things because the infrastructure is paid for - with IRC networks it's largely a "free" operation.
In the past I've made a "Hookbot" that triggers and POSTs to outside services just like Slack. On some IRC networks there are network-vetted bots you can request in your channel to configure and make use of. You can largely support everything Slack does in existing IRC, we just needs standards to add some coherency and expectations for developers/users.
UX does matter, I completely agree with you - IRC needs to change minimally to support those Slack-like features, though. Clients need to change. Most of the draw of Slack is embedding linked items in the chat for convenient viewing. Even icky Mibbit does that :p
[1] https://matrix.org/docs/projects/as/rocket-chat-federation.h... [2] https://matrix.org
I'm curious though.
What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings.
I use a nice web gateway (kiwi) on top of an IRC channel for my student office hours and it's easy. They just supply a username and log in. No software to install, the UI looks nice, and students don't have to sign up for anything.
If I had the resources and the money, I'd focus on a good modern IRC client and server.
Am I wrong?
your use case is very different, and i wouldn't expect any pay-for-chat service to make any sense for it
Although I take issue with "when chat is down your business is at risk."
Pick up a phone. Use Skype. Send email.
Business was done for thousands of years before chat apps. :D
It's perfectly possible to pivot your sales funnel, but it's not something you can do in two hours whilst the chat server's down.
If you rely on a third party for business, you need to plan for it.
The rule always applies: You will pay now or you will pay later.
Yes and no. Setting up an IRC server is hard. Pretty much all IRC servers use arcane settings and configuration formats. I run an Inspircd and Hybrid servers, and for people who aren't used to it, it's really daunting compared to setting up something like prosody.
Services on top like Kiwi are nice. I run Shout IRC which is beautiful and slack-like, but again requires passenger and node to work, so lots of moving parts just for a web-ui.
Having said that, all of this is perfectly doable, it's just not so easy if you're used to dealing with something lightweight and a little php on top.
Seems like a quick script would set all this up for us :D
Think of a bar that lets you bring drinks from other bars. It doesnt have good prospects.
You want to pick and choose your UI? That is an anti-feature. One user sends an image and the other cannot display it because he uses a terminal client. One user sends an emoji, another client only displays a box, because he has no glyph in his font. This is already a problem with XMPP. It has lots of nice features, but each requires server and client to support it. There is no "Full XMPP" label.
And since you prominently talk about the protocol: XMPP probably has all the features one needs. Why hasn't it won yet? Because the complexity of all server-client combinations makes a good user experience too hard.
What is the problem with using different clients/networks for different groups? Why do you want to mix work and private groups into the same app? What does matter (especially for web apps) is a unified authentication scheme (Mozilla Persona would be my favorite), so I can quickly switch between them and do not need lots of accounts. Thus: Federated accounts, but diverse chat solutions.
(disclaimer: I slightly exaggerated to play devil's advocate)
That argument is like saying we should only have one HTML browser because text-based browsers like w3m could exist.
And "one user sends an emoji, another client only displays a box, because he has no glyph in his font" is an issue between different operating systems. Even in a non-federated system like Slack I used to get emojis from people using iOS8 that don't display properly.
I'm not very fond of IRCv2, and have moved away from it where I previously used IRC. But IRC is popular, has a lot of clients, and v3 has a lot of promise. Why didn't the author bother to mention it?
[1]: http://ircv3.net/
I'm sad because I applied to Twitch directly stating what I'd want to work on with the IRC portal and never got a response. My entire work history is IRC. XD
https://github.com/jleclanche/quassel-weblog
There's a demo in the URL field (not hotlinking here directly because it's a weak server). I didn't really document it but there's backlog search, ?highlight=<nick> functionality and it's straightforward to add functionality.
Honestly, it is the future. Everything except Ring / Tox* should just pack up and start contributing to Matrix :p
* Because there is still use for anonymous fully peer to peer messaging, but the marginal utility IMO does not outweigh the incredible tradeoffs you have to make to implement it for normal people (ie, no history, the need to pass around account tokens between devices, slowish message propagation).
It's a submarine for Mattermost which released a new version today
Black Duck are not any kind of neutral source in free software matters.
There's also this, which may be what I'm thinking of, and perhaps not official, but one of the first things I recall:
Dating to 1999.
I do hope to see some work on better user interfaces. Our team recently switched to Slack from Hipchat - many features are better, but the desktop UI is really unpleasantly sluggish. It seems unreasonable for a chat application to stutter and freeze on even small amounts of data. The trend for wrapping web UIs in desktop apps is not a good one, in my experience. Hopefully open equivalents will encourage the development of native clients.
Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application."
Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.
For example, Hipchat's settings overlay (https://i.imgur.com/V3UOyMI.png) which should:
• Be a separate window
• Be sized properly for its contents instead of having to scroll
• Use tabs along the top for the settings categories
• Not have clipped left edges on all of the checkboxes
• Put the close button in the top left corner of the window like the rest of the OS
Compare to settings in Textual, which is an actual native application: https://i.imgur.com/5GFURBk.png
Beyond the design aspects, there's also the issue of performance (the OS's UI layout system is well optimized for doing UI layout) and battery impact.
The average "Energy Impact" of Hipchat as measured by Activity Monitor is 24x as high as Textual's. Twenty four! That puts it in 3rd place, beaten only by Google Chrome and Spotify (which IIRC is a similar "wrapped our webapp in CEF or electron). Hipchat does a bit more than Textual (inline image display), but not enough to justify its abuse of my battery life.
EDIT: spelling
Aside from that, non-native applications inevitably introduce accessibility issues and UX incongruencies with the rest of the system that are difficult if not impossible to resolve entirely. There's a huge trade off made when using web tech for desktop applications and developers would do well to deeply consider their choice of technologies before acting.
You'll lose literally hours of battery life simply by running Atom instead of Sublime. It's absurd how little regard Electron devs are showing for end-user resources.
But there's a difference between saying "I put a webview in my app" and "I put my whole app in a webview". Driving the whole thing from HTML/JS tends to have bad implications for:
• Performance (laggy animation, excessive CPU use, more drain on battery)
• Window management (everything in one box! Modal overlays! Window management is overrated, nobody uses Exposé or multiple windows of one app anyway)
• and UI consistency (some popup menus look one way, right click and every other popup menu on the computer looks another way)
Adium, Textual, and Colloquy use HTML to display things, but they don't try and shove the whole damn app in it.
Every app has to re-invent the wheel here, and there's a lot of native controls that don't exist on HTML.
Generally though, window management is unimportant because these apps tend to be single-windowed apps anyway.
Slack actually does use multiple windows. The sign-in flow (enter organization, enter email address, choose between magic-email or password authentication, enter password) happens in a popup.
What it can't do is pull organizations out into separate windows like Adium or Colloquy. I'm in 3 separate groups on Slack, and sometimes in a conversation in more than one of them simultaneously.
And yeah, I can go open up the second one in my web browser, but it kind of defeats the point of having a "native app" if it's going to be crappier than just going to the website.
The Slack native app for desktop was horrible last year, but right now it's acceptable, apart from annoying notifications polluting the application switcher.
1. is a much more complex application
2. has no perceptible performance issues
3. is also built on Electron
That seems to be the main gripe. Is that true for VSC too (I've never used it)?
if you're curious, download it and open devtools, it's in one of the menus. you get the usual Chrome devtools and you can edit the entire editor.
See my reply to benologist for some reasons that I don't love the HipChat app compared to native group chat alternatives.
I've had a lack of issues with Slack, but HipChat seemed to have updates every other day and crash a lot when I used it.
http://risovach.ru/upload/2016/03/mem/novyy--shablon_1085837...
HTTP and IRC on the other hand look easy at first, then you get past that and there's just more and more complications and edge cases and horror. Like all the various cache headers and behaviors in HTTP, or how all IRC networks have their own dialect that's subtly different.
I once tried to work on an IRC server interface, I read all the RFCs, wrote code, then tested with a client. Nothing worked, so I had to resort to replay what the client sent to a different network and reproduce whatever they did.
If you go read the XMPP RFCs, you should be able to write a client or a server that gets along pretty well with the rest of the XMPP world.
Important conversations already took place on our internal jabber server. People with nothing to say never connected, but now with animated gifs and embedded youtube they use slack for entertainment.
Never thought I'd see Eternal September in a professional environment.
Probably the weakest point of Slack is their price. A similar open source SaaS offering will not be free so Slack has margin to compete.
http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf
Highly-Scalable Searchable Symmetric Encryption with Support for Boolean Queries (2013)
A simple solution: divide the data into N blocks. Create an index that maps words to blocks (e.g. word "hello" is on blocks 36, 43, 84). Then encrypt the blocks and the index and upload them to the server. When you want to search, you just download the index, decrypt it, then use it to identify the blocks you need to download from the server.
The first paper I linked has some more advanced techniques of the same sort.
It depends on how "deep" you want to search. Also, to get Slack's functionality, you need to be able to search through history that your client might not have "seen" yet because you were not in the channel when it happened.
Then let a thousand clients with different paradigms bloom
Perhaps because the hard part of creating an online chat is the network effect and scaling, everyone thinks they can have shot. With so many being thrown at the wall, eventually a lot of them stick.
I remember the Yahoo messengers and the MSN messengers of yore having a majority of the features that I see in the modern chat clients. It really perplexes me that these new chat services are apparently worth so much money.
Yes, you took some trends and put everything into a convenient package. Is that alone worth billions of dollars? The actual technical innovation is minimal.
You have that - SIP and XMPP.
Please don't complain that they are complex and consist of a lot of documents, and have hard feature standartization path. It is the only possible way to openly evolve such systems - to publish serious writeups as documents on their own and have them discussed with criticism and then gradually adopted. And then you may end up with competing alternative implementations of same feature in different standards - that's also inevitable if the system is open. Because, would you be happy to have the same video codec everywhere, or you admire the fact that existing systems are flexible enough to interoperate with _different_ codecs?
The real issue is XMPP does not directly solve the problems the authors of those chat apps deal with. Doing things properly requires writing XEPs and just a lot of hassle which a company building its own little Slack killer doesn't want to invest in, and doesn't have a reason to invest in either because none of the current ones support XMPP in the first place (the bootstrap problem).
If you want to fix this, you have to do that work for them. You have to make XMPP a direct solution that says "Spin up this server, write a cool UI, and your product is done".
Could you please recap which problems exactly? I though the problems which matter nowadays is independence from vendors, and, after that, reuse of existing software.
> Doing things properly requires writing XEPs and just a lot of hassle which a company building its own little Slack killer doesn't want to invest in
So they don't. But I think it's obvious that the point of current discussion is that owned networks are no more satisfactory because of lack of openness and freedom. XEPs and IETF RFCs are exactly for this purpose, so they are necessary.
> If you want to fix this, you have to do that work for them.
For whom "them"? Vendors of yet another IM service? I don't need any of them.
> You have to make XMPP a direct solution that says "Spin up this server, write a cool UI, and your product is done".
It is pretty much so nowadays. You would be surprised how many commercial messaging systems run XMPP software internally, and how much building up the solution is close to what you've said.
Don't see what to reply here
> push notifications
Solved https://github.com/siacs/Conversations#how-do-xep-0357-push-...
> "message was only sent to my other client and I didn't see it"
Message Carbons XEP-0280, implemented mostly everywhere (except Pidgin)
> scrollback
Message Archive Mgmt, server-stored chat history (this + carbons gives you chat sync on par with skype).
> history search
Client app matters. I don't see this function in Conversations (Android), but it is in Gajim and Mcabber, to mention few.
> editable messages
Sure, XEP-0308. E.g. Gajim enables you to do that. Ctrl+UpArrow and you are editing it, then your conversation/groupchat peers see it edited.
> embeddable rich content
Images and markup? Sure. Don't know about GIFs, well, maybe that's why Slack took off - better support for GIFs.
> reliable interop
I think this is not quite fair complaint towards software ecosystem which is currently mostly not supported financially. Indeed, this is quite the problem keeping XMPP and mere mortals apart, but XMPP is closer to reliable interop than yet-another-new-slack-killer-company or NIH-driven-community-project. Keep in mind huge variety of existing software and amount of problems resolved. Let's stand on shoulders of giants, not on the mere ground.
> my mental model of how a message I create will appear to my viewers doesn't need me to understand 100 different clients and their quirks
Not an XMPP problem. In open world, you are safe to assume variety, not sameness. I love my scriptable terminal-based chat client, are you going to deny me in having one? I want a text-to-speech generator to read your messages to me, and free protocol enables me to do that, is your mental model of your message disrupted? I want to have your message translated by some engine and presented in different language, is your mental model of your message disrupted? Or, I am blind and I use Braille terminals, are you going to deny me in using it?
Really, the only thing that stops me from wanting to use these services at $DayJob is the fact I have enough stuff I have to maintain. I'd really rather just pay $99/month for a 10-20 person team.
I was blown away on how much better the UX was in Gitter compared to IRC. The history, the notifications, the markup, the UI...you name it.
And Gitter is a pretty crappy client. If there was a nicely implemented client, it would be even more impressive.
But Gitter has other issues - mostly of the UX kind. One of them is that you can search for other rooms, but you can't really save that search. You have to start over everytime. Also, the default of sending you an email for every freaking message when you star a room is absolutely atrocious.
Getting a critical mass of people to use a chat system is the defining factor of success, not the technical genius or features of the system.
Slack is successful because it IS one of those standards that a critical mass of people use and is modern.
There are plenty of systems that are far superior. However they are failures because they didn't achieve the critical mass of users.
Traditionally, this is solved by autodetecting their OS and giving them a big link in giant UX-ey button form as "recommended", and only mentioning the other platform links in smaller letters below that.
So, I don't think it's quite ready for grandmas yet.
:)
Seriously I know XMPP is pretty un-popular, but deep inside I kind of wish it was the default protocol everybody used to communicate...
The question really is what made Slack special. Why is it the Slack revolution and not the HipChat revolution? What about the veneer has allowed it to become a pervasive trend, expanding into non-tech companies and being hailed as a permanent replacement for most emails? This is the only interesting question around Slack, since, as numerous other commenters have pointed out, it doesn't really bring anything to the table that the messaging space hasn't seen a good number of times before.
As you can tell from my post which states that Slack doesn't offer anything unique or special, uh, no, I'm not drinking the kool-aid.
The organisation I work for got on board the HipChat train just as Slack was gaining momentum. While it's cheaper, I think if we'd had Slack we'd have much greater adoption.
I'll try Slack... let me check Skype... no maybe they're on HipChat... SMS... oh hell I'll just call them!
Yeah, IRC is from the 80s and is lacking some modern features, but at least it was a fairly unifying chat system in its day. No one company owned it, most people could use it trivially, and there were many different clients out there to suite one's taste.
There's still a market for wrapping a protocol in a nice web app UI and hiding the complexities from the user, which is why this closed chat systems trend is getting frustrating.
Can't different chat services communicate with each other easily, without the need for a bridge?
If more chat services supported Matrix.org we could get there.
https://matrix.org/docs/projects/try-matrix-now.html#clients
Someone's suggested it in the Mattermost suggestions site:
https://mattermost.uservoice.com/forums/306457-general/sugge...
Everyone is talking about open protocols but when you're client agnostic you have to store/manage data somehow so surely Slack with its integration friendly mentality could go in that direction?
Then there's also Ricochet: https://ricochet.im/
What are the significant differences (advantages/disadvantages)?
I get that IRC never had a particular client that galvanized the protocol as much as the many iterations of proprietary real time chat that has came and went over the past 10 years, but honestly the problem isn't the protocol, the problem is that no one was making clients meant for the mainstream.
Matrix has solved the right engineering problem first which is the persistence of the chats across all of your clients.
Oh wait, IRC.
So I can point my run-off-the-mill IRC client to a slack server and partake in cat pictures exchanging and almost-NSFW-but-not-quite with my fellow coworkers, yes?
Otherwise whatever it uses inside its walled garden is completely irrelevant I'm afraid.
https://get.slack.help/hc/en-us/articles/201727913-Connectin...
It doesn't help that IRC tends to get used in places where massive amounts of users are expected. I feel some of the newbie clients should just hide by default join/quit spam.
Also on public IRC you tend to have a channels of 80 people, all idle.
and, if only there was push button per channel access control set up out of the box so that some users can join some channels but not others! no, not channel keys, those are busted (what do we do when someone stops being involved in a channel? rotate the channel key?)
there's way more in slack than IRC, so there needs to be way more in a slack killer than IRC...
Have you heard of irccloud.com? You should check it out. My mum could use it (I'm not affiliated with them in any way besides being a happy customer).
IRC is difficult to configure, difficult to host, difficult to use, and does not offer the same feature set as Slack. There is an obvious use case for something like Slack (obviously, because otherwise it would not have millions of users!) and covering one's ears while yelling "IRC! IRC! IRC!" is sort of wilfully ignoring that if it were a suitable solution, Slack would never have taken off.
I can tell anyone in any kind of role (senior to junior, technical to non-technical) on my team to "Download (the/a) client for X and join #channel #channel2" "Follow the directions to set it up so changes on this Trello board are posted to #channel" and reasonably expect they will succeed if X is Slack, but not if X is IRC.
1. Download IRC client.
2. Pick a nickname.
3. Pick a server.
4. Join a channel.
Regardless, it's not as if there aren't upwards of a dozen of off-the-shelf IRC bots you can grab off the 'net...
Yeah, here's where you fucked up reading my post.
> anyone in any kind of role (senior to junior, technical to non-technical)
I'm talking about Joe Frontend, Billy Design Intern, Gary Office Assistant. Maybe you work on teams that are 100% neckbeards that aren't afraid to crack open an RFC to get daily shit done (and waste huge amounts of company resources on things that should be simple), but that's not the environment I'm talking about.
Not accounting for these people is the fatal mistake made by far too much of the tools and processes in software. I've watched people go into shops like this as non-technical helpers, work really hard and skillfully within the boundaries of their role, but get burned too many times by a hoity-toity technical bro "lol, you can't even open an ssh tunnel to the bastion host to connect to the internal IRC..." that they quit software, return to lower paid job they did during school and decide they have no skills, when they would thrive on a more balanced (and more socially skilled) team.
I had specifically included a scenario that is both common for use in my experience, and also pretty much impossible for a normal human using IRC in order to preempt this branch:
> Follow the directions to set it up so changes on this Trello board are posted to #channel
Sure, in extremely limited situations (so many qualifications are required here I won't list them) it's mostly easy enough for a non-technical person to manage.
Normal people (that is, people who value their own time and haven't been warped by daily interaction with software that fails to do what you asked because you failed to include some extremely implicit punctuation) laugh at many common explanations surrounding IRC, just a handful of examples: "IRC doesn't have passwords really so to prove who you are, you have to speak specific commands, like a CLI, at this bot over here, or configure your client to do that for you" "IRC has away status but nobody really uses it, because it's manual in many clients, so you typically 'ping' people and just wait to hear back if they are around" "oh yeah, if you want to get rid of all the join/part/away spam, the option for that is hidden in a menu with a bunch of other stuff, and in this client you have to set it up for each channel separately" "oh, yeah, you can't speak in that channel because you have to get the bot to +v you by direct messaging it 'shibboleth'" "btw here's the list of random-seeming letter 'flags' our server supports and how it interprets what they mean differently from other IRC daemons"
And we haven't even talked about how bad the story is around message persistence or using multiple clients or the "solution": bouncers. Getting all that going is basically a non-starter for humans unless you give in and use a service like IRCCloud that deals with search and synchronization well across platforms (but which you must be aware of in the first place).
I'm pretty technical, I've internalised the arcane knowledge, I've written IRC RFC-compliant bots to get things done (and then made them conform with common out-of RFC conventions in order to work with non-conforming IRCds), but that was all in high school, well before I gained a sense for the value of my own time. I can do it but I still refuse (to the degree that a team's use of IRC would make me pass on an offer as would I pass on a developer interviewee's inability to perceive usability problems with IRC).
I still think it'd be fairly easy to set up a company-internal server and make the whole process pretty streamlined for users. The only somewhat difficult part, then, would be the password. And I'm not sure how valuable message persistence really is, anyway, especially when you have your company email directory (and you could have IRC logs).
And for the record, I don't claim IRC's UX is without it's problems. It could certainly be improved a lot. I just don't think it's bad enough that people can't be expected to figure out how to log on and start chatting. At the same time, I think switching to a proprietary service that's run offsite is not a good solution. (We use XMPP where I work, but strangely not with conferencing. It works very well, but we're forced to use a shitty client (Cisco Jabber)). I've got high hopes that IRCv3 can start making improvements on a lot of the things you mentioned, but only time will tell.
If there were no other alternatives we could probably manage somehow, but there's much less friction in "here's the URL, sign up with your email address"
It's not like you're stuck with ugly terminal only clients anymore. There is KiwiIRC, IRCCloud, and several other great web clients that not only let you connect to any server but provide bouncer services and backlog. There are also plenty of easy to use native clients that don't require any configuration.
There are some benefits of Slack, but the ones you mention aren't them. In fact, seeing how you CANT host your own Slack server I would say "difficult to host" is a flat lie against IRC.
(No I don't work for them. Self-hosted their AMI at last job, found them to be friendly, easy to deal with folks)
Hell one of the downvoted comments is just "IRC comes to mind"... Just hand waving away all of the problems that something like slack is trying to solve, which the article talks about.
Worst case, it turns out being a legit article, in which case it's cool. Eh, no big deal.
If someone is astroturfing, I suggest you stop immediately.
I'm downvoting them as I see them for this reason. Anyone saying "Why not IRC?" to the question of "Slack alternative?" is being willfully ignorant at this point.
Same goes to those who accuse people of astroturfing absent evidence other than "$ideaILike is being downvoted".
You can't impute motives why someone might ask that question. You may feel it has been repeated ad nauseum but it's quite possible those asking the question haven't read the previous HN comments.
At this point, you come over as an arrogant jerk.
To avoid repeating myself: http://lists.lca2016.linux.org.au/pipermail/chat/2016-Januar...
As soon as you say "run a bouncer" you limit your audience severely. Without a bouncer, you're a transient in the world of IRC. Doubly so if you have the temerity to want to interact from a mobile device that pops on and off networks all the time.
[1]: https://events.ccc.de/congress/2015/wiki/Congress_Everywhere and yes, they use IRC. LCA's audience is a bit different
Love Discord, wish it were, but I just did a quick check and couldn't find anything there
Stop touting IRC as the "perfect" chat system. It's far from it.
IRC scales much, much better than Slack. Unreal or InspIRCd or Charybdis whatever - Slack fails miserably for hundreds of thousands of users in one "team"/network.
I do agree administering/configuring IRC servers has to get nicer. I personally want an IRC server that exposes a REST API for online configuration (no rehashing of a config file).
The history should load in progressively as needed. Switching channels within the same team should be instant. I don't know how you fail at tab-completing nicknames and commands, but somehow they made that slow. I get the feeling rendering is not on a separate thread in the desktop app.
Anyway, you're right that not everyone needs to be on 7-9 networks with the ability to talk to everyone among those. Slack is great for teams of like 500 people and less (imo).
Email's pretty crappy but at least with email I get small, contained threads of conversation that can be searched and organized easily. Slack is like having a few giant never-ending email threads. It's horrible.
And there's still no voice.
Therefore, wouldn't it be nice if there was a website where product designers (not software developers) could post their product designs, so that the developers have something to work from?
I don't even get IRC or IM. "Chat" is noise and distraction. Write proper emails or arrange phone calls.
What exactly are people using slack for? I don't get it.
We need to discuss something visual as a five-person team? A phone conference is the wrong medium.
We need to collaborate on a significant technical document? Slack is the wrong medium.
We need to have a searchable back-and-forth discussion, interleaved with other things that are vying for our attention? We should probably use a chat tool.
This is email.
> We need to discuss something visual as a five-person team? A phone conference is the wrong medium.
Shared desktop conference, such as gotomeeting.
However, the growing number and popularity of alternatives should be a strong signal that they do not work for every team.
You can also talk to Mattermost team on #matterbridge on Freenode.
For those ~15 lines of unwrapped text, the whole page is 1900 lines in total.
It generated incredible hype, but a lot of people (including me) could not use it due to this bullshit; maybe they can acquire Slack and reengineer it using the much more mature Wave foundation.
I'll get down voted to hell but come on. It's cheap, it's good, so why not let the guy make a living? And for the record I don't even know who the guy is (or woman is).
I just hate the "it's cool, lets rip it off attitude". Because the ripoff is rarely better than the original.
I just don't like that as soon as something becomes popular then it's a target. It's always bothered me that open source seems to copy more than innovate. I'm sure there are open source projects that invented something new but it's hard to think of them (for me at least). But I can think of zillions of copies of closed source things (linux, gcc, etc).
In the case of slack, it seems sort of mean spirited to try and clone it. They give it away for free for most people and charge for some sort of extra functionality and it's cheap, $7 or $8/month/person. I can understand something like Postgres, Oracle is expensive and cumbersome. But slack? Really?
For the record I have no connection to the slack people, don't know them other than what I've read in the press.
In fact, I'd consider any open source alternatives to Slack to be fair game on an open market, and the massive underdog at this point.