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…
Open Sourcers Race to Build Better Versions of Slack
181–190 of 397 posts
Re: Open Sourcers Race to Build Better Versions of Slack
#182Earlier 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…
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
#183For 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/
Re: Open Sourcers Race to Build Better Versions of Slack
#184Re: Open Sourcers Race to Build Better Versions of Slack
#185Re: Open Sourcers Race to Build Better Versions of Slack
#186If 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.
Re: Open Sourcers Race to Build Better Versions of Slack
#187Earlier 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.
Re: Open Sourcers Race to Build Better Versions of Slack
#188Earlier 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"?
Re: Open Sourcers Race to Build Better Versions of Slack
#189Earlier 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/
Re: Open Sourcers Race to Build Better Versions of Slack
#190Earlier 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?
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.