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.
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.)
Good luck, you are working on an important problem.
Thanks for giving it a shot, at least. It's getting to the point where if I wanted to keep in touch with most of my friends all the time, I'd need to carry two or more devices (thanks for keeping iMessage closed, Apple).
Have you written a stand alone library which communicates with skype?
It looks like an interesting platform, but I was a bit surprised by what I found at:
https://developer.actor.im/docs/encryption
"MTProto v2 Rev3 enables encryption support to replace or enchanse TLS one." So far so good - here's someone that's built on top of NaCl and built a legacy-free encryption system on top of well tested, known primitives, I thought.
But: "Actor encrypts message with US encryption and then again encrypt with Russian encryption that in result guarantee absolute encryption streight" (sic).
Uh. This sounds like applying a "political" reasoning to layering security: AES might be backdoored by NSA, GOST(?) might be backdoored by the FSB -- but using both, only double-agents will be able to foil our encryption!
While the truth is probably that you're know vulnerable to buffer overflows or other more mundane software errors in the now double-sized encryption code -- and get none of the (potential) benefits of a clean, modern architecture on top of just NaCl?
In addition, it appears you also use curve25591, possibly an implementation derived from NaCl:
https://developer.actor.im/docs/securing-server
"For secure communications Actor Server have to be configured with Curve25519 keys. To generate them, use actor-cli util:"
So that's three codebases worth of bugs, rather than one. Any plan to simplify this part?
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?
How do other servers know how to reach me?
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.
You want to pick and choose your UI? That is an anti-feature. One user sends an image and the other cannot display it because he uses a terminal client. One user sends an emoji, another client only displays a box, because he has no glyph in his font. This is already a problem with XMPP. It has lots of nice features, but each requires server and client to support it. There is no "Full XMPP" label.
And since you prominently talk about the protocol: XMPP probably has all the features one needs. Why hasn't it won yet? Because the complexity of all server-client combinations makes a good user experience too hard.
What is the problem with using different clients/networks for different groups? Why do you want to mix work and private groups into the same app? What does matter (especially for web apps) is a unified authentication scheme (Mozilla Persona would be my favorite), so I can quickly switch between them and do not need lots of accounts. Thus: Federated accounts, but diverse chat solutions.
(disclaimer: I slightly exaggerated to play devil's advocate)
That argument is like saying we should only have one HTML browser because text-based browsers like w3m could exist.
And "one user sends an emoji, another client only displays a box, because he has no glyph in his font" is an issue between different operating systems. Even in a non-federated system like Slack I used to get emojis from people using iOS8 that don't display properly.
What about Spectrum http://spectrum.im/ ? I am successfully using Spectrum as gateway to Skype (except groupchats ATM, some bugfixing pending) and IRC from my XMPP client apps.
What about XMPP in the whole? It looked depressing few years ago, but times have changed, I can help you to catch up with nice novelties.
I'm personally working on Movim, a nice-looking "Social-IM" client fully based on XMPP (https://movim.eu/). The main goal of the project is to show that we have now all the tools to build a decentralized, standard and universal IM (and also social !) network without reinventing the wheel again and again.
You can have a look at our latest release-note as well https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e3122... (this blog post has been published/edited using Movim and XMPP ;)).
And Movim is also compatible with Spectrum to offer interconnection with other networks ;)
I'm curious though.
What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings.
I use a nice web gateway (kiwi) on top of an IRC channel for my student office hours and it's easy. They just supply a username and log in. No software to install, the UI looks nice, and students don't have to sign up for anything.
If I had the resources and the money, I'd focus on a good modern IRC client and server.
Am I wrong?
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.
your use case is very different, and i wouldn't expect any pay-for-chat service to make any sense for it
[1] https://matrix.org/docs/projects/as/rocket-chat-federation.h... [2] https://matrix.org
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…
Now we have more bandwidth, and sending XMPP as a server is negligible.
I just would prefer JSON to XML. :-)
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
Think of a bar that lets you bring drinks from other bars. It doesnt have good prospects.
Laziness.
JSON in, JSON out. HTTP codes tell you what response you got. TLS on an https connection for secure communications. WebRTC for voice calls, and you just query the API for the signaling server to use.
Obligatory xkcd reference: ... ok, never mind, you probably all know which one I mean.
Oh wait, IRC.
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.
It's not like you're stuck with ugly terminal only clients anymore. There is KiwiIRC, IRCCloud, and several other great web clients that not only let you connect to any server but provide bouncer services and backlog. There are also plenty of easy to use native clients that don't require any configuration.
There are some benefits of Slack, but the ones you mention aren't them. In fact, seeing how you CANT host your own Slack server I would say "difficult to host" is a flat lie against IRC.
(No I don't work for them. Self-hosted their AMI at last job, found them to be friendly, easy to deal with folks)
Stop touting IRC as the "perfect" chat system. It's far from it.
IRC scales much, much better than Slack. Unreal or InspIRCd or Charybdis whatever - Slack fails miserably for hundreds of thousands of users in one "team"/network.
I do agree administering/configuring IRC servers has to get nicer. I personally want an IRC server that exposes a REST API for online configuration (no rehashing of a config file).
and, if only there was push button per channel access control set up out of the box so that some users can join some channels but not others! no, not channel keys, those are busted (what do we do when someone stops being involved in a channel? rotate the channel key?)
there's way more in slack than IRC, so there needs to be way more in a slack killer than IRC...
Have you heard of irccloud.com? You should check it out. My mum could use it (I'm not affiliated with them in any way besides being a happy customer).
Love Discord, wish it were, but I just did a quick check and couldn't find anything there
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.
I'm not very fond of IRCv2, and have moved away from it where I previously used IRC. But IRC is popular, has a lot of clients, and v3 has a lot of promise. Why didn't the author bother to mention it?
[1]: http://ircv3.net/
It's a submarine for Mattermost which released a new version today
http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf
Highly-Scalable Searchable Symmetric Encryption with Support for Boolean Queries (2013)
I do hope to see some work on better user interfaces. Our team recently switched to Slack from Hipchat - many features are better, but the desktop UI is really unpleasantly sluggish. It seems unreasonable for a chat application to stutter and freeze on even small amounts of data. The trend for wrapping web UIs in desktop apps is not a good one, in my experience. Hopefully open equivalents will encourage the development of native clients.
Turns out they mean "electron is a native application, and our app is a webpage inside of electron, so our webpage is a native application."
Bummer. I use both Slack and Hipchat for different groups, and I'm not happy with the wrapped webapp for either of them.
The Slack native app for desktop was horrible last year, but right now it's acceptable, apart from annoying notifications polluting the application switcher.
1. is a much more complex application
2. has no perceptible performance issues
3. is also built on Electron
I've had a lack of issues with Slack, but HipChat seemed to have updates every other day and crash a lot when I used it.
Then let a thousand clients with different paradigms bloom
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.
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.
You have that - SIP and XMPP.
Please don't complain that they are complex and consist of a lot of documents, and have hard feature standartization path. It is the only possible way to openly evolve such systems - to publish serious writeups as documents on their own and have them discussed with criticism and then gradually adopted. And then you may end up with competing alternative implementations of same feature in different standards - that's also inevitable if the system is open. Because, would you be happy to have the same video codec everywhere, or you admire the fact that existing systems are flexible enough to interoperate with _different_ codecs?
The real issue is XMPP does not directly solve the problems the authors of those chat apps deal with. Doing things properly requires writing XEPs and just a lot of hassle which a company building its own little Slack killer doesn't want to invest in, and doesn't have a reason to invest in either because none of the current ones support XMPP in the first place (the bootstrap problem).
If you want to fix this, you have to do that work for them. You have to make XMPP a direct solution that says "Spin up this server, write a cool UI, and your product is done".
http://risovach.ru/upload/2016/03/mem/novyy--shablon_1085837...
HTTP and IRC on the other hand look easy at first, then you get past that and there's just more and more complications and edge cases and horror. Like all the various cache headers and behaviors in HTTP, or how all IRC networks have their own dialect that's subtly different.
I once tried to work on an IRC server interface, I read all the RFCs, wrote code, then tested with a client. Nothing worked, so I had to resort to replay what the client sent to a different network and reproduce whatever they did.
If you go read the XMPP RFCs, you should be able to write a client or a server that gets along pretty well with the rest of the XMPP world.
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.
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.
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.
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.
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.
As you can tell from my post which states that Slack doesn't offer anything unique or special, uh, no, I'm not drinking the kool-aid.
I'll try Slack... let me check Skype... no maybe they're on HipChat... SMS... oh hell I'll just call them!
Yeah, IRC is from the 80s and is lacking some modern features, but at least it was a fairly unifying chat system in its day. No one company owned it, most people could use it trivially, and there were many different clients out there to suite one's taste.
There's still a market for wrapping a protocol in a nice web app UI and hiding the complexities from the user, which is why this closed chat systems trend is getting frustrating.
Can't different chat services communicate with each other easily, without the need for a bridge?
If more chat services supported Matrix.org we could get there.
https://matrix.org/docs/projects/try-matrix-now.html#clients
Someone's suggested it in the Mattermost suggestions site:
https://mattermost.uservoice.com/forums/306457-general/sugge...
Then there's also Ricochet: https://ricochet.im/
Really, the only thing that stops me from wanting to use these services at $DayJob is the fact I have enough stuff I have to maintain. I'd really rather just pay $99/month for a 10-20 person team.
I was blown away on how much better the UX was in Gitter compared to IRC. The history, the notifications, the markup, the UI...you name it.
And Gitter is a pretty crappy client. If there was a nicely implemented client, it would be even more impressive.
But Gitter has other issues - mostly of the UX kind. One of them is that you can search for other rooms, but you can't really save that search. You have to start over everytime. Also, the default of sending you an email for every freaking message when you star a room is absolutely atrocious.
I don't even get IRC or IM. "Chat" is noise and distraction. Write proper emails or arrange phone calls.
What exactly are people using slack for? I don't get it.
We need to discuss something visual as a five-person team? A phone conference is the wrong medium.
We need to collaborate on a significant technical document? Slack is the wrong medium.
We need to have a searchable back-and-forth discussion, interleaved with other things that are vying for our attention? We should probably use a chat tool.
This is email.
> We need to discuss something visual as a five-person team? A phone conference is the wrong medium.
Shared desktop conference, such as gotomeeting.
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.
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.
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.
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.
:)
Seriously I know XMPP is pretty un-popular, but deep inside I kind of wish it was the default protocol everybody used to communicate...
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?
What are the significant differences (advantages/disadvantages)?
I get that IRC never had a particular client that galvanized the protocol as much as the many iterations of proprietary real time chat that has came and went over the past 10 years, but honestly the problem isn't the protocol, the problem is that no one was making clients meant for the mainstream.
Matrix has solved the right engineering problem first which is the persistence of the chats across all of your clients.
Email's pretty crappy but at least with email I get small, contained threads of conversation that can be searched and organized easily. Slack is like having a few giant never-ending email threads. It's horrible.
And there's still no voice.
Therefore, wouldn't it be nice if there was a website where product designers (not software developers) could post their product designs, so that the developers have something to work from?
You can also talk to Mattermost team on #matterbridge on Freenode.
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.
