Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

getmogochat.com

Post reply on HN
Print view View original

41–50 of 71 posts

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

#41

Post by untog »

voicereasonish wrote: post #29
gildas wrote: post #27

Earlier quoted context omitted.

> 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 conceiv…

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.

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

#42

Post by SingAlong »

ef4 wrote: post #15

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.

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

#44

Post by opendais »

hunvreus wrote: post #40
opendais wrote: post #34

Earlier quoted context omitted.

...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…

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: ema…

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

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

#45

Post by untog »

SingAlong wrote: post #39
psycr wrote: post #25

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/... Eith…

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…

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.

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

#46

Post by hunvreus »

opendais wrote: post #44
hunvreus wrote: post #40

Earlier quoted context omitted.

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: ema…

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...

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

#47

Post by ef4 »

SingAlong wrote: post #42
ef4 wrote: post #15

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.

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

#49

Post by opendais »

hunvreus wrote: post #46
opendais wrote: post #44

Earlier quoted context omitted.

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 st…

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.

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

#50

Post by SingAlong »

untog wrote: post #45
SingAlong wrote: post #39

Earlier quoted context omitted.

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…

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.

Post reply on HN