Live data from Hacker News

Open Sourcers Race to Build Better Versions of Slack

wired.com

181–190 of 397 posts

Re: Open Sourcers Race to Build Better Versions of Slack

#181

Earlier quoted context omitted.

What's wrong with that? VSCode is also such a thing, high performance and beautiful apps are obviously possible.

Apps built with front end web tech are nearly always heavier than their fully native counterparts, for one. It's nothing for an electron-based app to gobble up 150MB, 250MB, and higher amounts of memory while doing (in terms of resources actually required for the given task) nothing. A great comparison is Sublime Text, which takes up ~35MB of memory at cold start, even with a few plugins enabled. Compare this to VS C…

[deleted]

Re: Open Sourcers Race to Build Better Versions of Slack

#182

Earlier quoted context omitted.

What's wrong with that? VSCode is also such a thing, high performance and beautiful apps are obviously possible.

Apps built with front end web tech are nearly always heavier than their fully native counterparts, for one. It's nothing for an electron-based app to gobble up 150MB, 250MB, and higher amounts of memory while doing (in terms of resources actually required for the given task) nothing. A great comparison is Sublime Text, which takes up ~35MB of memory at cold start, even with a few plugins enabled. Compare this to VS C…

It's not just RAM, either. If you measure "energy usage" however your OS allows you to (powertop or OS X's Activity Monitor, etc), Electron-based apps are absolute battery killers.

You'll lose literally hours of battery life simply by running Atom instead of Sublime. It's absurd how little regard Electron devs are showing for end-user resources.

Re: Open Sourcers Race to Build Better Versions of Slack

#183
post #36

For talking about a race, Wired seems to have neglected a crucial technology: ircv3[1]. 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/

Hi, I wrote the Wired article in question. I hadn't heard about IRCv3, but it does sound like it would plug some of the holes in IRC that Slack users complain about. It wouldn't really have been a good fit for this article, since I was mostly focused on the two Slack-alikes with most traction, at least according to Black Duck's data (an imperfect measure to be sure) and IRCv3. As for why I didn't mention IRC in general, well, I alluded to it in the first sentence, but as many other people have mentioned, IRC just doesn't hold a lot of appeal in the business world, for various reasons.

Re: Open Sourcers Race to Build Better Versions of Slack

#186
post #2

If only there was a well supported, standard, open and interoperable text messaging protocol (with multiple implementations) that companies could host themselves... Oh wait, IRC.

Every time Slack is mentioned here someone brings this up. I can't help but think they've missed the point. User experience is important.

I think their point is that open standards are good for user experience. Can you imagine if each browser implemented their own hypertext format instead of html? Or Stylesheet language beside css? Or they used their own application protocol instead of http? Or if email wasn't federated; Can you imagine not being able to send emails between networks, so nodamage@gmail.com couldn't email smadge@myuniversity.edu? No matter how good the user experience of these nonstandard protocols and formats were, the user would suffer.

Re: Open Sourcers Race to Build Better Versions of Slack

#187
post #123

Earlier quoted context omitted.

Aren't most of those application bugs? For example, I don't see why the check boxes should be clipped in any web application, since in their default configuration (no CSS), they aren't. So the Hipchat CSS borked the default widget.

Yes, the check boxes are a bug in HipChat. That's part of my point: I have literally never seen a native OS X application that couldn't lay out checkboxes properly. Working in html/electron opens you up to making these UI bugs a lot more easily than native development.

[deleted]

Re: Open Sourcers Race to Build Better Versions of Slack

#188
post #165
post #99

Earlier quoted context omitted.

> Some sort of open protocol. 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…

I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?

All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.

Re: Open Sourcers Race to Build Better Versions of Slack

#189

Earlier quoted context omitted.

Thank you! We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse. That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.

Reminds me of the story around AIM/MSN wars from back in the day. http://www.theverge.com/2014/4/21/5635488/msn-messenger-vs-a... https://nplusonemag.com/issue-19/essays/chat-wars/

Or how AOL's Oscar protocol got updated at one point to start requesting chunks of the AOL IM binary as authentication against open sources clients (because they couldn't distribute AOL's binary with their client).

Re: Open Sourcers Race to Build Better Versions of Slack

#190

Earlier quoted context omitted.

"Practical techniques for searches on encrypted data" (2000) http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf Highly-Scalable Searchable Symmetric Encryption with Support for Boolean Queries (2013) http://eprint.iacr.org/2013/169

Homomorphic encryption would be great, is it likely to become practically usable soon? That is, is it safe enough against attackers, while allowing useful search?

Homomorphic encryption is about doing computation on encrypted data, but you don't need it just to search. All you need is some way to get the server to send you the encrypted blocks which contain the messages you want (and which you can decrypt); you don't need the server doing computation on the encrypted data itself.

A simple solution: divide the data into N blocks. Create an index that maps words to blocks (e.g. word "hello" is on blocks 36, 43, 84). Then encrypt the blocks and the index and upload them to the server. When you want to search, you just download the index, decrypt it, then use it to identify the blocks you need to download from the server.

The first paper I linked has some more advanced techniques of the same sort.

Post reply on HN