Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Exactly.

Personally, I recommend switching to Ripcord as a Slack client. That's what I did some time ago, and I couldn't be happier.

View on HN

Thank you! I didn't know about Ripcord, and so far it is great. I am amazed how fast it is. I'm also depressed that this amazes me, as it basically does what mIRC did for me over a decade ago.

This is developed in QT by one person, and it looks pretty feature-complete to me. I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.

> as it basically does what mIRC did for me over a decade ago

When Atlassian finally pulled Hipchat last year I was tasked with finding the replacement. Turns out the one that met everybody's needs best was a local IRCd and whatever desktop client for it people liked.

Some problems have been solved correctly for a while; chat is one of them.

I'm actually in the process of doing this right now. (Looking for a Slack replacement.)

Which specific daemon did you settle on?

I was about to ask the same. One of the things I badly needed was persistent logs. I googled around and found https://github.com/davisonio/awesome-irc which lists bouncers that serves the purpose.

Not really looking for replacement though (team is currently on Mattermost)

inspircd with a cron job to mail the logs daily to a pastebin for people who wanted to reference them later.

I am an old-time IRC user, but IRC is missing tons of features I use literally every single day in Slack. It does not have well-functioning and reliable file transfers. It does not keep history of discussions. It does not have media embedding.

It is very far from a solution in 2019.

If you have control of the entire IRC stack (the daemon, the bouncers, etc) you can work around a lot of those issues.. though at that rate, it's probably a lot less work to just host something like Riot..

How do you work around the lack of a kept history?

In our case, we didn't. Kept history wasn't a feature people used or wanted. Stuff you were going to refer back to later was for email.

As I said, I use this every single day of the week. Not having it means it is not even close to a solution.

Lack of history is a feature, not a bug. If you want persistent storage of decisions/etc there are better options out there.

Yes, like Slack.

Slack is more CYA than a store of knowledge. Yes, it's really great for pointing fingers: you can literally link to a specific message, saying "here, this dude made the call".

Again: I use it every single day. Not for "CYA". No need to be condescending.

Respectfully it seems like you may be condescending

It is definitely not a feature in most corporate environments.

Quassel, The Lounge, etc

Forcing each user to maintain an always-online machine is not really a good solution compared to just... having the history available to everyone, always.

You just run the bouncers on the same machine as the daemon.

This does not strike you as ridiculous, at all?

running 2 programs to provide another higher level interface? not really.

IRCd - real time, ram buffering of messages. Quassel - reads and stores buffers in a database, allows users to retrieve them.

If it's an internal chat system then the server admin just runs that second layer on top for those who want it, they're all multi user

> It does not have well-functioning and reliable file transfers.

If only there were some sort of Universal scheme for denoting the Location of a Resource. That would let you map a relatively short string to one of many possible file access services, and put that string in a text chat channel, rather than conflating two distinct problem domains.

Also every server I know and most clients do logging.

I am well aware of how to do this, yes. I do not find this a good solution.

So dial back the snark.

I concede the snark and withdraw it, but my point remains: one tool for one job. There are tools for sharing files, and URLs allow those files' locations to be shared over text channels. One tool for one job.

That is a tool that takes something like 10x the effort of having built-in file transfers. It is just not a good solution.

"It does not have well-functioning and reliable file transfers."

I've never had a problem with DCC transfers, but I suspect I'm in the minority.

"It does not keep history of discussions."

Actually, there were several servers which had "MsgServ" bot which would remember your last logout time, and could go back to retrieve all those messages from its logs and auto-relayed them to you, all you did was ask it to replay missed content from x channel and you got it.

"It does not have media embedding."

If you used pIRCh98 as your client you had live video capability and could easily do a quick desktop share through OBS or similar software, but that did rely upon everyone using pIRCh98.

Slack is basically a modernized version of a mix of the best features that IRC clients and daemons and bot creators had.

The only thing slack hasn't seemed to copy yet from all the old IRC stuff is the ability to use mIRC as a desktop file system browser (that was fun to see being coded.)

I'm curious, how does IRC handle history and multi-device sync?

How does IRC handle end-to-end encryption in groups?

How does IRC handle editing messages?

I asked users for a desired feature list, and none of those were mentioned.

That's kind of like saying nobody mentioned they wanted wheels for their car, so you got them cars without wheels. What's the problem?

> I'm curious, how does IRC handle history

Servers can re-send history when a client join. At least InspIRCd supports this (though it's not enabled by default.)

Quassel.

Blowfish normally.

Press up arrow, retype message, or type *correction.

Personally I dont need that stuff. Encryption maybe, but if we can run inside our VPN we should be good.

I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.

Several things I can think of: "quantity is not quality"; JS developers far outnumber everyone; making web apps look exactly the way they want is easy, and they are not interested in platform-native functionality, preferring a "consistent" UI across platforms instead; "premature optimisation" dogma that means no one cares about efficiency anymore.

Microsoft Teams and (later versions of --- they actually moved away from perfectly decent native Win32) Skype also use Electron, and that's Microsoft. That says the size of the company and its resources matters little in things like this.

> making web apps look exactly the way they want is easy

Its easy peasy with Qt as well. I am the only dev for https://www.sostronk.com/app and it looks (and behaves) _exactly_ as our designer wants it to. (Oh, and this is when I'm also spending time working on backend stories).

> no one cares about efficiency anymore.

That is not true. Discord and friends spend a lot of time for efficiency because they're using Electron. It is not impossible to have a (relatively) efficient application with Electron (VSCode for example), it just takes more effort. Compare that with Qt where performance is free of cost - in the last 5 years at SoStronk, I've hardly ever needed to spend dedicated effort for improving performance. Another example, and I wasn't aware of this till very recently, is the Telegram Desktop app which is Qt as well.

But yeah, I do agree with your first point, the only reason Electron is in use is because JS developers are a plenty. At the end, cost is the #1 thing when businesses make decisions.

But it's not clear that JS developers being plentiful actually reduces cost in the long (or even medium) term.

Ehhh for Skype it's mostly a Skype thing. Pretty much every decision made about Skype be it platform, features, ... Is wrong. I'm convinced Skype within Microsoft is now some middle step they put their product managers through for a year or two without paying much attention to them, and each tries to implement his "own mark" on it as some sort of achievement. The alternatives to that theory are too scary.

I mean yeah, s4b is getting EOL'd in 2021 in favor of Teams

Will we get a new SKU? Teams... FOR BUSINESS!

Wait, if Skype is Electron ... why can't I have Skype on Linux? Politics?

https://snapcraft.io/skype

I’ve been using Skype on Linux for years now. At least that we can thank Electron for.

Keep in mind that Ripcord only needs to implement support for whatever Slack has already decided to implement. They don't need to do the whole "iterative design" process (which Slack is doing for them), which is precisely the part where C++/Qt things tend to fare poorly.

That doesn't explain why Slack seemingly can't do it. They could literally hire the Ripcord author and pay him to continue development, and sell Ripcord as Slack Lite. It would be peanuts for them, and it would vastly improve their product offering.

But then it wouldn't be theirs, and that's clearly more important than success now.

Slack should stop iterating as each time they do it the product gets worse. They're not good at this.

> I really don't understand why a company the size of Slack invests all their development effort into such a subpar platform as Electron, when a native solution is clearly doable with very limited resources.

A lot of reasons... a solution 1) grows to match the size of its budget constraints 2) becomes more complicated the more people with long titles have a say in it 3) becomes more difficult to implement the more people that are working on it 4) becomes less useful the more people there are that can dictate what it does and how 5) fulfills more of the letter than the spirit of its requirements as more hierarchies of people manage it 6) becomes less user friendly as fewer typical users are involved with its development

Though the actual answer is "somebody with power just wanted electron for personal reasons and nobody had the power to turn the ship once it started on its course"

There's also wee-slack:

https://github.com/wee-slack/wee-slack

Just switched over to this. Thanks for posting.

Wee-slack was my go-to for the longest time but can no longer use it and it makes me sad... The problem with it now is that they had to migrate off the legacy API tokens. You now need an administrator to authorize wee-slack as an application for your organization. Not all organizations are willing to do this.

One benefit of being the admin... Fwiw I was worried about the port/move, but it works very well.

I seem to remember reports of people having their accounts suspended for using third-party clients (though I may be thinking of Discord accounts). Either way, I've used ripcord a bit and though it's not much to look at, it certainly gets the job done. I'm personally grateful for an alternative.

WRT. Ripcord, from what I've heard (I can't find the source now :/), it was Discord, the bans were due to a bug, and were promptly lifted after contact with support. But perhaps there were other bans I haven't heard of.

thanks, looks great!

Reply on news.ycombinator.com