A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up.
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.
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.
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.
The problem is that the IM protocol space seems very opinionated. "XMPP? XML sucks!" "Web sockets? Web sockets suck!" "JSON? JSON sucks!" "Binary? That prevents telnet, binary sucks!"
People do care, it just seems as though they care about their pet peeves more.
That "XML" sucks thing is why we don't have single-sign on (YuBiKey is doing a great job getting half way there though). We keep on reinventing the wheel re: authorization & authentication despite the fact that there are well-defined, cryptographicly secure[0]. SAML2[1] has been standardized, implemented, operates in a similar fashion to SMTP/Kerberos (i.e., your identity is established (i.e. authentication) purely through a trusted-source), after which you can proceed.
* 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.
It's SMTP mail back in the late 90s when your buddy ran his own server as your primary MX, and his buddy as a secondary MX (i.e., you host an IdP similarly to hosting a mail server).
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).
[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.
We integrate pretty deeply with SAML and, yes, it's awesome tech. It makes complete sense that XML was used because real namespaces are important for claim extensibility. Sadly, "XML sucks!"
People do care. I'm working on a Qt Matrix client for KDE / maybe eventually Telepathy.
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.
Lots easier than before. Off the top of my head:
1: You have more than enough 'power users' who keep their machines on 24/7 for torrent seeding. VirtualBox is free & those guys are fairly security conscious as a result of the inherent defensive nature of torrenting (MPAA litigation, etc). Give them a VBox server they can run and they'd happily do it. Now grandma can use his server no problem, in the same way that you only needed 1 techie in your group (pre-AOL) to host an SMTP server.
The real difficulty is convincing grandma that she needs to leave "AOL".
That is oversimplifying, for example what happens when Microsoft seems to make your email to your brother in-law disappear and they tell you they have no control over their spam filters? Or when you sent out birthday invites and every Yahoo user you know presents you with an automated message that your server has been banned forever from sending them mail? So you set out to get SPF records, get DKIM working, get certs... and it doesn't help.
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.
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.
Ok. It's kind of good to hear the barrier to open sourcing is more legal than commercial. That means it's fixable :)
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?
We implemented them ourselves, and it took quite a bit of work.
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).
I was just considering advocating within my employer (Cloudant, i.e. clustered-CouchDB-as-a-Service) to back Loïc too. CouchDB is still stuck in the past with Mochiweb, and while switching that out for Cowboy 1.X would be a nice-to-have, getting our hands on a stable release of Cowboy2 (i.e. "the HTTP/2 version") would let us optimize Couch's replication story immensely. I've just been trying to set up a single trivial Event Stream HTTP/2 loop_handler with the Cowboy2 master, and it's really just not there yet, so we could probably give him a push.
That's actually interesting topic :) Right now we use gulp and gulp-typescript. So far, I like approach that is used in https://github.com/Microsoft/TypeScriptSamples/tree/master/e... but I'm not sure if we are going to use it any time soon. As far as gulp config, what we use is pretty much close to gulp-typescript README examples
There are actually FOSS implementations of Hangouts wrappers (Hangups) Skype wrappers (SkypeWeb for libpurple) and Facebook wrappers (purple-facebook) and even a telepathy wrapper for the Facebook protocol.
Nobody is getting sued yet, and Pidgin supports all of them nowadays.
Or how AOL's Oscar protocol got updated at one point to start requesting chunks of the AOL IM binary as authentication against open sources clients (because they couldn't distribute AOL's binary with their client).
Yeah because if you open source something under the right license, no abuse happens... What percentage of GPL violators has the FSF prosecuted? Or anyone else for that matter?
Unfortunately working on GPL compliance is expensive, I would encourage anyone who cares about copyleft to support the Software Freedom Conservancy's efforts.
Not sure what is so depressing here. According to the chart, a total of nine listed networks died in 50+ years, this is actually astoundingly low.
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.
The depressing aspect is the accelerating fragmentation caused by more custom protocols entering the game. Supporting them all as the space grows will only get more cumbersome.
Out of curiosity: are you leveraging such software as spectrum (spectrum.im) and libpurple? These pieces seem to be a good fit for internal gears of your product.
Good luck, you are working on an important problem.
Hi Andrey - we're not using spectrum.im or libpurple (but are aware of both). We saw that libpurple now supports Telegram, so we may borrow some ideas from them :)
It doesn't look like you provide quite what I'm after, which is a single OS X / iOS app that seamlessly connects to all of those, while supporting the differentiating features of each. Would easily shell out $30 for such a thing, and maybe even $10 a month for a licensed version. Setting up "tunnels" between client installs probably gets me fired.
We focus on connecting teams vs individual productivity. Check out http://meetfranz.com/ for a single app option.
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.
You find yourself in the same position that Trillian did, what, 15 years ago?
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).
Which is absolutely irrelevant. It's expected from a mobile phone to be able to send and receive SMSs. But SMSs can take several minutes to reach its destination in some areas. Long messages are split. And the experience as a whole is totally different. And of course, most people pay per message (individually or as a pack), at least globally. So, if someone wishes to send a message, it shouldn't matter what OS or app is being used by the other party. IF GP uses an Android phone as its primary phone, it may be problem if he is trying to chat with someone who uses only iMessage.
Facebook, Google chat and some others XMPP based were compatible and you could chat with Facebook users without having facebook account, but they closed their services making it all incompatible.
We decided to only include cloud services, so we weren't sure what to do with something you have to run yourself. That said, the line is blurry, we will fix.
Would you mind releasing the source (SVG? Illustaror?) of that very depressing chart under an freedom respecting licence (CC-BY? CC-BY-SA?) and hosting it on something like Github/Bitbucket/Gitlab/Codeplex?
I would like to contribute by updating it.
Also, I would like to link to it on Wikipedia.
You can see what happens to OS projects that work with WhatsApp, Skype, and some of the other heavily guarded walled gardens -- cease & desist orders, carried out by GitHub.
We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(
Actually I don't think so. The main thing the owners of big networks are afraid of is spam.
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.
In that case great for skype, bad for slack. Someone, somewhere will decide they'd rather force those customers to use their service/client, or else they'd have an open protocol in the first place.
There's a huge compliance problem with working in someone else's Slack team -- you own none of the resulting data and you don't control access on your end.
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.
We are actually trying to make open protocol in https://actor.im with federation with https://matrix.org. It seems that only Actor and Matrix understand importance of federation.
"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:
Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. 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.
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.
Ok. But why use AES and GOST? AFAIK they're both based on feistel networks? If one were to layer two symmetric encryption schemes today I'd think one would go with something like salsa[ed:chacha] and keccak (in authenticated encryption mode) -- and it would probably still be a bad idea, adding much more complexity than security?
> 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).
You're not helping your case. You make it sound like you are using bricks without knowing what their strength is.
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.
I haven't looked into actor much yet, but the last time I looked at Matrix, my main concern was how much implicit trust users needed to place in homeserver providers (messages and user profiles are stored in plaintext). Unless this has changed, I don't find it viable for any app that values user privacy.
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?
Matrix signs all of its messages to avoid homeserver providers tampering with message history. Actual encryption however requires E2E encryption, which is in the wings via our "Olm" Axolotl implementation (http://matrix.org/git/olm). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162. So I don't think you should reject Matrix on trust issues quite yet (although if you're really worried you should certainly wait for E2E to land).
Glad to see there's been progress on this front! The lack of E2E encryption is literally the last thing holding me back from building apps with Matrix. Can't wait to give it a try! =)
Axolotl has a well defined message structure using established crypto functions. All of them, for example, except Curve25519 are in Crypto++. You can probably fairly easily bake your own, albeit I'd use the olm from Matrix and just make theirs work well first.
But isn't the same true for Slack and its "open source competitors" mentioned in the Wired peace?
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).
Not sure if any were mentioned in the piece, but there are plenty of zero knowledge E2E encrypted chat clients out there. None of the ones I'm aware of are also federated like Matrix is though, and I suspect the federated nature of Matrix probably makes E2E encryption a lot more complicated to implement than I can ever imagine.
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.
Agreed that E2E is mandatory for privacy. The federated nature of Matrix doesn't make it any harder to implement though - after all, TextSecure/Signal has basic federation too. The one subtlety we have is that we want to give the users the option of selecting between PFS and replayable epochs of history on a per-room basis - the latter making it easier to sync history between devices; the former being for the privacy paranoid.
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 :)
Yes metadata is probably going to remain an unsolved problem for Matrix because it's not fully distributed, but I agree with the tradeoff Matrix is making here.
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:
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.
Have you heard much about the Signal server federation? It's been more than a year since it was mentioned (that I've seen) by the Open Whisper Systems folks.
I'm not sure it's a huge priority there currently, but we don't have any internal knowledge. We asked to federate Signal with Matrix (which is a concrete possibility given we share the same E2E spec) and were politely turned down, as they'd prefer Signal to be a silo whose security they control rather than risking interop with 3rd parties. Hopefully they will change their mind in future once Matrix's E2E is more proven :)
We have two options - end-to-end (experimental) and only client-to-server encryption. We are looking at ZeroDB to make it end-to-end by default and searchable. We had e2e default encryption but people start to scream after missing their phones and losing all theirs messages :(
Also we had Tor-enabled client, but Tor is not suitable for mobile apps.
You're certainly right that the UX of most IRC clients is seriously lacking compared to eg. Slack. But one thing I've always wondered - is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps? There's no reason why the protocol itself has to handle UX features like emoji/embedding/etc. - just send a text token over the wire and have the client interpret it as a specially displayed element. The only thing it may not handle well is file uploads... but even then, I seem to recall IRC having built-in support for sending files?
> is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps
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.
Offline messages is a server issue, though - in principle there's no reason why you couldn't have a server that remembers offline messages and passes them to the client when it reconnects, framing them as regular IRC messages.
There is, actually. IRC has no concept of timestamps. IRC has no concept of foreign metadata, even, so shoehorning isn't even possible without looking horrible.
Channel logs is a marginal, client issue, not a protocol issue. Does anyone do client-side logging on any of these other services that do server-side message history?
That is 100% true. But I use IRC and have offline messages. It's IRC, so I had to cobble something together to make it happen, and the UI is ass, but... I have that within the IRC protocol.
We already have offline messages, it's called email.
"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.
Chat is not e-mail. It's chat. It has a much different feel to it. One brings a different mental context to e-mail than they do to chat. It is accessed differently, and the use patterns are very different. Hence, solving "offline chat" by sending an e-mail... this is not a real solution.
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.
Your "solution" does not work well with people on mobile. People on 2G/3G/LTE can alternate rapidly between online and offline. This kind of problem is easily solved by the chat server behaving like a store-and-forward device. Which is exactly what email is. But nobody likes to converse entirely using emails.
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.
That's not really a protocol level solution. Sure, it works, if you know how to do it - but you don't automatically gain that knowledge "out of the box", you have to learn it. It is a real problem to anyone trying it out that doesn't understand why they can't send a message to someone who is offline.
Also mobile notifications - that's a huge benefit of Slack and an IRC app couldn't (as far as I can see) provide them without maintaining a constant connection.
I might be alone here, but I don't see the problem. I also do not believe that federation or interop would be a good feature for group chats.
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)
"One user sends an image and the other cannot display it" deals with features between two clients... I fail to see how this would be a more general issue with allowing different UIs. Especially since most chat clients do support the same features.
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.
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.
XMPP has changed yes. And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…).
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.
> And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…).
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.
Edit: looks like someone asked a similar question below.
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.
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.
A lot of ircds disgustingly put some config options in at compile time, including things like the servername. A friend of mine had her irc server give the generic name for her ircd for several months because she couldn't be arsed to spend the time to recompile and reconfigure.
Couldn't you just make sure that puppet/chef/whatever runs the right config options? Maybe a script that asks you for values up front and plugs them in?
i think the #1 value add from slack/hipchat is that it's hosted for you. we spend thousands of man-hours each month and year keeping our servers up. uptime is hard. chat is not hard. historical chat is not hard. when chat is down, your business is at risk. there's other services at my company we pay for that aren't very complicated - we just don't want to host it. paying $5/user/mo for chat that is always up is easier than keeping it up yourself.
your use case is very different, and i wouldn't expect any pay-for-chat service to make any sense for it
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…
Having used and developed with XMPP day in and out for the past 9 years I'd have to agree with the sentiments towards XMPP being on life support.
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'.
Looks like they're making all the right noises in order to be a viable successor to XMPP. Really does look good, but seems to be in its very early stages.
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.
There are quite a few large/huge companies building stuff on Matrix - looking at the copyright statements of the code in github.com/matrix-org reveals a few. Many of them are using it in commercial stuff which hasn't launched yet - and meanwhile Matrix is still in beta, so understandably they don't publicise their activity too loudly about their activity atm.
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,
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.
The thing is that Google moved from XMPP to something proprietary specifically to avoid federation. The big players don't want federation and any protocol will suffer the same fate unless it becomes popular without reliance on the big players. I think it is fair to say that XMPP isn't any more dead than any other protocol in this respect.
An interesting point. There was a similar issue with SMS (federating with big telcos), and Whatsapp (among others) did a nice job of routing around that (by piggybacking on SMS). It's interesting to think about how a genuinely open player might route around that.
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...
All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.
What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.
Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue.
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.
Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)
XEP-0136 was pretty complex, and didn't see that much adoption.
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.
So either XMPP is bad because it hasn't changed for years and is therefore old, or else XMPP is bad because there's new replacements for stuff that didn't work so well.
Honestly, there's some days I wonder if there's any way to win.
Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).
Hi Dave, firstly thanks for all the hard work on Openfire over the years, very much appreciated.
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.
Super easy to use, nice admin pages, great plugin architecture for 3rd party developers to extend its functionality. Means there's a LOT of cool plugins which add video, screen sharing, chat archiving, etc.
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.
I've used both and moved on to prosody. Ejabberd is just too arcane to configure and debug; and openfire is a damn resource hog for no apparent reasons.
You may want to check http://salut-a-toi.org/ then (I'm working on it), we have a similar architecture and it's a very active project, XMPP only though.
As someone somewhat related to an IRC project, it's frustrating talking to people who love Slack because most of what they want is something that would be supported in an IRC client - not the IRC protocol.
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
I wrote a Matrix client library in Qt about three weeks ago, and it was really braindead simple.
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.
For talking about a race, Wired seems to have neglected a crucial technology: ircv3[1].
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?
Not sure why you were downvoted. What you said is true - there's little to write about for pure tech projects like that when there's no flashy video to show off. You'd have to figure out how to message it to reach a wider audience which honestly seems difficult to me.
Twitch is fairly-conforming to IRCv3... they don't prefix their non-standard capabilities with their domain in CAP LS. :>
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
Doesn't it also lack a common, arguably nice, frontend? With integrations to everything under the sun pre-built, requiring no management by the implementers? Built in bouncers, searchable history, etc?
Sadly IRCCloud is still lacking one 100% crucial feature: a backlog search.
I've been a paying IRCCloud user for almost 2 years now and back then they already had the search feature on the roadmap as "coming soon".
The only way right now is to keep scrolling and scrolling and then some more scrolling until you find what you are looking for. In a busy channel this is pretty much pointless.
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.
Hi, I wrote the Wired article in question. I hadn't heard about IRCv3, but it does sound like it would plug some of the holes in IRC that Slack users complain about. It wouldn't really have been a good fit for this article, since I was mostly focused on the two Slack-alikes with most traction, at least according to Black Duck's data (an imperfect measure to be sure) and IRCv3. As for why I didn't mention IRC in general, well, I alluded to it in the first sentence, but as many other people have mentioned, IRC just doesn't hold a lot of appeal in the business world, for various reasons.
Matrix is very different to IRCv3 actually - you can think of Matrix more as a openly federated object database with pubsub semantics and a standard HTTP API. One use happens to be group chat, others include WebRTC signalling, IOT data exchange, etc. Meanwhile IRCv3 is very much an evolution of classic IRC - it's still closed federation, uses the IRC line protocol, and is all about group chat. We're looking forward to bridging it into Matrix :)
I for one welcome our Matrix overlords, where all our communication needs are done over HTTP json requests, and you can have interop servers into every other network through federated gateways.
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).
Some of the few features that are rolled into IRCv3 like SASL or CAP negotiation were widespread and specified on their own for long before IRCv3 was a thing.
It's good to see a bit of a variety – we all know that monoculture ends up being a bad thing, and there are obvious downsides to applications hosted by third parties (though of course in some cases it's not a problem!). Of course, there's no real network effect with applications like this either (beyond integrations support) so there's a relatively low bar to switching when compared to something like Facebook.
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.
Being build in HTML and being a webapp are very different things. I don't think rendering HTML is significantly worse than rendering some "native" UI kit. If it's not loading pages from the internet, which I'm sure Slack doesn't, than the experience should be pretty much the same.
This is a good point. I'm not opposed to using HTML in an app. Back in the early 00's, I did a decent bit of tweaking my Adium conversation display style. It's useful for displaying that kind of content easily.
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.
They're only single-windowed apps because they choose to be. Colloquy and Adium both let you pull channels/servers out into multiple windows (just like tabs in a browser).
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.
I think Mattermost has also Android and iOS native apps.
The Slack native app for desktop was horrible last year, but right now it's acceptable, apart from annoying notifications polluting the application switcher.
I give VS Code a pass on some of my UI gripes, since it's a text editor and I don't expect it to have much UI beyond a box that the text goes it. The "settings is a text file" setup works fine here.
See my reply to benologist for some reasons that I don't love the HipChat app compared to native group chat alternatives.
Apps built with front end web tech are nearly always heavier than their fully native counterparts, for one. It's nothing for an electron-based app to gobble up 150MB, 250MB, and higher amounts of memory while doing (in terms of resources actually required for the given task) nothing. A great comparison is Sublime Text, which takes up ~35MB of memory at cold start, even with a few plugins enabled. Compare this to VS Code or Atom, which take around 200MB right out of the box. That's downright comical, and I can't accept the "but resources are cheap" excuse. That mentality has been robbing users of the lightning-fast, ultra-silky experiences that are possible even on decade-old hardware for years now and it needs to stop.
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.
It's not just RAM, either. If you measure "energy usage" however your OS allows you to (powertop or OS X's Activity Monitor, etc), Electron-based apps are absolute battery killers.
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.
That's true, but when you roll a "one size fits all" HTML app across all platforms, it's much much less likely to follow operating system conventions and very easy to get layout details wrong.
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.
Aren't most of those application bugs? For example, I don't see why the check boxes should be clipped in any web application, since in their default configuration (no CSS), they aren't. So the Hipchat CSS borked the default widget.
Yes, the check boxes are a bug in HipChat. That's part of my point: I have literally never seen a native OS X application that couldn't lay out checkboxes properly. Working in html/electron opens you up to making these UI bugs a lot more easily than native development.
That's the risk of customizing the UI in any cross platform toolkit. I'd rather have slightly wonky cross platform apps than native apps for a very limited subset of platforms.
I think transmission did the right thing: a single core shared across all platforms, tailored UI for different platforms. And yes, the existence of a web app makes it available absolutely everywhere, and the existence of fully native UIs make it a joy to use.
What about reusing and polishing XMPP and existing decent software for it? About donating money to people who develop it all these years? No, we'll spread FUD upon XMPP or just ignore it but will proceed to use and abuse its legacy behind the closed doors.
It may look intimidating at first, but it's really very easy once you get the basics.
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.
This may be the primary reason for the multitude of protocols. Everyone thinks every existing protocol is complicated and thinks that they can implement it better. Or: https://xkcd.com/927/
In my org we started using slack and the people who talk the most say the least.
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.
In our team, we created a "random" channel for animated gifs, unrelated links, etc. to keep from cluttering the work-related ones. So far, it seems to have worked well.
I think the Achilles heel of almost every open source projects is [end-]user experience. The first time I used Slack I was sure it was trivial to replicate the software (not the business) by a small team of developers but a short time after I realized a lot of UX details that a normal open source team will not prioritize ever (e.g. conversationally educating the user about new features).
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.
One thing that nobody's mentioned yet is encryption. A Slack alternative that's end-to-end encrypted (at least for private messaging between users) and has encryption for chatrooms would be worth my time.
Homomorphic encryption would be great, is it likely to become practically usable soon? That is, is it safe enough against attackers, while allowing useful search?
Homomorphic encryption is about doing computation on encrypted data, but you don't need it just to search. All you need is some way to get the server to send you the encrypted blocks which contain the messages you want (and which you can decrypt); you don't need the server doing computation on the encrypted data itself.
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.
I admit that I get a bit blurry-eyed reading those, but I hope that they do in fact prove practical and gain implementation usable to everyday programmers.
This sounds like a fun thing you could do directly in Slack with a chrome extension. Kills a lot of the server based features - search, pulling in webpages, lots of integrations, but it seems like those would break in your end-to-end world no matter what.
Presumably you'd have access to the plaintext after decrypting it at the other end of the channel. Why wouldn't client-side search work if you wrote the entire app?
> Why wouldn't client-side search work if you wrote the entire app
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.
For reasons that have never been entirely clear to me, chat has been reinvented more times than perhaps any other common Internet utility, and every time it is, there are no shortage of investors lined up for it. I think the cycle is largely driven by fashion, as youth get online and demand chat apps that are distinct (if not different in any meaningful functional way) from the existing ones.
I have the same thought. Heck, voice and video chat, file sharing, even primitive forms of 'integrations' (in the form of IRC bots and the like) have been around for many years at this point.
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.
Yes, I have thought about that as well many times. AIM, ICQ, Yahoo, MSN, Gtalk, WhatsApp, WeChat, iMessage…
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.
If the medium is the message, then yes. A chat on ICQ is different from a chat on WhatsApp, because the app itself is part of the tribal identity. Like slang for existing words. So even if the functionality stays identical (and I would argue that it has, there's only so much you can do with a chat app), the cultural context of the app is different.
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 specs are not directly the problem in XMPP. They just amplify it.
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".
> XMPP does not directly solve the problems the authors of those chat apps deal with
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.
battery life / fast reconnection (aka, the mobile problem)
push notifications
"message was only sent to my other client and I didn't see it" (dunno if this is solved now, was a problem when I last used XMPP in anger)
scrollback / history search
editable messages
embeddable rich content
reliable interop (aka: 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)
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?
The real problem is that the problem keeps changing. XMPP adapts. There's some friction. XEPs get written to deal with it. Life goes on. Someone invents yet another variation of IM and the cycle repeats.
I work in consultancy, and the client I currently work for has us working on-premise using air-gapped computers. No internet, only intranet, meant finding new ways to communicate. So far Mattermost works well. We have it integrated with Jenkins, Stash etc. and do the typical "chat-ops" things.
Hopefully Mattermost and Rocket.Chat both build mature, robust HA systems since their features [honestly] are on par with Slack. Then move into SaaS hosting of their service in VM clusters across ~3 regions. :)
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've had zero problems with the server (like memory leaks or random crashing), but the iOS app started complaining when the server was roughly 3 months out of date. To stop the errors there I had to upgrade the server code (which was itself pretty simple). That doesn't meet your criteria, but I've find it pretty minimal by my standards.
I've been using Gitter for a few months now, I think it's just polished enough to use consistently. If it were even slightly unstable I'd have to stop using it.
Until recently, Gitter had some weird bug where it the process would be in the background after you closed it, and you thinking that it was gone, would try to fire up another one it would just go to a background process or something.
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.
This reads like that old XKCD where someone tries to build a standard that unifies all the existing 14 incompatible standards but it just becomes the 15th incompatible standard itself - https://xkcd.com/927/
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.
The download page lists "Mac OSX, Linux x86", Linux x64, Windows x86, Windows x64". The average user does not know what x86 or x64 means, and if they assume that the larger number is the latest (because duh) then they'll be causing problems down the line by installing the 32bit version on their (probably 64bit) machines.
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.
I know what we need: an open protocol so that people can chat easily, whichever company you work for, wherever you are...
We should call it IRC or XMPP
:)
Seriously I know XMPP is pretty un-popular, but deep inside I kind of wish it was the default protocol everybody used to communicate...
This is one of those applications that is always being rewritten somewhere. JWZ's law may even be relevant here: "Every program expands until it reads mail". It seems there is always a large group people out there working on messengers.
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.
It could've been the HipChat revolution. It was so close to being just that. As a user of both HipChat and Slack, however, the difference is vast. Slack had a rich API an integrations well before HipChat did; presents rich content substantially more attractively; had first-class mobile support off the bat; tracks unread messages when you're offline (this one is extremely frustrating in HipChat); made being a member of multiple teams simple; had a much smoother signup process... etc.
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.
Revolution? Drinking the kool aid much? My team has it. We've had it for a month or two now. There has only been a handful of posts and most of them are "TGIF" posts.
I realize you're skeptical too, but I'm saying I wouldn't even go as far as to call it a revolution. Call it a trend if you'd like, that's giving it too much credit.
Yes it is fairly ridiculous. Which is why an open protocol / non-closed environment would help solve this.
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?
I dunno, I love being able to easily switch between different teams. Plus, they've just introduced audio, and video is next.
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?
Thanks for the link. However it is quite old, and Telegram was responding to the discussions and comments, demonstrating at least some respect for the feedback and perhaps doing something about it. Is there a more recent audit? I came across this - https://www.eff.org/secure-messaging-scorecard - a while back but it doesn't seem very thorough.
So, is any of those projects proposing something better than XMPP as IETF standard, or may be someone is proposing to improve XMPP further? Without interopearibilty it will be just +1 to the sea of incompatible solutions.
I wish we could just hurry up and come to the ultimate conclusion that we always had everything we needed with IRC. I can't understand why we're still in the jungle of high level applications replicating a low level protocol.
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.
If only there was a well supported, standard, open and interoperable text messaging protocol (with multiple implementations) that companies could host themselves...
This comes up every time, and as usual you have totally missed the point.
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 honestly don't get this. I've been using IRC for a few years, but I don't think nearly enough for blind eye nostalgia to take hold.
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.
I don't want "backlog" (read: see what happened when I was gone). I want full-text searching of the entire channel history. I already log my IRC conversations, and it's a pain in the goddamned ass to ssh to my bouncer, grep through the logs, and try to find what I was looking for. I want to type in the same client that I'm chatting in, and be able to reference this message to other people. IRC doesn't do that.
grep works way better than Slack's search, which makes you wait several seconds per tiny page of search results. I look forward to the day when Slack catches up to grep.
I think the point is that we should enhance IRC or XMPP, or create a new federated and open protocol that supports the features and easy setup Slack offers. Users suffer when we create proprietary protocols and walled gardens. Can you imagine if someone using Google Mail couldn't send an email to to someone using a university, government, or Yahoo email address? It would be unacceptable. However, this is the situation we are in with real time messaging protocols. It's infuriating to me that developers are content creating these systems. It's unethical, in my opinion.
A distributable VM or docker container, or even ball of scripts fixes the configure/host package. And there are plenty of easy to use IRC clients, perhaps make and even dumber/simpler one. Easy problem to solve.
It really isn't hard to use. Firefox has a great extension called Chatzilla that makes it wonderfully easy to use. Maybe it's hard to host, but you can just claim a channel on freenode if you need to.
It's easier to host (at least on the scale that most teams would, few nodes, few tens of users, no need for services -- basically `apt-get install ircd-of-choice`) than to use, but I disagree that it's easy to use.
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.
Are you fucking kidding me? I've been using IRC since I was 10. If a 10-year-old can figure it out, I think a professional engineer can figure it out. Using your typical IRC client to join a channel is just 4 steps:
1. Download IRC client.
2. Pick a nickname.
3. Pick a server.
4. Join a channel.
With something like kiwiirc, you can even omit steps 1, 3, and 4: you can give someone a URL to a particular channel on a particular server. Just pick a nickname and click "join". It's really simple.
> 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've never needed to open an SSH tunnel to connect to IRC. I click on the Xchat icon, and two seconds later I'm connected. I don't know where you're getting these ideas that using IRC requires consulting the RFC or opening SSH tunnels, because you don't need to do either of those things.
There's two ways this argument goes awry: "IRC is fine, you just have to be smart enough" and "Only ever use IRC for the things it does well", I thought we were on the other branch there for a bit.
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).
Those are all good points (hell, I've been using IRC for nearly 17 years and I still don't know what half those flags mean). I think it's the first time I've seen a good argument about not using 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.
Yeah, we tried that. You forgot setting up TLS, authentication, and oh you wanted a backlog? You'll have to switch to this different client that runs in the cloud / on a Linux server.
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"
Actually I know several IRC channels that have bots that send messages for activity on GitHub, Twitter, etc. And writing IRC bots is among the easiest things ever. The IRC protocol isn't hard and there are lots of libraries, snippets and bots out there.
Yeah, comparing it to Google Wave probably is a bit too much. In my neck of the tech woods HipChat is still pretty hip. I suspect that by the time we discover Slack, something else will have taken Slack's place as the new wave. Meanwhile I'll just keep visiting the same IRC channels outside of work that I have been frequenting for a decade. Will Slack be around in 10 years? Maybe. Will it be the poster-boy of internal chat? Unlikely.
You mean the same IRC that doesn't include basic features like the ability to receive messages if you aren't currently connected? The same IRC that has horrible scaling issues once you try to really use it? The same IRC that is a miserable experience to setup, administer, search, and even use?
Stop touting IRC as the "perfect" chat system. It's far from it.
Traditionally offline message caching would be the responsibility of a bouncer, or something like memoserv. There is an interest to make this responsibility part of the server in IRCv3, though.
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).
99.9% of Slack users don't give a shit about hundreds of thousands of users in on network. Slack scales better than IRC at anything other than absurd rates.
I don't understand your point - Slack can't scale for extremely large teams well. I've watched the desktop and web app grind to a halt on the first load of a channel because it's still loading in channel history/offline messages. Beyond that, when trying to tab-complete a nickname this similarly almost freezes the desktop app. This has been my experience as part of a team on Slack that has 4000+ users. These are client-side problems, really - but I don't see how you can say Slack scales better when all of its [great] features come at a cost that limit how large a team can be. The larger the team, the more noticeable it becomes.
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).
I think their point is that open standards are good for user experience. Can you imagine if each browser implemented their own hypertext format instead of html? Or Stylesheet language beside css? Or they used their own application protocol instead of http? Or if email wasn't federated; Can you imagine not being able to send emails between networks, so nodamage@gmail.com couldn't email smadge@myuniversity.edu? No matter how good the user experience of these nonstandard protocols and formats were, the user would suffer.
if only getting external collaborators or non-technical users into IRC didn't involve sending them a 15-step howto on configuring screen and ssh and could be as simple as "check your email and click the link you get"
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...
The question should be "why not use a self hosted irc client instead".
At least developers will use IRC anyway to get and stay in touch with open source projects and the countless communities that have their own irc server/channel. Why not use one protocol that's widely used?
because they're not user friendly, and my company wants to stay in touch with more than the developers. with slack, we can have all the admin and sales staff in the same virtual space as developers and operations - how easy is it to do that with IRC?
Discord isn't open source, AFAIK. Like Slack it's another data locker. And IRC isn't a solution because of it's age and issues like offline access and relatively poor clients.
Where I work, not even a very large startup, we spend a lot of venture money on a PR firm. It's pretty common for a PR firm to push content to journalists and blog writers and really it works nicely most of the time. It bugs me in this case though if it is a PR fluff piece.
Eh, the number of downvotes I'm seeing for a contrary opinion to article about something not really controversial is also pretty weird. Seems like evidence of a concerted promotional push on HN to be honest, if only anecdotally.
The first few times these discussions were interesting. But for every submission mentioning Slack, somebody has to come and claim that IRC is all anybody ever needed, and all the arguments have been rehashed over and over. The alternatives mentioned in the article on the other hand are barely discussed at all.
I find it interesting that all those who claim IRC is insufficient or is too hard to implement (they say the same about XMPP) don't ever seem to say what is so hard, or mention the features that are missing.
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.
I was in the LCA2016 IRC channel and at LCA2016 in person. I really wish we could have CCC [1] levels of "audience participation" because it allows people to interact with the conference who may not normally be able to attend. The live streaming was really well done but I think there needs to be One True Chat Channel for LCA2017. Maybe that means using Slack or similar and swallowing a bit of FOSS pride for a while.
Because such comments are at this point inane and uninteresting. As has been mentioned ad nauseum, Slack and friends are winning because IRC is a pain and lacks really basic creature comforts like offline messages and anything but text.
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".
Only as inane and uninteresting as the comment you just posted.
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.
I'm sorry but from where i am it's not "contrary opinions" being downvoted, it's useless dribble.
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.
It's not even that great of an article, and yet it's the top post on HN? I hope at least dang looks at the data. I'm sorry it's pretty suspicious. Like what is so notable about this post that it warrants being at the top? Above the living social layoffs and the various other way more interesting things on the front page right now.
Worst case, it turns out being a legit article, in which case it's cool. Eh, no big deal.
If you're worried about the upvotes on the article, they're definitely legit (as far as we can tell). I suspect it's as simple as that Slack is a hot topic (for or against) and people here like open source. And are passionate about chat software.
if only IRC was sufficient for the needs of modern workplaces. We use it, but it requires you do things like write a bot just to send a message to someone who is offline or store history so you can refer to it later.
IRC lacks message persistence across devices and sessions, which is a hard requirement today. It could be implemented but would require distributed storage, queueing, etc. between servers.
Messaging protocols are largely fungible these days, which makes them irrelevant implementation details. A major reason for the success of Slack is around the end-to-end UX. It's not "perfect", whatever that means, but it has met important needs that the "well, we already have IRC!" portion of the world has apparently never dreamed of.
That's Slack's main feature. Well that and gifs. IRC on the other hand is
James has left the channel.
Bill has left the channel.
Samantha has joined the channel.
Samantha has left the channel.
filled with worthless status updates
Martha has gone idle
that make it
Bill has joined the channel.
terribly easy to
Bill has changed the channel topic to "ZOMG! Ponies!"
miss things
Martha has become active
Martha has left the channel.
Well, in Slack, you don't leave by disconnecting, so that lowers the volume of people joining/quitting because they moved their laptop.
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.
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.
They have an IRC bridge you can connect your IRC client to. It probably can't do all the things (because IRC has no way of expressing them, and I wouldn't be surprised if they didn't spend too much effort on it), but it works.
You actually can use a regular IRC client with Slack. Though obviously anything that isn't supported natively by IRC comes through as a URL or encoded somehow.
I don't know why people think Slack is any good to begin with. It's fine at first but the more people use it the more unwieldy it gets.
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.
What I conclude from this is that open-source developers are all hungry for good specs (for a killer application).
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?
They're all different when it comes to communication bandwidth and effectiveness.
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.
We started to use Slack in our company but it wasn't adopted by most of the people. Desktop version requires too much resources and it was unacceptable. We backed to Skype again. Has anyone ever had same experience?
It's already here - Bitrix24. Light years ahead of Slack. Free for unlimited users without silly restrictions on search and other crap. And GASP it comes with actual work tools beyond IM.
Could not read this from wired.com due to my router has adblock enabled. Wired says if you don't let us do ads you can't read on. How did they detect that?
I don't mind them, normally, but in the case of Wired their detection is broken for uBlock. It continues to detect the blocker as on, even once disabled. So, reading Wired is now impossible for me, even if I accept their ads (which, I tend to be fine with for companies I trust not to be too invasive, and not to have ads that make noise or start video without warning).
Ghostery counts 27 trackers for me on this single Wired article, 19 of which are classified as "Advertising". I would not call this "not to be too invasive".
Exactly. The whole piece is < 900 words, mentions about 4 meaningful pieces of info (current Slack stats, names of 3 OSS competitors and a line or three about their rationales, history, 1-2 added features). Hardly "must-read" territory.
For those ~15 lines of unwrapped text, the whole page is 1900 lines in total.
Too bad Google insisted on dead-birthing Wave by throttling access via beta invitations.
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.
This is why I sort of hate open source. Slack is doing a great job, their prices are right. So why is it OK to destroy that? With what is going to be not as good stuff?
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.
So you have a problem with open source putting out alternatives, but you're perfectly fine with the free market, in which companies put out competing products all the time? I'm not trying to start a flame war here, I'm just curious as to why you think that a community of programmers working together to develop a competing product is any worse than a company like HipChat doing the same thing. I, for one, welcome this kind of collaboration.
How is open source 'destroying' anything? Last I heard Microsoft was considering buying Slack for billions of dollars. I don't think they're destroyed.
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.
Nah, I use open source every day, I've contributed to it.
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.
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.