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.
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/.
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; 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.
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.
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.
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.
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?
* 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.
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.
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.
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.
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.
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 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....
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 :)
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".
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.