I'm very disappointed to see that Slack has decided to go the way of every other messaging service and move away from decentralized and standardized protocols towards those that are walled and proprietary. > We are focused on making Slack accessible to all people. Over the past year, we've made great progress in improving both the keyboard and screen reading experiences in Slack. We know many users have been relying…
> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team.
You're joking, right?
Have you not noticed any of the pain that anybody trying to make cross-platform app goes through, and hence the huge popularity of cross-platform frameworks?
There are open protocols like Matrix which are superior to Slack in that they are decentralised, have support for full e2e encryption, entirely self-hostable, don't store your data outside of the home-servers used for communication, etc. Riot is a perfectly fine client (looks just like every other chat application), and there are weechat plugins as well as native applications as well. Open protocols exist, and people…
I really wanted to like Matrix but it expects you to independently verify the keys for each device every person is using. If they get a new device, new keys to verify. This is crazy. The keys should be per person, not per device.
Matrix has an identity key that is shared between devices (hence why you can link up the sub-devices). The reason for having per-device keys used for e2ee that you can verify is so that you don't automatically trust new devices if a users' account is compromised. Each new login creates new e2e keys that only persist with the session. In terms of UX this system is currently pretty ugly, but the actual concept makes sense. If you want to just trust that the other users' account hasn't been compromised (which is what having a system designed around a single per-user key would effectively mean) then you can just blindly accept all keys, because each device key is first registered with the identity service and signed (requiring access to the account's identity key).
To be clear, there are several hiccups with e2e at the moment, but they are being worked on (from what I can tell).
I'm very disappointed to see that Slack has decided to go the way of every other messaging service and move away from decentralized and standardized protocols towards those that are walled and proprietary. > We are focused on making Slack accessible to all people. Over the past year, we've made great progress in improving both the keyboard and screen reading experiences in Slack. We know many users have been relying…
> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team. You're joking, right? Have you not noticed any of the pain that anybody trying to make cross-platform app goes through, and hence the huge popularity of cross-platform frameworks?
Just use Qt. It's harder, but not dramatically harder, than a web-based implementation.
I run Slack in a browser tab . Their native apps are basically electron tabs. I wonder how many people used xmpp and irc gateways in relation to all of their active users ?
They're not basically electron apps. they _are_ electron apps. And it's completely absurd that mine is currently using 1514MB of memory. If I weren't required to use Slack on a day-to-day basis, I absolutely wouldn't solely on principle.
Indeed, the Windows app is horrid. One of our older workstations is a quad core i5 with 8GB, nothing special but no slouch either, and the Slack app completely chokes that machine. The employee has to run Slack on her iPhone to be able to get regular work done throughout the day. On our newer workstations it's not quite as bad but it's still noticeable. Our oldest in-service machine is a Core i7 laptop I use when I'm out in the warehouse; that one also chokes heavily with Slack.
It's still 100% an improvement over what we used for chat before (Skype), but I'd be much happier running IRC or XMPP hosted on one of our servers. The boss decided on Slack instead as it's less maintenance on my part. I don't mind the extra work involved with running something we control, but the company wants me on other projects.
> Here's a thought: how about you write a native app for each platform? I can guarantee that the hundreds, if not thousands, of engineers working on AppKit and Windows APIs are a lot better at getting this to work than your team. Not just that, but it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days. So yeah, I…
> it took them months to implement some (mind you, still not all) features that are useful for blind users that someone already did in a userscript in a few days A userscript hammered out in a few days is not really that comparable to incorporating accessibility in a flexible and sound way across a codebase. Where one is dependent on the current representation and types of features in the app, the other touches prett…
assuming this claim is valid, that it took "few days" to implement what took them "months", then they could rewrite the entire user script from scratch every time a change is made, and this could be repeated dozens of times, which, assuming major UI changes are made once every few months, would take several years.
Mattermost has bridges[1]. There's also Matrix[2] which is decentralised and has bridges for almost everything. [1]: https://github.com/42wim/matterbridge [2]: https://matrix.org/
Have you tried running this stuff? Have you tried running your own home server and then bridging your irc network to it? It's not simple.
I have run my own homeserver, you're right it's not simple. However, the main Matrix homeserver has those bridges set up (so if you don't mind using it, you can). But in the context of a corporate environemnt, you have people who are paid to maintain services like this.
Mmm, while this wouldn't have impacted my decision in the slightest, I am mostly glad that I have moved over to Discord for everything I used to do in Slack.
Pretty easy, I reckon. I started writing a native Mac client using the API, and it was pretty straightforward. I don’t see there being a huge barrier to implementing a gateway.
I've been starting to toy around with it and Qt for a quick and dirty native app. Nothing worth sharing yet. What route did you go?
Just a plain Cocoa app using Swift. Similarly nothing worth sharing, but the API is straightforward enough and I wanted to brush up on my Swift, so it was a worthwhile experiment.
I think this just proves slack can no longer do what it was originally made for sending/receiving messages to boost productivity. Their are a ton of articles posted on hackernews discussing how slack turns a productive person into a slave of answering questions on slack. Slack is a distraction now, a glorified way to show your boss and others you are doing stuff while achieving nothing. Them removing these protocols isn't about forcing people to use their closed source protocol or shitty gui web technology. It is about taking a techie and forcing him to interact with the reset of the team like a good little sheep. Now he can't ignore the pings from pm and channels. Now he can't ignore the voice/video calls that someone demands of him/her sucking up more of his day with useless trash. All I hear in my head while I read this was either be a sheep like the rest or else.