Hacker News new | past | comments | ask | show | jobs | submit login
RocketChat: Slack-like online chat, built with Meteor (github.com)
155 points by sachalep on May 29, 2015 | hide | past | web | favorite | 112 comments



Funnily enough there are actually multiple Slack-like chat app projects underway in the Meteor community. I guess building a chat app is the new building a todo list app?

Yesterday at Meteor's main meetup Devshop this was presented: http://spacetalkapp.com/ and the speaker mentioned that there's a big community effort underway to keep improving it.

Let's see which one wins the race :)


I think chat apps are the new todo list app. Everyone is building one and frankly they are all boring and don't offer anything significant.


I tend to agree. Instant messaging seems to be dying out in the workplace. I used to find it a highly effective mode of collaboration, especially in large enterprises. Small shops seem to leave it off the list. We cranked up Slack for my team of 15 devs, but since we are co-located it didn't add any value. I guess if you were trying to make a buck off the cloud an IRC SaaS solution might look like a good idea. I don't think Freenode has to worry. :)


It doesn't hurt that Meteor is basically a chat app out of the box. Just hook up the accounts component to the DDP component and voila.


A chat application is pretty much the canonical "Hello, world!" of socket programming. No wonder it is becoming the "Hello, world!" of web sockets too.

Normally, the progression is time-server, echo-server (with timestamps, sometimes), "selective echo server" (don't reply to sender, allow multiple recipients/subscribers) -- aka "chat".

What fun is message passing if you've got no one to pass messages to, or receive messages from? And when you're doing that, you have chat! :-)


> Join SpaceTalk on Slack.

So they're not eating their own dog food?


I've been building https://github.com/mattfeldman/nullchat, a meteor chat application as part of a commit-a-day pledge of working with meteor.

I think the reason there are a few of these popping up is that it's a lot of fun to build a chat application with meteor. I never intended to be a 'clone' of slack as as much as rocketchat or spacetalk.

I've been running it for a small group (~10 active daily users) for about 6 months - it has more social features like rich embeds, mentions, notifications, sms gateway, giphy search etc.

Demo Instance: http://nullchat.space


Would you be willing to join efforts with Rocket.Chat? There's a lot of neat stuff on nullchat that could be really useful there.


So you set this up and you use it for a few hours and everyone on your team is like hey this is kinda cool.

* a month or so passes *

Now everyone is invested in the tool and since the expectations have been set by things like Slack they expect integrations to work flawlessly, search to be infinitely fast, 99% uptime, Google OpenID authentication, and a slew of other features and before you know it you have someone spending two hours out of every day keeping it running.

As a personal project for kicks? Sure it's cool. Would I let me company run it? Hell no!


Unless you know they never used Slack, so there are no expectations.

And your company wants to run OSS, so "has a guy" that already maintains the other pocketful of apps to company is using.

And since it is OSS, you can add Google OpenID auth if required.

And the slew of other features you want to add, but can't to Slack even if you knew about Slack.

Don't crap on the idea just because Slack is Slack and this isn't. Apply your "a month or so passes and now everyone is invested in the tool" scenario to any OSS alternative and your argument just comes off as fanboying.


Well it's not just Slack that sets expectations but pretty much every SaaS webapp out there.

Of course, you can add features but do not underestimate how much work it is to do so and is it even worth the effort? It is what you should be spending your time on as a company if that's not your business?

And let's remember Slack is going to video and voice soon...


What if you can't run slack because your company doesn't allow chat services that are externally hosted?

EDIT: This seems like something that never gets brought up in any discussion of Slack. No company I have worked for would have allowed an externally hosted chat service. Have I just been unlucky, or is it just the people in my situation never speak up?


Lots of enterprise companies demand full control over all things. Its not uncommon at all.


It's not uncommon, but it's uncommon around here.


It's certainly one of my major griefs with Slack. I don't want my entire company's internal communications to be hosted by some third party startup I can't at all trust.


I would say this traditionally case but I think things are slowly changing even in the Enterprise world, where they too are starting to realise it's not realistic to be good at everything as well as their employees demanding better services.


Unlucky. We used Slack at the last three companies I worked for.


You can't be a very loyal employee given that Slack has been out for less than 2 years.


I'm not. I'm a consultant.


Also, there's nothing stopping your company from making the product better.

You shouldn't be spending 2 hours each day solving the same problems. If you make fixes, push them upstream (and others will too), then everyone gets a better product.


When you are running a business, you use tools to make your life easier.

The reason I pay for Slack is precisely so I _don't_ have to push fixes upstream.

Tools are a means to solving a problem. Something being open source is not by itself a plus. I don't want to be developing a chat client so I can use it, I want to build my own fucking company.


So...don't use it. Honestly, there are other people here that will see this link and go "hey I want to add this feature in this" and the tool becomes better. Once it does I am sure you're gonna come back and leech on it.


Obviously I have the option not to use it, but we can still have a discussion about the pros and cons.

What I'm saying is that "pull requests welcome" is a really lazy way of telling someone to support themselves. That's fine if you have a unique set of needs, in that case you should be building things out specific to you.

For something like chat, most people have a very similar set of requirements, paying Slack a couple of dollars per month to handle it is awesome. Would it be cool if Slack were opensource? Maybe, but that isn't why people would use it even if it were. It works really well, there is a team behind it that is paid full time to develop new features, and we can focus on building our own company instead of using bandwidth building tools for basic functionality.

That doesn't mean there isn't room for improvement, but the places for improvement in Slack aren't that it isn't open source.


OSS isn't for just the contributors.


Another company offering SaaS products is not a plus by itself either. The idea of "pay us so you don't have to push upstream fixes" is just another spin on the usual marketing agenda for cloud-based companies. Either way when running a business you need to consider what kind of infrastructure you're investing in.


This. Was about to respond with a comment like this, but I think it's just better not to devolve into that argument (which has definitely been done before, countless times).

When Slack doesn't have some feature you need, what do you do? switch? pay some other company? develop it yourself? both positions have tradeoffs.

But by all means, if you don't have time to contribute to open source, then... don't, and buy the pre-packaged service -- I'm glad people think this way because it makes it easy for SaaS startups to profit -- which moves the industry forward anyway.


Right, so then... pay for Slack. Leaving negative comments about such a general "problem" with open source software isn't really productive or warranted, I think.

It's not the open source project's job to make themselves appealing to you, you're just looking to use and use and not give back.

Also, the benefits (intrinsic or otherwise) of open source is a completely different discussion (that people have by and large already had).


That also happened in transportation: Ferrari set the expectations so high that nobody rides bikes anymore.


Another sweet new open soruce Slack alternative is Friends, https://github.com/moose-team/friends


There's also letschat: http://sdelements.github.io/lets-chat/

Dunno why people tend to flock over to the propietary option though. :(


> people tend to flock over to the propietary option

Because it Just Works(tm) and there's no fiddling or faffing about necessary. I'm all for [FL]OSS applications, but sometimes proprietary solutions, even if they do the same task, are just easier to use and integrate (both technically and bureaucratically)


In the case of something like Slack though, there's a huge business risk: Storing your confidential internal discussions with a random startup of questionable security practice.


True, but it also gives you an out if customer data is breached. You, with good faith, contracted a thirdparty to manage and secure your data. If you run your own Letschat and some exploit is found that dumps your chat db, you're/your company is on the hook.

FWIW, I don't and likely will never use or promote Slack for intracompany chat.


The opposite. If you install opensource software on you own servers, and make it available only for your company's intranet, you are perfectly safe from outside attackers. Proprietary software can also exploited or they can just sell your data for bucks, when they are about to bankrupt.


Unless someone compromises your intranet as a whole.


> Because it Just Works(tm) and there's no fiddling or faffing about necessary.

That's what marketing would have you believe. For example Hangouts broke the ecosystem horrible, and now xmpp and hangout users can no longer intercommunicate (and wonder why their messages are silently dropped).

Users complain that they need 6+ apps to keep in touch with friends.

The real answer, IMHO is "Because they market it as 'just works'.".


Then you put on a great deal of risk in terms of owning your data, having unwanted changes in the product, or Google acquiring (and closing down) your service provider.


Well for one thing, there's the hassle of maintaining it.

Don't get me wrong, I maintain lots of things. It's my full-time job. I count it as a victory every time I can gain some capability without adding some additional thing to maintain. Double victory even better every time I can take something I thought I needed to maintain and throw it on the scrap heap, eg because its functionality was subsumed by something else I need more.

Then there is security. If I take this open-source app and deploy it on my servers, and there is a vulnerability that results in privilege escalation, I have just opened up my network. Skilled admins will balk, but if I chat over Slack and there is a security vulnerability in Slack, even something related to my own (or my users' own) incompetence, I've just exposed... worst case is Slack, and Slack's network, and whatever my users already saw fit to expose to Slack.

It should already be eminently clear to my users that data in Slack's hands has left the garden of our own control, and is not to be trusted.

I am a proponent of other and opener Slack alternatives (to put it mildly), but I prefer things that come in a bigger stack, so when I waste my time setting them up, I get something back better than... my own watered-down version of Slack that I need to add to the maintenance charts.

(Insert small, shameless plug for Urbit, which has a centralized talk server and stores backlogs)


> Well for one thing, there's the hassle of maintaining it.

You're confusing FLOSS with self-hosted. You can use free software, but hire it as a service. Example: https://githost.io/


about the security issue, you're wrong: if you want to host it for your company, put it behind a VPN or defend the site with a password on the HTTP level. This prevents all attacks from outside.


That also hinders remote access and promotes a sense of false security with users who don't know better. Better to tell them to use a secure channel for sensitive things. Then again if you thought slack was really secure I could set how you might think that.

There are both arguments. We have a VPN but don't let just any user on it. Then again I'm not sure if I want those people on slack with me either. The times when we want to use slack can tend to not overlap with the times we want to worry about whether the VPN works or if I can connect to it. We even use slack to organize a distributed disaster recovery and coordinate it!


Friends is P2P which could be useful for cutting out points of failure.


If it's p2p do you lose the ability to reliably store history and do search on it?


The fact Slack is a thing is evidence of how horrible dominant IM companies are at their business.


They're more interested building their own little walled gardens. If they spent as much effort improving their products as they did breaking integrations then there wouldn't be a Slack.


Dominant IM companies are a thing?

I know this is serious, but maybe I misread your intention. The thing that makes Slack greater than all of the dominant IMs is that IM is their whole business.

Everyone else is busy "improving" gmail if you're Google, or monetizing voip/video chat, or (whatever it is that SalesForce does besides Chattr), meanwhile Slack is just chat, and whatever else you expected chat to encompass.


> Everyone else is busy "improving" gmail if you're Google, or monetizing voip/video chat

Yes. Instead of improving, they do voice, video, profile pages, silly pictures replacing your text and all that crap.

The only actual innovation I've seen to IM is ability to edit your last message.

Last people that tried to improve the actual IM chat were Google Wave but it crashed and burned because they fixated on everybody seeing as what everybody is writing when they write it (which was something nobody wanted).

Today, almost 20 years after ICQ people default to Skype even though it's closed crap for that purpose.

Any IM company that had some users had potential to become twitter or even facebook, but instead someone fresh came and stolen their lunch while they were playing with crappy voice and sponsored news feeds while accumulating bloat on their software.


There's a link to an "online demo" but then it asks for your login info or for you to register. That isn't really a demo then, is it?


That's the brick wall I hit too. I'm not giving them my email address for a demo, and I'm not logging in with a social media service.

I suppose I could download it myself and try it out that way, but that's a ton of effort for something I may not even want in the end.

Rocket.Chat devs, if you're listening, please provide a way to demo the program without giving up real information.


Agreed. If you still want to use it however just enter somerandomstring@mailcatch.com and then check the mail at http://somerandomstring.mailcatch.com/. Very useful when you want to bypass such useless logins, just know that the mail is public.


Thanks, I didn't want to deal with one of those mailinator-type accounts but this is even easier. Adding it to my "cool tools" bin. :)


+1


One of the devs said yesterday that API integrations are coming soon. After this, replacing Meteor's Blaze for something like React could make this a serious slack alternative...


What specifically would a user notice with the difference between Blaze and React? I get react is a bit faster under the hood. Its not something that would make this a 'serious' alternative?


I'm an avid react user and I completely agree. It wouldn't make it a 'serious' alternative just from that, although I would always love to see react used :).


The serious alternative is having both: API integrations + react, specially the first one... Like you say, react alone won't make a big difference, but it could potentially make the UI less laggy.


Remind me what slack offers over xmpp+web client, and/or irc+web client (apart from the lock-in, and marketing, I mean)?



One of the useful parts of Slack is push-notifications to my mobile device when I'm away (and only for things I opt in to).

Do any of these new-fangled open source Slack alternatives offer notifications for people on the go?


It's planned. You can see whatever is planned or not in GitHub issues. Also, you can create some feature request there or either contribute with something.

https://github.com/RocketChat/Rocket.Chat/issues.


Don't forget the integrations, I love those. The rest is easily replicable.


Pretty amazing effort, very clean UI and works flawlessly so far...


[deleted]


Are you asking if people would consider to a better but cheaper version of Slack? Because the answer is probably yes. Gotta get the integrations right though.


Parabéns pessoal pelo projeto! Pelo que vi, todos são brasileiros, isto é muito legal :)

--English-- Congratulations guys for the project! From what I saw, you're all Brazilians, this is very cool :)


I can't seem to find a Meteor-built IRC client but maybe I'm not looking hard enough. Is there one? Why not combine the strengths of Meteor with IRC?


Offtopic

What are some resources for getting started with meteor. Being able to build a chat apps like these seems powerful.


Go to https://www.meteor.com/ and Start tutorial. After installed you can go through the tutorial in an hour or two depending how deep you go, and it comes with a number of examples (show with "meteor create --list").

Discover Meteor has some more; they were giving their book away (see https://www.discovermeteor.com/blog/we-made-our-book-free/ -- first 4 chapters are free).

That may be enough for the basics. Then look at telescope, or one of the chat apps listed here or search on github. Also plenty of conference talks on youtube.


Does the demo work for anyone? Would like to check it out, but does not load, just hangs.


It loads now. However, can't login as it demands an email. For something like a demo, this seems a little overkill.

For something I might host for my employees or people I intend on collaborating with I guess it makes sense.


Seems like it's down/not responding? Unable to get in at the moment.


With all the self-hosted options, how do mobile push notifications work?


Are mobile apps planned?


this. I've been looking for something to replace facebook messenger to use with my friends. Whatever it is, it would need mobile push notifications. Currently I'm using tinfoil facebook so not getting push messages causes me to miss long portions of conversations in my group chat and I don't want to just use another service, I'd rather host it


Whats wrong with Telegram?

https://telegram.org/

edit: just saw where you want to host it...


questionable crypto, by that questionable ethics, not fully open source


xmpp?


It's written in meteor. Meteor is for writing web and mobile apps. Rolling a mobile version goes something like $meteor add-platform android and $meteor run android-device. (you can replace android with ios).


I guess improving XMPP isn't as cool as building something brand new?


This isn't just a protocol.


XMPP is XML-based, noisy, and just plain annoying to deal with. There's only so much polish that can be applied to a turd...


- https://github.com/otalk/stanza.io

- https://github.com/xmpp-ftw/xmpp-ftw

It's really a shame when people can't look past the surface, and just emit vague subjective rebukes like this. XML may not be fashionable today, but really it poses no technical issues compared to the kinds of actual hard technical issues involved in making an open and decentralized IM network that XMPP has been solving for 15 years.


Using someone else's wrapper library is like (insert sufficiently disgusting analogy for doing something with a pile of excretia).

At the end of the day, the underlying product is still an overwrought, overly verbose mess, and the wrappers only serve to hide that. And following the law that all abstractions are leaky, you're going to have to touch it eventually.

A better replacement would be IRC. It serves almost all of the XMPP use cases with no extension, and i'd wager all of them with the right daemon and right plugins.


Are there any sensible, albeit less popular, modern equivalents to XMPP?


IRC is better and actually more popular. IRC solved the problem of instant messaging over 20 years ago, and solved it very well. This is a problem that everyone and their mother attempts to re-solve and they always end up with a solution that's inferior to IRC. Just deploy an IRC server folks!


IRC solved basic communication, but the necessity of bots for things like authentication for usernames, logging, and retaining permissions are inelegant kludges, in my opinion. If XMPP has problems, so does IRC.


I don't think it'd be very difficult to set up some sort of web UI for account creation, combined with existing in-client features for usernames/passwords. That'd be more worthwhile than building a new solution from scratch.

IRC has advantages over XMPP by having a much wider variety of clients and the fact that you can create your own integrations for things like build automation in a very short period of time thanks to the simple text-based protocol.


Yeah, I agree with you. Some autocracy and curation could really make a nice ircd + bot + UI set of utilities.


Once you realize that everything on an IRC service is tied to a user account, it makes a bit more sense. And extending from there, different user accounts are responsible for different things. (The *serv accounts on most networks).

I always thought it made sense in a way - it makes for a very neat separation of concerns and makes the stack more modular, since you can now use almost any combination of IRC daemon and services package.


I appreciate the separation of concerns, but I meant more that "agents and clients sharing the same channel of control" is inelegant. It can lead to race conditions in netsplits, even, from what I recall!


IRC and XMPP have the same weakness: no server side persistence.

Don't answer "bouncers" for IRC. It is an ugly hack. With XMPP the server MAY provide history, which makes it unreliable.


Bouncers. They aren't an ugly hack, are easy to deploy, and make the experience way better. I'd prefer to host that sort of thing on my own infra, too.


xmpp is a protocol, it doesn't make any sense to say that it doesn't have server side persistence. Lots of servers that implement XMPP persist chats.


matrix (https://matrix.org/) is a more modern messaging protocol than XMPP; it revolves around HTTP and JSON because it's the most logical today the way XMPP is based on XML because it was the most logical at the time. Let's hope they can achieve something here !


I also wanted to come in here and promote matrix. You can use it internally, or you can federate it. It takes a lot of concepts from XMPP, and is essentially json over http with an "eventually consistent" synchronization between clients and servers.


Yes. Telehash. http://telehash.org/

From the same developers who designed and built XMPP.


Not really, there's an extension for it to work as a binary protocol.

No, not this one though: http://xmpp.org/extensions/xep-0231.html

XML also makes extensibility a lot less painful.


Why wouldn't I just use slack?


It's not free, it's not controlled by you.


could not register: "Please Wait..." for 5 minutes and counting


Same for me, demo registration doesn't respond


It's working now.


Not for me, I was able to get to the confirmation email, now it is just stuck in a loop.


Sorry guys.. this was just our development server.. we were planning to release it in 3 weeks time :)


No worries, I guess I'll try again in 3 weeks. :)


Gorgeous!


test


2 questions:

What is Slack?

What is Meteor?


1. a hosted chat service with an UX people really like. https://slack.com/

2. A framework for writing realtime JavaScript applications. https://www.meteor.com/


Slack is a software-as-a-service chat application:

https://slack.com

Meteor is a javascript app building platform:

https://www.meteor.com


I did a containerized deployment for the project: https://github.com/giantswarm/swarm-rocket. Still has some issues that need to be resolved, including configuring the mail server, long build time, and a handful of other issues. If someone finds it useful, let me know!


how can i help you to get that working? can we add it to our repo?


Howdy! You can email me or ping me on Twitter or my email is {{my_handle_ here}}@giantswarm.io. Twitter same.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: