Show HN: Mogo Chat – open-source team chat app written in Elixir and Ember.js | Hacker News Reader

Show HN: Mogo Chat – open-source team chat app written in Elixir and Ember.js

getmogochat.com

140 pointsSingAlong69 comments

There are tons of free apps, with contenders like Kandan (https://github.com/kandanapp/kandan) if you're looking for a self-hosted or free alternative to HipChat/Campfire, you can even find sexy-ish Web clients for IRC (https://github.com/thedjpetersen/subway).

The problem I see with message apps is that it's like email; you really wished you could host it yourself and fine tune things (as well as make sure nobody is eavesdropping). But you can't have it down or (worse) performing at half capacity. It needs to be up all the time with almost perfect quality.

Sure you can set something up yourself, but you'll probably struggle with maintaining a decent QoS, and if your team is any good, they probably won't allow that to go on very long.

And also sexy web frontends for existing IRC client WeeChat: http://cormier.github.io/glowing-bear/

Source: http://cormier.github.io/glowing-bear/

Worth noting that SingAlong (the OP), is also a contributor to Kandan - mentioned in their README

If you're working with IRC, your backend will also get DDOS'ed very quickly and very often. So there's that fun to deal with as well.

The IRC server I use at work is DDOS'd less than our website. ;)

Shameless plug, I've also written an app: https://github.com/sdelements/lets-chat

It looks a little something like this: http://i.imgur.com/djnd0Uk.png

It's still in it's infancy, currently working on a big update that includes a REST api and other stuff.

Why re-inventing the wheel? IRC and XMPP are proven technologies that scale, I wouldn't go and try to build my own messaging technology: there are hard problems like presence and notifications that you don't want to solve yourself.

I don't see how these are hard problems. We needed something simple, stateful and easy to work with so we rolled our own thing. It's only a few hundred lines of code and we've extended it to work with LDAP among other things.

...how is your [insert tech startup here] going to maintain a decent level of QoS if you cannot maintain it for a trio of IRCds and a trio node instances? You could even get away with DNS-only HA since it is purely internal so if A is down, everyone knows to connect to B or C.

The only reason I don't host my own e-mail is I haven't found an open source project that can truly compete with gmail's functionality and the fact I don't really care if Google reads my e-mail since none of it is sensitive.

I have high hopes for https://www.mailpile.is/ since if my Desktop is down, I'm screwed /anyway/.

Just my two cents.

It's not really a matter of ability, rather a matter of focus.

You sure can maintain your own IRC server, the same way you can maintain your own Git server. But it's probably a waste of time when you know that you have free or cheap alternatives (Gmail, GitHub, Mailchimp): stuff breaks, and even if you can fix it doesn't mean you should.

I outsource stuff that I depend on and don't want to waste time maintaining: email, online storage, some collaboration tools...

Fair enough. I guess I took the struggle + QoS comment and ran with that. :)

Fair enough; outsourcing is not always an option (or convenient). I actually find GitLab pretty compelling.

If you're into mailpile, you should support them for the Knight Foundation News Challenge: https://www.newschallenge.org/challenge/2014/feedback-review.... Personally, I assume that I wouldn't be able to do a better job at securing stuff up on my own, but it is an interesting project nonetheless.

And if you still have 5 minutes to kill, check out Carbon Folder, my team's entry: https://www.newschallenge.org/challenge/2014/submissions/car...

I maintain our internal GitLab instance so I definitely agree with that. :)

I'll take a look at yours, I already did the Mailpile bit.

+1 for Kandan's use of ClojureScript

Someone seems to have broken the demo by typing in some JavaScript. Doesn't seem to be sanitizing input completely.

EDIT: Looks like it's CSS, not JS. In case it helps, here's what I'm seeing [1], and here's the code from the message:

    <style>* { float: left; display: block }</style>

[1] http://imgur.com/BoZ6lrF

EDIT 2: Yup, style tags don't seem to be escaped. Tried changing colors of the room a few times, and it worked:

    <style>* { color: green; }</style>

EDIT 3: Issue filed here: https://github.com/HashNuke/mogo-chat/issues/2

This should be a major red flag to anyone.

You don't make an app/website secure by deciding on a list of things you need to sanitise.

You sanitise everything to start with.

A very common rookie error.

> You don't make an app/website secure by deciding on a list of things you need to sanitise.

I agree

> You sanitise everything to start with.

So you need to list everything you need to sanitise...

A better approach is to ban "innerHTML" from your code. You should always display user generated text in text nodes.

Just to clarify:

    var t = document.createTextNode(msg);
    content.appendChild(t);

That code sanitises all possible content in msg. I don't need to list out HTML tags, script/style tags, do special case for unicode exploits, etc.

You need to list what variables are "unsafe", but you don't need to list out the ways they might be unsafe. If it's got the potential to be unsafe, assume it's completely unsafe in every conceivable way, and don't use it in any context apart from as an unsafe text string.

The rookie code is something like:

    msg.replace("something I think is unsafe", "something safer");
    content.innerHTML+=msg;

And agreed. InnerHTML should be removed from browsers.

Ya, but if they built it so msg='<b>msg</b>' that would remove the bold, no?

So it is a bit more complex than that if they want to enable user markup. https://code.google.com/p/pagedown/source/browse/Markdown.Sa... https://code.google.com/p/pagedown/wiki/PageDown

I'm not even a front end guy but I'm pretty sure the field they are adding the user message to should handle the style, not the user message.

If one uses common choices [e.g. Markdown] that isn't how the parsers are designed.

It is [message] -> [parse] -> [sanitize], generally.

If you want to enable user markup, then build a simple parser, and use that to generate the correct styling you require.

My point was:

A) It was not as simple as you suggested if there was markup involved in the message.

B) They'd have to use a parser and I linked to a parser that sanitizes that was once used in a pretty big network of sites.

I'm uncertain if you misunderstood or are simply agreeing with me in a tone of writing that makes it sound like you disagree.

I think the point was that it's inherently less safe to allow arbitrary markup and then attempt to sanitize it, than to make a full parser that's incapable of generating unsafe HTML at any stage, all other things being equal.

The safety of widely-deployed Markdown + sanitizer libraries is largely thanks to testing at scale and a history of patches for XSS vulnerabilities.

InnerHTML should be removed from browsers.

While it's still the fastest method for changing the page DOM it shouldn't be. When used outside of user inputted scenarios it's fine.

It's still absolutely ugly code. And in many cases direct DOM manipulation beats it in terms of speed.

I, for one, am glad to see example Elixir apps with some polish that are published freely. I've been meaning to get into Elixir and Erlang, but lack of polished example apps has been a stumbling block for me, and though I have no immediate need for a TeamChat app at all, it's one of those examples like "The Todos App" that you can even perform as a code-kata in your language of choice.

It would be great if I didn't have to use any Off-the-Shelf code at all, or if I must, if I actually had the time and knowledge to review it for serious vulnerabilities. But posts like this are why I come to HN.

Thanks for reporting Steve. I'll fix it.

EDIT: Should be fixed now.

Thanks JangoSteve for reporting this.

Pierre's been tinkering..

Error on startup

    No route matches get to ["%3Ca%20target=%27_blank%27%20href=%27http:", "pierregoutheraud.fr"]

It seems that the room message state is synced via a poller, as seen here: https://github.com/HashNuke/mogo-chat/blob/master/assets/jav...

I'm curious why you decided to implement this with a poller instead of with a Websocket. There's actually a reasonably detailed answer about how to do this sort of thing with Ember Data in the emberjs.com guides: http://emberjs.com/guides/models/frequently-asked-questions/...

Either way, how did you find working with Ember Data in general? What were the main sticking points?

Here are some problems when using websockets

* Message loss * Latency * Authentication has to be done again over websockets - on every connect and reconnect. That means it is going to make the app resource hungry.

This is my first time with Ember. Experience was pleasant. The codebase is fast-changing, so StackOverflow replies become quickly outdated. You'll have to refer to the CHANGELOG.md file in their repos. And the Ember IRC channel is super-helpful.

Authentication has to be done again over websockets - on every connect and reconnect. That means it is going to make the app resource hungry.

Right, except that WebSockets only connect once in normal operation. You'd be surprised how resource hungry WebSockets aren't when compared to constant HTTP connections. Waiting 2.5 seconds for messages to arrive to all clients feels a little imperfect.

I live in a country where latency for websockets is 300-400ms for most hosting services (US/Europe). And the most common internet connection speed 512kbps.

Websockets disconnects for me frequently. So during reconnection, I'll have to reauth in my case.

Well it isn't difficult to detect that case and drop back to polling (which should have the exact same latency anyway). Aiming for lowest common denominator in this stuff seems unwise.

Totally agree. That's the right way to do it.

MogoChat is right now a one-man project, so supporting websockets and then polling seemed tedious, especially with something like Faye or SocketIO missing in Elixir. Phoenix Framework will soon have a high level abstraction over websockets (with Faye-like features). Once that's in, I'll be able to use it.

Why do you have to reauth? Websockets can carry cookies or query strings just like rest. How else do you prevent the need to reauth on every http query?

I am glad to see an Elixir app on HN! Elixir is a great language I have been enjoying messing with in my spare time. It's far below a 1.0 release but its syntax is delightful and it's been a good excuse to get familiar with BEAM and OTP as I know nothing of Erlang.

So quality of the app aside (I haven't looked) everyone should give Elixir a go.

Suggestion: Have messages instantly appear in chat (maybe with a loading icon to one side) when uses hit enter/send... then display an error if it fails to reach the server. Not enter ........ message appears. It'd make the app feel much more responsive.

Isn't every Erlang web tutorial about building a chat app?

Thanks for an example in Elixir, though:)

I would like to see a credible open source alternative to Campfire, etc, so this is nice work.

But if it's an Ember app, why don't the different rooms present as different URLs?

When URLs change the message pollers also will be destroyed and reinitialized. That would be a problem.

IMHO, chat apps usually push the limits of any frontend framework.

That's not true. It's a "single page app" with built in support for both pushState and hash-based URLs, so there's no reason anything needs to reinitialize just to update the URL.

I have written an Ember app that maintains a persistent websocket connection as it transitions around through many URLs.

No, you're doing it wrong. Apart from your controllers being long-lived and persist between routes, you're usually interacting with the data store, which caches and keeps references to records. Just make sure you're pushing data into the store instead of making requests or whatever. Also, remember the Run Loop.

Check out https://github.com/sdelements/lets-chat, it does exactly that.

Nice, thanks.

"[TODO: Too tired to complete the docs. If you feel like contributing, please take a look at the routers and send a pull-request.]"

I approve of this kind of API documentation.

Out of curiosity, why did you choose Ember? For context, my team is evaluating Angular vs. Ember. Thanks.

At first, just to learn Ember. For complex layouts I believe Ember works better. You could use Angular too, but I think you'll need UIRouter or something else along with it.

This is cool, and as a heavy IRC user, I'm eager to find a solution that can replace self-hosted IRSSI+ZNC entirely, without compromising security. Don't reinvent the protocol, reinvent the UI.

Why irssi+znc? Why not just run irssi on the box you run znc on (inside screen or tmux)?

Because with ZNC it's possible to connect from multiple clients, get the full message backlog on every device, push notifications, iOS/Android apps. You could use an ssh client on your phone and reattach to the screen/tmux session but it's just not that comfortable.

I haven't seen anything that beats IRCCloud in the ease of use and UI departments, especially their mobile apps.

That said, the full service is $5/month and so not for everybody. Also, you mention security and I'm not sure whether you'd consider a cloud service permissible in that sense or not.

Is there any documentation on installing this locally (without Heroku)?

Yes. You can install locally by following this doc page - https://github.com/HashNuke/mogo-chat/blob/master/docs/insta.... If you have any questions feel free to send me an email.

I know the advantage here is the open source availability, but ever since my team joined Slack for dev team chat, we haven't looked back. So many integrations. Such awesome.

I have a test account on Slack, I really like it....but like so many Saas-only products, we'll never be able to use it here at work behind our firewall, with our protected source code and JIRA databases....

If you're interested in this, you might also check out https://echoplex.us

That's a lot of AJAX requests. Why not use WebSockets?

I'll just stick with IRC, thanks

someone already changed the demo account password

Perhaps. Although I just tried a fresh install on my own Heroku instance, and the default password is not working there either.

Works fine from here. I just tested by deploying an app.

Make sure the last command is run when you copy-paste the commands. That is what creates the admin user and the sample room. admin@example.com and password is "password".

Also, I've now disabled editing the account details on the demo app (the password was being changed frequently). So it should be fine from now on.

I did follow all the instructions, and was told the admin user was created successfully, but it will not let me log in. The demo is working now though, so thanks for that :)

It would take 30 minutes to modify the Node.JS and Socket.IO examples into a usable, IRC-like chat server.

Every programmers underestimate complexity. Based on what you think it is easy. But when you look into more details, 30 minutes of work include code highlight, notification, responsive design, etc?

I think you're discounting the weeks of effort that went into writing the ember front-end, css, and the backend business logic for a full-fledged "Team Chat Application".