Slack's company blog announces product features, such as threads and Enterprise Grid, and discusses security incidents and competition with Microsoft.
HN commenters link it for the Dear Microsoft letter, which they find ironic in hindsight, and for threading and security breach posts debated in product critiques.
I'm sorry if this sounds snarky but a lot of your criticisms of slack so far just don't seem rooted in anything resembling the recency of development within the platform.
https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd
Threaded conversations have been supported for a full year now, you have the ability to specify and narrow your searches down to specific rooms by using "in:#general" or by conversation by using "in:@dave", but a plain search will search as best the application can public rooms, private rooms and private messages, and the application does a great job I think telling you exactly where the search results come from, when they happened along with a contextual view of the conversation that happened before and after the search results-giving you the precise context of what was talked about, and allow you to both jump back in time to the moment the keyword appears, and jump back to "Now" very easily.
https://slackhq.com/next-level-searching-in-slack-1ce56aa8adee
Again, sorry if this sounds snarky, but I don't think your critiques are really lined up with how Slack has been developed in the last year. Many of your problems have been directly solved.
There is a cluster of related stories here. Many users seem to feel that the konklone.com post is the best representative of the set, so we changed to that from http://slackhq.com/post/103473448150/slacks-policy-update, and gave it a neutral title.
We're working on a system for grouping related stories together, but don't know yet when it will be ready. In the meantime, we merge threads manually, and you have to fish through the comments looking for context (like what the previous url was, why it was changed, and so on). That's not great, but see the first sentence of this paragraph.
There were a couple of borderline calls here: first, whether there are two significant stories that deserve to be on the front page, or just one (I'd argue just one, but it's not obvious); second, which of the two urls should be on the front page. Initially we chose the one that had been submitted earlier and had the larger discussion. Based on user feedback, we've flipped to the other.
I'm marking this subthread off-topic now, so it doesn't stay at the top and make the thread be about HN story merging policy.
> Didn't Slack rewrite their app to be native and move off of Electron?
What are you talking about? That has never happened.
They posted this blog post [1] on July 22, 2019 and you probably misunderstood their point.
They did not rewrite the application to build on native libraries, they simply redesigned the architecture of their UI logic to draw web components only when strictly necessary, sharing states between workspaces and stuff like that, but it is —as of today May 19, 2020— still 100% a web application running on top of Electron. They recently announced another visual rewrite [2] on March 18, 2020 which also resulted in the same web application running on top of Electron, no changes in that part whatsoever.
[1] https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4
[2] https://slackhq.com/simpler-more-organized-slack
Maybe this is more interesting than I initially thought. I was thinking this would just the encryption keys used to store the information for your whole organization Slack account. Instead, the keys seem to be much more granular, since you can revoke access to a single file, specific channel, workspace or organization level. [1]
I see one benefit of this being able to securely throw away data. Like if you are doing work for customer XYZ and chatting about it on the corresponding channel you can throw away the keys for the channel when the project ends.
Wonder how all this granularity works together with the search functionality. Or maybe they maintain per channel search index that can be covered by a separate key.
[1] https://slackhq.com/enterprise-key-management
Slack is an excellent product with a seemingly top-notch engineering team. But Slack has had multiple published security events the last couple of years. Including a DATABASE BREACH. E.g. someone either left a db open to the public, or didn't have ssh password auth disabled, or any number of no-brainer security practices.
Again, no hate for Slack -- growing as fast as they have is an incredible feat. But heavybit is, um, pushing the definition of "secure" with that title. LOL.
* https://slackhq.com/march-2015-security-incident-and-the-launch-of-two-factor-authentication-3cdcc8efba29
* https://www.wired.com/2017/03/hack-brief-slack-bug-everyones-worst-office-nightmare/
In case you hadn't seen yet, I suspect everybody at Slack in a position to comment on the company's behalf in pubilc is probably kinda busy with more pressing matters right now:
http://slackhq.com/post/114696167740/march-2015-security-incident-and-launch-of-2fa
(And I can't help but wonder if these two issues aren't connected somehow. Someone may have been sitting on a 0day trying to do the right thing in expectation of a bug bounty program reward, only to discover exploiting or selling it was the only avenue likely to actually pay out... Surely this isn't just coincidental timing?)