With ZenHub, we worked with them even closer because we saw that our users were happier using GitHub + ZenHub. We made it super clear that UI changes would likely break their app but that would be a risk for them to evaluate. In the end, it worked out well since ZenHub invested alot in their UI and became a long term partner of GitHub's.
From a technical level, I'd also take issue with this. You're customizing the output of their services once it's in the browser at the request of the user. If you're still interacting with Slack through the API and being a good platform partner (i.e. respecting rate limits), then I think you should be allowed to keep on. Disclaimer: I'm running a company on the Slack platform 
I’d love to avoid reverse engineering their minified code and use well documented APIs. Unfortunately, that’s not possible nor planned (as they told me on a tweet I linked on the post).
I was talking a while back with some Mozilla people about the move from their legacy API  to WebExtensions . It was a giant pain, but their old API exposed way too much surface area in ways that were too closely tied to the original implementation. The way I heard there were significant ongoing costs in trying to maintain the old API and support popular extensions while trying to improve the underlying tech and the user experience. So I get why Slack is very reluctant to expose API surface area, especially for the UI.
Just as the new WebExtensions API does. And as any hypothetical Slack API should.
I realize they are saying something about privacy, so it may be their position to argue against every system that does what your's does...
GH projects also has this arbitrary distinction between notes and issues, and notes are more or less useless yet the default when adding new items to the board.
Sherlocking is a well-known risk every tenant application must consider if they want to make a business out of it.
I would hope and expect that the ZenHub folks always understood github could just integrate the features directly, and not necessarily by buying zenhub.
This is no different than any user writing a Tampermonkey script to modify any website they want to modify. Even further, this is no different than a user opening the Dev Tools console and modifying things there.
Will you cover his legal costs for choosing this decision? Right matters less than resources if it's expensive to even be right. You can state your case here on HN without repercussion, not so when being sued (it costs to even state your case reasonably due to hazards of self-defense and it costs dearly if you lose).
And if I choose to run my own code in my browser why not?? Who's computer is it, after all?
In your moralistic mind or in the courts? Because idealists are not immune to laws they don't like any more than the rest of us. This arm chair idealism is getting ridiculous.
In the 90s the music industry tried to claim that the buffering data while playing music was making a copy of their data for which they should be paid or which they did not authorize. A few technically ignorant judges initially sided with this argument but it was eventually laughed away.
Your calling this "armchair idealism" makes me think you might be suffering from a legal system Stockholm syndrome.
>Please respond to this message to acknowledge that you have received it. If you can resolve the matters specified above in the next seven days, that would be excellent. If you anticipate that it will take longer, please let us know. I’ve cc’d our Legal alias so that in the event that I am unable to respond, one of our product counsels will be able to provide any necessary assistance.
tl;dr: respond and desist or they will escalate to the next step. Legal action is heavily implied, and it's outright foolish for you to read that and somehow think there's no threat to sue, whether implicit or not
Maybe it's foolish, maybe it's not, but this email cost Slack the salary of the person for the time it took him/her to write it. At least make them also pay for an hour or two of legal fees to have this taken down.
As a slightly bad analogy imagine a disclaimer that customers of a fairground ride might experience back pain. If it was found that all previous customers had suffered back pain then the disclaimer would not be enforceable and the ride owners could be sued for negligence.
And tbh, Axel Springer isn't the most surprising entity to sue for this, the entire publication house is a bunch of asshats, who have been cited for being the most deplorable journalists and in one case someone argued that one should be as mean and rude as legally possible to employees of Axel Springer.
They have also succesfully sued the producer of an Anti-Anti-Adblocker since their Anti-Adblocker was considered DRM by the court (IIRC).
There are a bunch of folks doing this already for ad blockers.
It does work on Firefox for Android, if you enable Request Desktop Site. It's not optimized for small screens, though.
It does work with Firefox on Android (not Firefox Focus), if you check 'desktop mode'. Weird that you should have to fake the user-agent string to access it.
I find it hard to believe they would redirect you to a pirate site. Are you sure it was a pirate site and not just a third party site hosting apks
It seems anyone who tries gets such a backlash and end up losing more than what they gain, plus they expose themselves to have false positives (e.g. one image didn't load due connection issues but slack falsely assumed it was an extension blocking it)
We use slack and I still have to use 4+ other forms of communication at work daily (jira, confluence, outlook, github). Sometimes we use video chat services and conference calls as well. There are days where very little happens via slack, and I'm becoming increasingly convinced that anything beyond pinging for simple things (hey look at this jira ticket, have you done this?) is wasted effort.
Blocking ads is not quite the same thing as modifying a product - but I don’t see any obvious reason why an EULA which forbids ad-blocking wouldn’t be enforceable. Though it would be deeply unpopular.
Their product are the bits they ship to you and the code they run on their servers.
You're modifying a part of their product.
Since you can't modify their product, you also obviously shouldn't be able to use any web browser to view slack because those browsers take those bytes they ship you and interpret them in the context of the browser windowing system (its userChrome.css for example)... that's also clearly modifying the experience they delivered to you.
You also shouldn't be able to use a computer monitor that has color settings different from the web designers working at slack. If you accidentally have a monitor with slightly less blue than theirs, well, you just modified the slack UI to be a little less blue. Obviously a ToS violation and you shouldn't use them at all.
God forbid if you zoom in on the page to modify their product's resolution/size.
I was going to comment something similar, but in trying to come up with details and examples to explain my point, I realized I couldn't, I so I decided they aren't really different with respect to modifying a product. What makes them different is how the product was modified, but that presupposes modifying the product and that's not really the way the question has been posed.
Blocking ads is removing the revenue mechanism, and is akin to patching out account verification for a desktop product (assuming the webapp/webpage has some AUP stating that the ads are required to be viewed as part of the service).
Modifying a program takes many forms, from removing authentication mechanisms to fixing bugs or adding enhancements, so while the legal system may or may not acknowledge those differences, it's at best an overly broad description of the case in question.
But then the next logical step is to argue that he’s inducing a breach of contract by his users, which seems to be the case.
Inducing a breach of contract is a tort . It does not apply in all cases where someone is induced to break a contract but in this case where the extension author has knowledge of the Slack terms of service and the extension targets Slack only, it almost certainly does apply. This argument was used in the case of Blizzard vs Bossland .
There's far more of a financial incentive there.
Adblockers inject code into sites. So do password keepers. If sites could sue adblockers because it breaks their terms of service, don't you think they would?
You are not bound by the slack terms of service except in the scope of your slack account or an API connection of some type.
Someone else can use my software all day long to break their terms of service, but that doesn't make me liable. I didn't agree to anything.
People need to realize that terms of service are a civil contract. It's not "illegal" to break them. Especially if you didn't agree to the terms.
Being "right", sometimes, is not worth the fight.
Maybe the agreement isn't binding depending on his local jurisdiction, but it's unclear how he could use Slack without agreeing (or at least clicking "agree") to the terms.
It does not matter, he does not want to fight this.
That's only in the US as far as I know, everywhere else you can't be bound by an agreement without signing anything.
Regardless of where you are, the majority of the agreements you enter into are not only not signed, they are not even explicit (but rather implied).
Case in point: practically everytime you buy something and pay with cash, you have entered into a purchase agreement without having signed anything.
Of course not. But in this specific case, it is safe to assume that he is using the product, or more specifically: he used Slack to develop BetterSlack.
So thats not true.
changing the name is not an issue... however, if I have to take it down, that's moot.
So lets see what they are 'forbidding' you: They don't want you to write code that makes browsers do other things to their site... How is that any of their business?
What if a new browser comes along that renders all of their fonts differently so that they become unreadable, is that any of their business or is it the business of the people who use that browser? I'd say the latter.
I agree that a disclaimer and a change of name should be enough. I'd suggest 'SlackingOff' as a name.
You are free to write any extension that does anything to any website as long as you aren't hurting users' human rights and as long as you aren't hacking them if you ask me. Users can decide whether they want to use your extension perfectly fine on their own.
Also note that you are free to not write any extension as well. It is your life of course :)
None of them involve talking with a lawyer in a different country over something that's really not that important in my life.
On principle, I want to side with all these other commenters. Fact of the matter is that time is precious. Glad you're doing what you feel is important to you.
When you delete a public repository, one of the existing public forks is chosen to be the new parent repository. All other repositories are forked off of this new parent and subsequent pull requests go to this new parent."
It seems unlikely to apply to a Chrome extension:
Craigslist Inc. v. 3Taps Inc., 942 F.Supp.2d 962 (N.D. Cal. 2013) was a Northern District of California Court case in which the court held that sending a cease-and-desist letter and enacting an IP address block is sufficient notice of online trespassing, which a plaintiff can use to claim a violation of the Computer Fraud and Abuse Act.
If you are in a different country than US I wouldn't worry at all. I would just avoid using the name "Slack".
But you're not the person being asked - the courts in g3rv4's jurisdiction and in Slack's are the ones who would be asked, if it came to it. Have you read the relevant law (including case law) about copyright and "cybercrime" in these jurisdictions and concluded that, in fact, Slack does not have the power to restrict this? Have you read the Slack user agreement and concluded that the provisions in that user agreement are unenforceable?
Is this your first week on the Internet? Of course he hasn't read any of those things! We're all arm chair lawyers here with our own personal, grumpy views about what shape society should be.
(I'm agreeing with you.)
I wanted to give you a moral boost, in case you were looking for a reason to take a stand. But if you don't want to, that's entirely valid.
It injects code into the dom model of the users browser.
But it doesn't inject code into their site, right? The HTTP request is made to the server all the same, nothing modified via the browser, it's all code additive/correction in the extension?
Don't be surprised about legal writing. He/She as a legal person is responsible for writing in a very clear and explicit way since any misunderstanding might cost the reader or themselves in the future. It just shows their accountability. You don't want a misunderstanding cost you trouble.
I have colleagues working in the legal department. They understand you, but they still have to make sure there is no misunderstanding there.
They are serving enterprise companies, Anything goes wrong can destroy their business. It makes sense for them not to risk anything.
Companies are paying them for the security. Otherwise, there are cheaper alternatives to Slack with somewhat similar features.
Slack could allow custom clients. But I'm pretty sure all major customers will require their employees not to use un-official clients for security reasons.
Ok, then he/she can be called out since we are on the front page of HN and there is a lot of noise and harm done.
I honestly can’t see a single reason why slack legal department, probably worth millions per year, in a company worth several billions, can write such things just to kill a free chrome extension built by a single person for non profit reasons.
I never used slack but from now on I will actively advice against using it.
When you arrive at the point that you can’t even modify your browser to see whatever you like I think that we are almost at the brink of total destruction/anarchy/“choose your not so preferred destination”.
Disclosure for slack layers: I never used your product, so I never agreed to your TOS and I would never use it hopefully.
I am not associated in any way with any of your competitors.
I sadly have to admit that sometimes I play with JSFiddle
in my browser just for fun.
If you want to sue me please go on, there is not much difference compared to what you are suing g3rv4 for.
And I don't. I mean, charitably this could be attributed to some non-tech person noticing the extension and sending/asking legal to send a C&D because they didn't like it. That's the only thing I can think of, because the alternative is plain malice. This is a client-side modification, the main part of their letter is just absurd, and the justification is nonsense.
If those enterprise customers are worried, they're free to lock down browser extensions on their employees' systems if they want. If they're worried about this, they should be just as worried about extensions acting on webmail, internal sites, etc.
are they going after all of them? if that's the case, I'd understand.
> Slack could allow custom clients. But I'm pretty sure all major customers will require their employees not to use un-official clients for security reasons.
Is security really a client side thing? Obviously I understand stuff like key logging and such in a malicious client, but how would somebody using a custom client affect another user's security with an official client? I mean if it would, wouldn't that be a horrible situation anyway from security point of view?
In that case, there would be no "contractual privity" between Slack and the dev, and Slack would have to go after him for inducing breach of contract or some such thing.
I think the real lesson is "don't take legal advice from internet forums of non-lawyers", or at least take it with a grain of salt. Not all analogies are equally good and only a qualified lawyer is gonna know which analogies will fly in court.
 Here's a fun analogy in a tort law case cited at https://cyber.harvard.edu/bridge/Analogy/analogy3.htm:
In Adams v. New Jersey Steamboat Co., a steamboat passenger sued the owner after the theft of valuables from the rented cabin; neither passenger nor owner had been negligent. The passenger claimed the owner nonetheless was strictly responsible, regardless of any failure or compliance with care, in light of prior case ruling that innkeepers were strictly liable for the theft of boarders' valuables. The owner argued against strict liability and pointed to precedents rejecting liability claims by passengers on open-berth sleeping trains. For purposes of liability for theft from a passenger, should the steamboat owner be viewed as more like the innkeeper or more like the train owner? The court reasoned that "A steamer carrying passengers upon the water, and furnishing them with rooms and entertainment, is, for all practical purposes, a floating inn, and hence the duties which the proprietors owe to the passengers in their charge ought to be the same." The court noted that both innkeepers and steamboat operators are entrusted with high levels of confidence in the face of temptations by many to endanger guests. Given this parallel relationship to guests, innkeepers and steamboat operators should bear the same kinds of duties to guests.
I can't even count the number of them I have received. They look scary but basically will not be followed up with. You might as well just respond with "fuck off"
These are power moves by Slack. They want to have greater control over the communication medium and presentation
If you thought they were ever going to support extensions of their IRC gateway for long, then you misunderstood their product and who their market was or rather who their market became
Same at my workplace. Slack is mostly used by the managers, all the devs avoid it. Even if you don't mind the proprietory protocol, the performance even on beefy machines is an absolute dumpster fire, that nobody wants to touch the app with a ten foot pole.
When Slack came up, some of our development teams picked up using it, because it was free and didn't have to be installed and because of "it was that hot new thing from Silicon Valley that all devs use now". Most people loved it. I've always been in the "we try to keep our other infrastructure mostly in-house for control/privacy/anti-lock-in reasons, so why add a dependency to an external service and push internal documents onto it while we don't even pay for that thing?" camp and therefore flat-out refused to use Slack until the issue of internal instant messaging got enough attention to be discussed on a company-wide level. It was agreed upon the need for such a service, but it was also recognized that the way in which Slack was used to serve that need was not sustainable and far from rational, so alternatives were discussed and we eventually settled on trying out Mattermost.
Within weeks, all teams using Slack had moved over to Mattermost, and even most of the people who never wanted to use Slack for various reasons, including me, were okay with giving Mattermost a try. Most kept using it, so it has become a widely accepted part of our internal infrastructure now.
- Why does it have list of users with their avatars and everytime new person comes in it has a huge, slow animation lol
- ads for other rooms and quarter of the screen is "best comments top list"
- the chat user avatars are unaligned, some are bigger, some smaller, some have usernames under avatare, some on the right.
I'm not sure if it's a late april fools joke or what's going on here.
Others mentioned Mattermost, Discord, but really, there are so many viable options out there. See this list of 25+ alternatives for example: https://fleep.io/blog/best-slack-alternatives/
From cloud-based to self-hosted, open-source and commercial... As long as they integrate with the tools devs use, there will be devs who use it.
Or are you referring to audio calls and video calls?
Main difference is cost. If you're already paying for Office 365 then paying for Slack Enterprise (or Plus, or whatever it's called these days) across a fast growing organisation of 170 people on top starts to look really hard to justify versus Teams. You can, of course, stick with the free version but this caused two problems for us:
- We ran out of integrations,
- We found losing message history more than a few days old was really starting to hurt us - you couldn't even go back and refer to a conversation you'd had last week.
Teams isn't perfect: it's purple theme is pretty gross (actually it has a couple of other themes, but they're both foul as well), it can be very slow/laggy, and it has a plethora of UX annoyances (like having poorly designed chat window layout and formatting that wastes loads of space) but we saved £20k/annum by switching over to it. And we now have conversation history and unlimited integrations.
Plus, I have to say, I do not approve of this move by Slack. They could have approached it much more positively by partnering with the author (as an example).
* You are in all channels, all the time.
* no threaded replies (most important)
* the notifications system is weird
* weak integration system (integrations cannot add widgets to chat)
Some more reasons that I forgot. But these ones most importantly.
While I haven't seen any legal threats, they tend to threaten end users with bans (due to breach of ToS) for using third party clients, client modifications (like BetterDiscord), and "self-bots".
Slack can shut off their web interface and rely on their own apps if they want to control that stuff.
From the people who had no problems naming their product identical to the colloquial name of the oldest maintained GNU/Linux distribution, thereby confusing the hell out of actual technical people for the longest time with press releases.
Also, Bob Dobbs called...
(Edit: you can take away my upticks, but you will never take away my slack. "Hacker" news my ass.)
I bet the Slack top brass just told legal to throw the book at the guy because of the name, and so they padded the letter with everything they could find, including weak technical arguments that they don't even enforce on others.
(I agree on the confusion with Slackware btw, it took me a while to realize they had no connection whatsover with Volkerding or the distro.)
Frankly the origin of Slack's name has nothing to do with Slackware Linux (or Linux in general) so I'm having difficulty following your grievance here.
Now if "Slack" means the pretty protocol-breaking irc-client to you, that's perfectly fine. But if some party starts threatening someone with 'That's not what "Slack" means! We're the authoritative source on the meaning of "Slack"', a hacker should resists. Slack is for everybody. Many may have forgotten, but it's not VC-money that makes the Internet go round, it's Slack.
To quote the prophet:
"If someone is making money off ``Slack'', it better be me."
"Those who cannot remember the past are doomed to trade their precious Slack for worthless trinkets."
"The Slack that can be described is not true Slack."
Okay but they didn't do that. Slack is concerned about someone using their name in relation to third party, unaffiliated software which is obviously related to their own software. Slack the messaging company doesn't care about the use of Slack outside of that niche.
If you wrote a browser extension called "BetterSlack" that emulated Slackware in your browser, Slack wouldn't care. If you wrote a browser extension called "DontSlackOff!" that automatically restricted the time you could procrastinate on Hacker News or reddit, Slack wouldn't care.
Slack cares about its brand, not being the canonical authority on an English word use of that word in products. The idea that Slack cares about uses of the word that don't have anything to do with its own software seems like a willful misinterpretation of the point. This is a pretty mundane legality and has nothing to do with hacker culture or "resisting" anything.
Except that these channels make it impossible to really interact with Slack, and they pulled the rug out from under the APIs that used to kinda make this possible (XMPP/IRC integration). If you're going to force people to use your client, then you should allow for users to customize how that client looks and feels. Even more so if you're doing a terrible job at that yourself.
Slack Team, just listen to the market (hint: HN score!) and bring such guys like OP into a gig to improve your stuff.
I felt it was better to unpublish my (likely to be unmaintained) fork. Probably should have left up a note to redirect folks.
you certainly have stronger feelings about it than I do :)
That, data mining, must be part of the business case. Especially the friend maps they can generate.
1. I don't want to get involved in that, even if I'm based in Uruguay and they'd have a hard time suing me.
2. What they could do is put resources to detect the extension and block it. We could start a mouse and cat game that they'd win... I don't have their resources to invest in it. After all, all I wanted was to solve Slack for me, and that would make it harder.
Well done on what you have achieved, keep fighting the good fight!
It sounds like the plugin author isn't located in the US, so this may be moot, but countries colonized or invaded by European countries or the US often have similar legal systems.
I doubt they'd win in a fair fight, but I also doubt the plugin author can afford to put up a fair fight.
The biggest thing is Terms, which will almost always exclude any tampering of any kind, client or server side. These agreements are usually upheld in the US. So that's hurdle #1.
The CFAA isn't really obviated by client-side modifications, because the CFAA allows essentially arbitrary definition of "unauthorized access" and "exceeding authorized access". If they tell you to cease and desist, most judges won't believe that you can reasonably claim that you didn't know your access was unauthorized. The CFAA makes unauthorized computer and network access illegal.
There's a third barrier here, which is copyright law. The "RAM Copy doctrine" is the dominant interpretation, and it states that even the temporary copies that exist within RAM are sufficiently tangible to qualify for copyright protection, meaning you either need a license from the rightsholder or you need to prove fair use just to load the content.
The only way I can see that that wouldn't affect client-side applications would be if they access everything through a proxy without ever actually loading the copyrighted content directly, i.e., by injecting and accessing the DOM through the browser. But you'd still have to convince the judge that the extension itself is not infringing on the work it alters, which seems unlikely -- it would likely be considered a derivative work.
Again, I'm not a lawyer. Maybe all this is wrong. You shouldn't rely on it. But the situation is not as dreamy as people think. BigCos keep this bully pulpit relatively quiet because it makes it easy for them to crush upstart competitors who may offer a "move your profile from $X" feature. With the data locked up, the users never move.
Honestly, if they do that they're idiots and, longer term, slack is a dying product: they'd be much, and I mean MUCH, better served by investing those resources in improving the product.
Congrats on your Stackoverflow job :)
You wouldn't happen to have any recommendations for hiring web-devs here in Uruguay for a small startup? It's CRAZY HARD.
I think it would be unlikely to have won, had the software been made to streamline the game or make it run faster.
There's some excellent analysis of this sort of case here https://ir.law.fsu.edu/cgi/viewcontent.cgi?article=1101&cont...
It makes no sense for them to claim that every extension published on the Chrome store needs to comply with their acceptable use policy...
If that were true, then wouldn't 1Password and any other extension that uses a content script also be considered unacceptable?
Furthermore, in a civil suit what needs to be demonstrated are actual damages to their business. (It’s not enough to just show that the ToS were violated). There’s no possibility of that for most browser extensions.
So this seems rather unfortunate now but the first thought I had on reading your initial post was "wow, I wish he'd come and do some similar stuff for riot, but unless slack shut him down there's no chance." However lo and behold here we are, so I thought I might as well reach out. If you haven't heard of it, Riot can be described as "an open source slack" although I think that's unfair on it, it certainly lacks certain features that slack has (although with its current rate of development this gap is shrinking) but also can do things slack just can't.
Full disclaimer I'm not a developer on riot (or matrix the open protocol it implements), just a happy user so I can't speak with true authority but I think they'd be happy for you to make these sorts of changes to riot.
So I invite you to come check it out, I hope you find it compelling. At the very least riot has a means of bridging to slack (along with irc, gitter and more) which you might find helpful in dealing with slack (I know I do).
Hope your future endeavors so smoother, I look forward to seeing whatever you create next.
that’s a dream come true!!! I’ll def check it out
A company making the case that their Terms of Service or definition of Acceptable Use applies to users manipulating the data that is sent once it is in the user's browser is a terrible way to go. We should always have the tools and the means to add features and change the display format of data being sent to us.
When you have Fortune 500 companies using you, you know you're not a startup or company for the common folk anymore. As for hostility towards developers, we only have to look at how well that worked out for Twitter when they turned up hositility to 11 towards their developers. Different situation, but same premise of cutting off developers making your product better.
As for Slack, I loved it in the early days. But now, I find is distracting. The numerous bots you can enable on it (most of which are counterproductive) are annoying or distracting (like the Gif bot). I dread opening up Slack because it's not a nicely designed product and it is starting to become dated.
We've been using Microsoft Teams where I work and I must say that it is amazing. You get so much out-of-the-box with it without needing to add in bots and it's more customisable.
You know how to predict if this will happen? It's pretty easy. It will if the company's product or service is proprietary and centralized. It's just a matter of time.
So can taking screenshots of messages. If injecting JS can possibly affect the security of your platform then that's a vulnerability you should fix, not send a C&D to some developer about.
If everyone gets used to installing 5 Chrome extensions from unknown developers adding little themes and tweaks to Slack, then some of those extensions are going to be malicious and a lot of people are going to have their accounts stolen. Third-party software should only request as much access as it needs, and Chrome extensions are just bad architecture for this sort of problem, since you can't say "this extension gets to make benign visual tweaks to the page but doesn't get to steal my Slack account". I haven't worked with Slack's API, but nearly every API like it provides granular access and certainly doesn't let you steal the user's account, and all actions are done via an API token that can be tracked and revoked by Slack if your app is malicious.
Any extension that asks for the permission to read data off webpages can read data off webpages, yes.
It's the user's responsibility to not install such an extension, not the company's responsibility to do whatever the hell they're doing here.
Anyways, this extension wasn't malicious. Its source code was available freely, and auditing it reveals nothing malicious.
It never was? The Android client takes 10 seconds to start, runs my device hot and the UI is so bad that the first time I tried to respond to a thread I couldn't figure out how to get out of the thread view.
The desktop client uses 1GB of memory gobbles my CPU and takes 20 seconds to start.
The "least bad client", the web client still takes 10 seconds to start, for no obvious reason. Last week I looked into it, it turns out that every time the client makes a request to the server it the TTFB is 300 to 500ms, on a connection with 40ms ping. So their backend is just as fucked as all their clients.
Even their email notifications don't work: every time I click on the link they send me it doesn't take me to the mention!!!
They did corner the market so clearly they must be doing something, but really I just can't see it. I'm completely stumped.
I've been wondering about this for a while now. Slack feels more like "just good enough" in terms of UX than anything special. It's just a chat application with terribly slow clients but somehow everyone is using it.
One of the reasons is the lack of competition, e.g., we use Microsoft Teams instead, but its also an electron app with the same problems (and takes ages to start).
I wonder about the rest of the competition, for a while everybody was using hipchat, I never used it myself, I wonder why nobody talks about it anymore.
But I agree. And even outside enterprise, their web client is the least bad option if you have to use Slack.
(I didn't catch the original mention of BetterSlack a few days ago, so ironically, your "Welp, gotta withdraw this!" message here is the first I've heard of it. This seems to be my usual timing with such things, though...)
As someone who messes with native apps: this really isn't true, at least in my experience. Native apps tend to follow platform paradigms, which usually make them reasonably well designed and structured–sometimes more so than web applications. Usually adding functionality is simply a matter of finding the class that manages the component, rather than digging thorough a bunch of broken CSS (for IE 6 support) and minified goop.
I haven't been messing much with Windows executables for quite a while, but back in the day, I'd "improve" many programs by just editing their resources.