I mean I wish we just stopped there, IRC, done, call it a day, never ever think about many to many written communication ever again. It works, scales, supported on all platform, text based, small memory/cpu footprint. Just like we stopped developing hammers a while ago. CS is the only field where 1.0 is never good enough. We keep "innovating" adding features that nobody needs and complicating things until it becomes this unmanagable mess. </rant>
As a big fan of IRC, I would have to say that it doesn't "work" at all when compared to Slack or Discord. You have to be online to receive messages, making it pretty much useless for any serious communication needs. Yes, I am aware of, and run, an IRC bouncer, this is not a real solution for 99% of users.
Except some people can be having a conversation while I'm offline. When I get back on, I can catch up or have someone link me to an important part of it. It's handy.
A feature to the small handful of people who still use IRC. Look around though. Everyone else expects basic features like being able to send someone a message even though that person went through a tunnel.
I work with a bunch of people in oakland, where comcast flickers on and off like a light bulb during a wind storm in the 1920's. So the only way to have a quick chat is over email?
IRC is not limited to plain text. Discord, Slack, and IRC all handle media the same way. Someone sends an URL and the client decides to how to handle displaying it. Textual shows me images and videos all the time from URLs sent.
I guess then technically IRC servers need a way to have images uploaded and re-serve them. When I share an image on slack I'm usually just uploading it directly to slack, rather than using imgur or another uploader.
I thought they stored the graphics on the server with Discord. I know there is that out-of-band file protocol that some IRC clients support, but it was always a terrible hack that hated firewalls.
That's not how I use the feature at all. The vast majority of images and files I send are created locally. I can then upload or paste then into the chat client, they get stored on the server and shown to the other users. With IRC, I would need to use a separate service like imgur to first upload the images. And or a file hosting service like Dropbox for the files.
A robust IRC client could include integrated image hosting. Or ask you to plug in your Dropbox account, and then upload there automatically when you drag and drop a file or image.
Unless things have changed since my IRC days, doesn't this a) require routed ports, so anything not a private controlled network is out, b) expose your IP address, which is a security risk, and c) is 1:1 only. It's also more of a side protocol than actually being part of IRC, right?
Whereas posting images directly into the chat window and having everyone see it is insanely useful.
It does not have full slack-like functionality. But it was never limited to just text. Some of the biggest communities on IRC revolve(d) around file sharing over DCC.
Anyway I think saying that it's "insanely" useful is a gross exaggeration. You know what is insanely useful though? Having open source clients and access to logs without paying $100 per year per user.
So, our small team is using google hangouts but that also supports image pasting (and is searchable, free).
Image pasting is for more than just memes. We can post screenshots of errors, or user data/visualisations, or sections of syntax-highlighted code. All of this is infinitely more agile than going through a bulky ticket system (which we also use once we’ve confirmed as bugs or decided how to use forwards). So no, it’s not an exaggeration at all.
IRC was fun in the 90s but seems to have stopped there? It was also never ~at all~ friendly for non-technical users, which is a complete non-starter nowadays.
The alternative to pasting images is making a ticket? I would have thought it would be uploading images to some image hosting site and then pasting a link.
Don't forget NickServ. It's a pretty massive user bottleneck. More than half of the people in my (tech) company would probably take more than 20 minutes to figure that out.
I used to spend a fair bit of time in a non-tech IRC (we've moved to Discord since) and the amount of intelligent people who simply could not get the hang of NickServ was astounding.
I've always wondered why IRC clients didn't add seamless integration with NickServs of large networks. Maybe this was one of the reasons why services like Slack or Discord are successful; these services are taking your hand and are guiding you through everything, while IRC expects the user to read RFC and diagnostic server output in order to figure what's going on. I don't think it has to be this way.
IRC as a protocol probably can be used to build a service as friendly as Slack. I.e. it's not a problem to add URL autoexpansion, like in this WeeChat plugin: https://github.com/antekone/youtube-autoexpand . Of course it's not easily possible or practical to show pictures inside of the terminal window, but I think it's entirely possible to create a new modern Slack-competitive IRC client over a pure IRC network. What could be done on IRC can be seen in an old Microsoft app, Microsoft Comic Chat: https://en.wikipedia.org/wiki/Microsoft_Comic_Chat .
(disclaimer: i prefer IRC to Slack/Discord but I get why for many people IRC is a bad idea)
NickServ always felt like a terrible hack to me. It doesn't help that some major servers have incredibly stingy limits on NickServ too. I've had usernames age out after only a week, and the registration process is fairly cumbersome. Plus it involves sending a password in plaintext over the network, which never felt good.
Kind of a toothless "many" when this isn't even built into Freenode. I have to wonder if any IRC server I've ever connected to supported it and why I've never seen this feature.
-MemoServ(MemoServ@services.)- ***** MemoServ Help *****
-MemoServ(MemoServ@services.)- MemoServ allows users to send memos to registered users.
-MemoServ(MemoServ@services.)-
-MemoServ(MemoServ@services.)- For more information on a command, type:
-MemoServ(MemoServ@services.)- /msg MemoServ help <command>
-MemoServ(MemoServ@services.)-
-MemoServ(MemoServ@services.)- The following commands are available:
-MemoServ(MemoServ@services.)- DEL Alias for DELETE
-MemoServ(MemoServ@services.)- DELETE Deletes memos.
-MemoServ(MemoServ@services.)- FORWARD Forwards a memo.
-MemoServ(MemoServ@services.)- HELP Displays contextual help information.
-MemoServ(MemoServ@services.)- IGNORE Ignores memos.
-MemoServ(MemoServ@services.)- LIST Lists all of your memos.
-MemoServ(MemoServ@services.)- READ Reads a memo.
-MemoServ(MemoServ@services.)- SEND Sends a memo to a user.
-MemoServ(MemoServ@services.)- SENDOPS Sends a memo to all ops on a channel.
-MemoServ(MemoServ@services.)- ***** End of Help *****
But I do notice and on my machine I prefer lightweight apps, so I can make the most of my existing resources instead of wasting them on a chat application.
I notice how long it takes to start up the app, I notice how hard my CPU fan runs when Slack inexplicably decides to max out a whole core for a few minutes, I notice the data hit if I have to download a new version while on the road. It's definitely bloatware.
I actually ran into that today and restarting the app fixed it. That shows that there's a pretty serious limitation if such a high profile app has these sorts of problems.
Emphasis on "modern" --- I distinctly remember using some web chat clients with IE6 in the early 2000s, and they didn't need hundreds of megabytes of RAM (average PCs had a total of between 64 and 256MB of RAM) and the whole (single-core at the time) CPU to do what today's web apps do.
For anyone who knows what I mean, it might be interesting to write such a "lightweight" web client for e.g. Slack, restricting yourself to whatever JS abilities were available in 2000 or so, yet imitate as much of the features and appearance of the web client today as possible. Chances are it will still work with "modern" browsers too, and use a tiny fraction of the resources of the current one. All the better if it gets noticed and DMCA'd.
Oh please. I'm not about to start referring to a specific toolkit as "modern technology” at the expense of everyone else, particularly a step backwards
I don't actually use any of these services so I had no need to, but just being curious, I downloaded the Windows client; and while it may be smaller than Electron apps and native, it's still quite large for a native app --- over 30MB, and also 64-bit only (why? Do you expect to need more than 4GB of RAM for this?)
To contrast, MSN Messenger 4.7, an app with similar capabilities (IM, voice, and video calling), is only ~2MB --- with several third-party reimplementations being <1MB. Makes you wonder how small you can make an app for today's messaging services if you really tried... they don't need to be that big even if they don't include an entire web browser.
A 32-bit binary will work just fine on a 64-bit OS, but not the other way around, and there's no reason such an app needs 64-bit, so why unnecessarily restrict compatibility?
I think you're in a minority. Are there any 32-bit CPUs being produced for the mass market these days? Making a 64-bit only software is not only about wanting more than 4gb of ram; it's about debugging support, tooling, installation size and installation packages, etc. It's easier to distribute 64-bit only software than both 32-bit and 64-bit, and you can't distribute 32-bit only software because:
1. macOS will deprecate 32-bit completely soon,
2. Linux needs 32-bit libs installed on the system, and many people don't have them,
3. Windows has really good backward compatibility and still supports 32-bit. But it's the only system.
So, distributing a 64-bit-only software actually makes sense.
When I install something, if it pulls in a ton of stuff, I'll reevaluate whether I actually need it. In fact, I was pretty excited when I finally got rid of my dependency on 32-bit stuff and could eliminate the 32-bit repo.
I like 64-bit because it keeps my system clean, but because it's "better". I definitely want a 64-bit OS so some things can use more than 4GB RAM, so why have two copies of everything? Just standardize on the thing nearly everyone uses: 64-bit.
Are there any 32-bit CPUs being produced for the mass market these days?
Can we stop assuming that people are always going to have the latest hardware? Even then, 32-bit SoCs running Linux are still pretty common in various embedded things and other low-power devices --- exactly the use-case for a small and native chat client.
Not exactly true for Linux - a modern Linux desktop usually has only the most basic (libc, ...?) 32 bit libraries installed. Though an AppImage (which Ripcord uses) might work because it's mostly self-contained anyway. On Linux, approximately nobody still uses 32 bit systems.
When can I finally get rid of this stupid "Program Files (x86)" folder which annoys me every time I click into the wrong one looking for my program, when even new programs are released as 32-bit?
It's not native (as in native windowing toolkit), it's Qt based which is probably where most of that 30MB is going, MSN Messenger is/was built on win32. Still, in the age of electron apps that's a huge improvement, it's good to see real desktop developers still exist.
Its not like 32 bit applications are more efficient than 64 bit applications.
There is place for 32 bit applications but not here! The job of a program is to do what it is supposed to do efficiently and get out of the way, and it better use all registers and instructions needed to do it.
Its not like 32 bit applications are more efficient than 64 bit applications.
Yeah it is. You need to move 7 bits through memory and through the CPU, is it more efficient to pad it with 25 blank bits and move 32 bits overall, or pad with 57 blank bits and move 64 bits overall?
Which is doing things "more efficiently" and "better using" the hardware?
your cpus arent capable of 32 bit calculations anymore... so the questions is: is the software emulation of your OS for 32 bit more efficient than the programming language overprovisions.
The CPU is still perfectly capable of 32bit calculations. Even 8 bit calculations. What you can't do is use 32bit pointers (though, strictly, you can, but x86-32 isn't well supported, I wonder why?)
It's not -entirely- true but it's not false, either as far as I'm aware.
Windows in specific uses WOW64 -- Windows 32 on Windows 64. It's an emulation layer that doesn't actually hamper performance but does do things a bit differently than a native OS -- such as running all 32bit programs in 'user mode' rathe than with elevated permissions.
If you use eax instead of rax, you can do both. Compilers are smart these days and will use the appropriate register size when necessary. If you need to move 7 bits, it'll likely use the al register.
I can't edit, but it seems my reasons for thinking 32-bit can be faster aren't entirely daft - but the gains of 64-bit x64 include it having simply more registers, having smaller faster floating point precision, being able to request more memory at once, and the hits to pointer size overheads or processor cache holding less real data are rare and mostly from buggy or odd conditions, and that for a lot of normal programs there'll be no difference either way:
Most of the stuff is taken from the fact that Ripcord is multiplatform. It uses Qt5, it takes lots of space, but works everywhere. Ripcord also bundles lots of libraries for lots of file formats (audio, video), bundles OpenSSL for cryptography support (although the library is from 2014, and probably should be updated), should theoretically support Wayland (at least it has some libs for supporting it), etc.
MSN Messenger probably uses WinAPI and being a Windows-only program it can get away with it.
I like that "Not made from a web browser" is a headlining feature. My laptop has 16 GB of RAM, and still doesn't have enough memory to run all the Electron apps I use without grinding to a halt.
I think this meme needs to die. I run 3 massive electron apps on the regular, in addition to my multiple IntelliJ IDE instsances and RDBMS clients on a 16gb Macbook Pro, the latter category being the biggest resource hogs.
When we pay less than $10/gb for ram and our systems have 32 gb and more, I do consider it acceptable. As long as the speed of development and feature implementation is sufficiently improved of course.
My system doesn't have 32GB RAM, and I really don't want that because my users don't have 32GB of RAM, they have 4GB. I don't want to get in the habit of just throwing away RAM because some target devices may have much less available, and I may want to port to such limited devices (phones, Raspberry Pi, small VPS instances, etc) where RAM is hard to come by or expensive.
An app's resource use should just justified by what the app does. It's really telling when a 3D game engine uses about the same resources as an electron app.
Who is our? Most systems do not have 32gb of RAM. My grandma isn't going to be writing emails on a MBP with maxed out specs, neither will a majority of people have more than 4 or 8GB of RAM.
Is all 800mb resident, and just for that app? On osx people often just look a the 'Memory' column in activity monitor, which says slack + the slack helpers are using 1.4GB of memory (OMG Electron sucks!) - but it is using 633MB of real memory. So not great if you are used to bitchx or something. But not terrible - half of what it initially looks like. Memory management is complicated.
IntelliJ has much more functionality than Slack so it's a poor choice to compare it to. Also... comparing slow cross platform tool to another sluggish cross platform tool isn't really a great place to start.
The fact that this Rip Cord does 99% of what Slack does and uses a fraction of the memory and runs faster pretty much says it all. Javascript/ Electron are resource hogs.
Largely depends on how quickly Slack/ Discord move their APIs and how aggressively those platforms block this kind of app. This has little to do with app performance though. Slack is a sluggish pig because the way it's written, not because of it's feature-set
It makes me sad that people continue to put their time and effort into supporting these closed communication systems. If anyone else is considering making something like this, please base your efforts on Matrix. It's so much better for us and so much more deserving of our attention.
> To be fair, for an internal communications usecase you just need to convince your company, not half the world
I imagine that's true for companies whose users stick to internal workspaces, but often the most active/vocal users (1) participate in multiple (often professional) non-company workspaces, and (2) don't want to run Yet Another Chat client.
That's less of a problem with Matrix. I set up a WhatsApp bridge because all my friends are on WhatsApp, and now I can use any matrix client, even a very lightweight CLI one, to talk with them.
YES! This is awesome. Have it up and running with Slack.
I checked for:
* Thread support (yes)
* Drag n drop images (yes)
* SSO support (yes)
* Quick Switcher (yes)
* Default dark mode (yes (!!))
There are some things missing, like search, fine grained notification controls for muting, profile editing, code snippets, moving emojis, etc. But for daily communication, I'll give it a try. Feels fast and light.
Edit: After some time, I think I will keep it around for when I am on the go and want to preserve battery. I do not think I'll use it full time because I miss some of the colourful whimsy of the Slack client.
Looks like a good project, I may give it a try on Windows.
On Linux, I use weechat to connect to a local bitlbee for Discord and Hangouts. When I was using Slack I used wee-slack [0] with success, but it looks like bitlbee has a plugin for Slack, too [1]. This lacks a few of the features of Ripcord (e.g. voip, graphical emoji, emoji completion), but it works.
This one is different in that is says that they will one day charge for it so instead of just shutting it down the author will have a lawsuit on his lap.
Are there examples where an alternative client was successfully sued? Seems like it would be like suing Firefox because you want your users to use the browser you provided.
I would think that worst case, slack could kick users off for breaking their terms of service (assuming there is a clause for that). But a random software maker is not subject to slack's terms.
Not exactly an alternative client scenario, but Blizzard successfully shutdown a US company that developed and sold World of Warcraft botting software.
The gist of Blizzard’s argument was that the software was designed for the sole purpose of facilitating customer violations of their EULA causing monetary harm to Blizzard.
Disclaimer: I used to be a customer service representative of Blizzard Europe, but not since 2012.
Unfortunately, there isn't a chance this survives, especially if it's closed-source and for money. Discord doesn't allow third-party clients (which I swear should be a legal issue since it's a PUBLIC API but whatever), and Discord is known to aggressively block and prevent third-party clients.
If you want something that doesn't suck, look somewhere other than Discord. It sucks that it's so embedded into so many groups but Discord isn't a very friendly entity.
I'm not very familiar with Discord, but I thought the same about Slack. Slack has been aggressive in the past sending C&D letters to those who threaten their walled garden. I'm not saying it'll definitely happen in this case and I wish all the best to the developers and users of Ripcord. I sympathize with their want for non-electron desktop clients. But I wouldn't be surprised at all if they received a terse and disapproving letter from Slack's legal team.
> Slack has been aggressive in the past sending C&D letters
Could you elaborate? Slack provides client tokens and they don't seem to forbid that in the way Discord does (in fact they explicitly provide client tokens via OAuth).
To be fair, the ones I specifically remember were various browser extensions and plug-ins that would modify the browser version of Slack's official client.
However, I could have sworn there were a few full-fledged clients that Slack didn't like. I feel like one of them was a terminal-based client.
It's pretty rough really, within Discord's native or webapp you have to pop open the devtools/network-tab and grab an auth token from a request header, heh
Works really well though. I've been lazy about addressing a mic-not-working issue on the linux client, and had been resorting to using the webapp when I wanna voice
Thoughts after around 5 minutes. It's fast, really fast. Cmd + P Fuzzy Find for switching chats between Discord/Slack and person/channel is amazing. Will continue to use as it doesn't appear to be near as buggy as Volt.
However I do wish this was an open source project. Seems odd to close something like this off in this day and age. Seems like another one of these chat clones destined to die off unfortunately.
Unfortunately it's not so much me, but my friends in this case. If I want to stay in touch with a large group of past co-workers who are all in the same slack, it isn't feasible to convince them all to switch to a self hosted service.
Even in the case of those programs you mentioned though, aren't they still plagued by a slow/electron based client?
*edit: I just looked into Matrix. Looks awesome. Wish my friends used chat programs like this. I will try to implement this with some of my closer friends.
I have this problem myself, I like very little about Slack but I have to use it for work. And since it's all proprietary anyway, I don't particularly care about the client being Free.
I just wish the client was free in this case because it would be a shame to see it turn into abandonware. I've only used it since yesterday now, but it's quite performant.
Trillian isn't dead though. I still use it, despite the internet becoming more and more of a walled garden.
Trillian still works just fine with Google hangouts, and facebook messenger too, as long as it's not a group chat.
I tried Ripcord but my main problem is that it just looks ugly on macOS. That's why I decided to build a new Slack client instead (Ben [1]). It started out as a dogfood for my other side-project (ReactQML [2]) but then I believe we can build high performance yet good looking native applications, using front-end technologies (no, not Electron/webview). Currently here is Ben's tech stacks:
The best part is that we can truly "code one, deploy everywhere". I was able to compile Ben to both desktop (MacOS, Windows) and mobile (iOS, Android) from same one codebase.
Though it's still far from feature-complete but I hope I can finally uninstall the official Slack app for good. You can try latest build here [3]
Your app looks great, and props to completing a project for something you wanted. However, I'd reconsider using the word "native" in your marketing since TypeScript and QML on a macOS desktop is not by any means native. TypeScript compiles into JavaScript which must run in a virtual machine like any other JavaScript program.
Ah, so cool to see this on HN! I've kinda snooped on the development of this software over quite some time and always been impressed by the author's persistent attention to performance/optimization. The "minimalistic" approach has been refreshing to see when nearly every popular new online software seems to require gigabytes of RAM for its embedded web-rendering engine. ;)
I exclusively use the web interface for both, as its easier to shut off from work when its just a tab I can close, as well of not liking the bloat of chromium based apps.
But if this is stable and lightweight I might use it. Gonna test it for a while.
This seems to be a common hurdle on non-Electron Slack clients (well at least on the one or two others I tried within the last few years that I can't remember the names of now).
I'd try and even use it because Electron-based Discord client acts like resource hungry pig on my machine, especially when I'm already running multiprocess browser and GW2 who happens to use CoherentUI to render some of its UI (which happens to be also based on Chromium fork), but: I'm afraid being banned and creating new account every now and then, getting onto servers, asking for invitations isn't something I'd like to do.
So, what are chances that Discord may feel "offended" by user login with and using Ripcord?
This is awesome!! really. like really. Great job! As a power user myself, I tend to go for the CLI style of view, in most cases that txt heavy.
I do have one question. <!here> is how you notify everyone in a channel about your msg. Can you customize this in the settings? otherwise, its a small adjustment I can make as you already have an app that I like more than the native slack app on macOS.
I have to reload Discord every hour or so when the audio goes down the tubes and starts constantly breaking up so if this client doesn't do that I will consider it a winner.
Fantastic! I’ve been running some memory-heavy jobs on my computer recently and literally had to close Slack so I could get a chunk of memory back and it have my job killed.
The discord api is pretty well documented. The bot api and the user api are actually the same thing, but you're only allowed to use the bot api. You can still use the user api but if they catch you they'll ban you, so we'll see how this client pans out.
There's only been one known case of someone being banned from Ripcord usage, due to too many requests being sent, triggering spam protection.
Their account was unlocked after contacting support.
The software now doesn't sync users to a sqlite local database if there's over 10k members in a guild, as a precaution
Discord is a pretty decent company so far IMO, I figure if they're okay with 3rd party clients then they'll be extra lenient on the rules. So far their success has been how much the community loves love (not to mention how well it works).
At first, I thought "what's the point?" Then I saw:
"It's not built on top of web browser technology: it responds quickly to input, sips gently from computer resources, and gets out of your way."
Reminds me of my IRC client.
I wish I could use my IRC client: https://news.ycombinator.com/item?id=16539857
I mean I wish we just stopped there, IRC, done, call it a day, never ever think about many to many written communication ever again. It works, scales, supported on all platform, text based, small memory/cpu footprint. Just like we stopped developing hammers a while ago. CS is the only field where 1.0 is never good enough. We keep "innovating" adding features that nobody needs and complicating things until it becomes this unmanagable mess. </rant>
As a big fan of IRC, I would have to say that it doesn't "work" at all when compared to Slack or Discord. You have to be online to receive messages, making it pretty much useless for any serious communication needs. Yes, I am aware of, and run, an IRC bouncer, this is not a real solution for 99% of users.
Only receiving messages while online is a feature. Want to work async? Email.
Except some people can be having a conversation while I'm offline. When I get back on, I can catch up or have someone link me to an important part of it. It's handy.
In some teams, IM+history is the email killer that happened by the mistake.
A feature to the small handful of people who still use IRC. Look around though. Everyone else expects basic features like being able to send someone a message even though that person went through a tunnel.
I work with a bunch of people in oakland, where comcast flickers on and off like a light bulb during a wind storm in the 1920's. So the only way to have a quick chat is over email?
It's also limited to straight text. People may say it's frivolous, but sending pictures and other media is expected now.
IRC is not limited to plain text. Discord, Slack, and IRC all handle media the same way. Someone sends an URL and the client decides to how to handle displaying it. Textual shows me images and videos all the time from URLs sent.
I guess then technically IRC servers need a way to have images uploaded and re-serve them. When I share an image on slack I'm usually just uploading it directly to slack, rather than using imgur or another uploader.
I thought they stored the graphics on the server with Discord. I know there is that out-of-band file protocol that some IRC clients support, but it was always a terrible hack that hated firewalls.
That's not how I use the feature at all. The vast majority of images and files I send are created locally. I can then upload or paste then into the chat client, they get stored on the server and shown to the other users. With IRC, I would need to use a separate service like imgur to first upload the images. And or a file hosting service like Dropbox for the files.
A robust IRC client could include integrated image hosting. Or ask you to plug in your Dropbox account, and then upload there automatically when you drag and drop a file or image.
Have you seen irccloud?
That's incorrect - you can send binaries over IRC with DCC.
Unless things have changed since my IRC days, doesn't this a) require routed ports, so anything not a private controlled network is out, b) expose your IP address, which is a security risk, and c) is 1:1 only. It's also more of a side protocol than actually being part of IRC, right?
Whereas posting images directly into the chat window and having everyone see it is insanely useful.
It does not have full slack-like functionality. But it was never limited to just text. Some of the biggest communities on IRC revolve(d) around file sharing over DCC.
Anyway I think saying that it's "insanely" useful is a gross exaggeration. You know what is insanely useful though? Having open source clients and access to logs without paying $100 per year per user.
So, our small team is using google hangouts but that also supports image pasting (and is searchable, free).
Image pasting is for more than just memes. We can post screenshots of errors, or user data/visualisations, or sections of syntax-highlighted code. All of this is infinitely more agile than going through a bulky ticket system (which we also use once we’ve confirmed as bugs or decided how to use forwards). So no, it’s not an exaggeration at all.
IRC was fun in the 90s but seems to have stopped there? It was also never ~at all~ friendly for non-technical users, which is a complete non-starter nowadays.
The alternative to pasting images is making a ticket? I would have thought it would be uploading images to some image hosting site and then pasting a link.
Don't forget NickServ. It's a pretty massive user bottleneck. More than half of the people in my (tech) company would probably take more than 20 minutes to figure that out.
I used to spend a fair bit of time in a non-tech IRC (we've moved to Discord since) and the amount of intelligent people who simply could not get the hang of NickServ was astounding.
I've always wondered why IRC clients didn't add seamless integration with NickServs of large networks. Maybe this was one of the reasons why services like Slack or Discord are successful; these services are taking your hand and are guiding you through everything, while IRC expects the user to read RFC and diagnostic server output in order to figure what's going on. I don't think it has to be this way.
IRC as a protocol probably can be used to build a service as friendly as Slack. I.e. it's not a problem to add URL autoexpansion, like in this WeeChat plugin: https://github.com/antekone/youtube-autoexpand . Of course it's not easily possible or practical to show pictures inside of the terminal window, but I think it's entirely possible to create a new modern Slack-competitive IRC client over a pure IRC network. What could be done on IRC can be seen in an old Microsoft app, Microsoft Comic Chat: https://en.wikipedia.org/wiki/Microsoft_Comic_Chat .
(disclaimer: i prefer IRC to Slack/Discord but I get why for many people IRC is a bad idea)
NickServ always felt like a terrible hack to me. It doesn't help that some major servers have incredibly stingy limits on NickServ too. I've had usernames age out after only a week, and the registration process is fairly cumbersome. Plus it involves sending a password in plaintext over the network, which never felt good.
Many IRC servers provide a service that allows users to send messages to offline users, which are then relayed to the user when they come online.
Kind of a toothless "many" when this isn't even built into Freenode. I have to wonder if any IRC server I've ever connected to supported it and why I've never seen this feature.
It's a common IRC bot feature. Typically there's a command like: .tell <user> <message>
Freenode does support it.
You can. See my top-level comment on this post https://news.ycombinator.com/item?id=19618630
Who cares that it's not built in Electron? Slack is plenty fast, your average user does NOT notice the difference.
My laptop battery sure does. Electron is legitimately wonderful, but apps built on it are often horrible CPU hogs.
But I do notice and on my machine I prefer lightweight apps, so I can make the most of my existing resources instead of wasting them on a chat application.
They will.
I notice how long it takes to start up the app, I notice how hard my CPU fan runs when Slack inexplicably decides to max out a whole core for a few minutes, I notice the data hit if I have to download a new version while on the road. It's definitely bloatware.
If you're in more than one workspace it can take literally 5-10 seconds to transition between them while showing some BS motivational message.
Slack lags seconds behind when I type anything.
I actually ran into that today and restarting the app fixed it. That shows that there's a pretty serious limitation if such a high profile app has these sorts of problems.
For future reference to OP: the term you're looking for is "modern web technology" or "modern technology"
Emphasis on "modern" --- I distinctly remember using some web chat clients with IE6 in the early 2000s, and they didn't need hundreds of megabytes of RAM (average PCs had a total of between 64 and 256MB of RAM) and the whole (single-core at the time) CPU to do what today's web apps do.
For anyone who knows what I mean, it might be interesting to write such a "lightweight" web client for e.g. Slack, restricting yourself to whatever JS abilities were available in 2000 or so, yet imitate as much of the features and appearance of the web client today as possible. Chances are it will still work with "modern" browsers too, and use a tiny fraction of the resources of the current one. All the better if it gets noticed and DMCA'd.
JIT engines operate on a time-memory tradeoff.
Oh please. I'm not about to start referring to a specific toolkit as "modern technology” at the expense of everyone else, particularly a step backwards
That was meant as a sarcasm and I was pretty sure anybody who hates electron would get it. Sadly, no.
I don't actually use any of these services so I had no need to, but just being curious, I downloaded the Windows client; and while it may be smaller than Electron apps and native, it's still quite large for a native app --- over 30MB, and also 64-bit only (why? Do you expect to need more than 4GB of RAM for this?)
To contrast, MSN Messenger 4.7, an app with similar capabilities (IM, voice, and video calling), is only ~2MB --- with several third-party reimplementations being <1MB. Makes you wonder how small you can make an app for today's messaging services if you really tried... they don't need to be that big even if they don't include an entire web browser.
I'm surprised at the criticism about 64-bit only. Are people still using 32-bit operating systems?
Yes.
A 32-bit binary will work just fine on a 64-bit OS, but not the other way around, and there's no reason such an app needs 64-bit, so why unnecessarily restrict compatibility?
I think you're in a minority. Are there any 32-bit CPUs being produced for the mass market these days? Making a 64-bit only software is not only about wanting more than 4gb of ram; it's about debugging support, tooling, installation size and installation packages, etc. It's easier to distribute 64-bit only software than both 32-bit and 64-bit, and you can't distribute 32-bit only software because:
1. macOS will deprecate 32-bit completely soon,
2. Linux needs 32-bit libs installed on the system, and many people don't have them,
3. Windows has really good backward compatibility and still supports 32-bit. But it's the only system.
So, distributing a 64-bit-only software actually makes sense.
This exactly.
When I install something, if it pulls in a ton of stuff, I'll reevaluate whether I actually need it. In fact, I was pretty excited when I finally got rid of my dependency on 32-bit stuff and could eliminate the 32-bit repo.
I like 64-bit because it keeps my system clean, but because it's "better". I definitely want a 64-bit OS so some things can use more than 4GB RAM, so why have two copies of everything? Just standardize on the thing nearly everyone uses: 64-bit.
Are there any 32-bit CPUs being produced for the mass market these days?
Can we stop assuming that people are always going to have the latest hardware? Even then, 32-bit SoCs running Linux are still pretty common in various embedded things and other low-power devices --- exactly the use-case for a small and native chat client.
You don't need the latest hardware to have a 64-bit CPU.
Slack client on an embedded platform? Are you ok?
Not exactly true for Linux - a modern Linux desktop usually has only the most basic (libc, ...?) 32 bit libraries installed. Though an AppImage (which Ripcord uses) might work because it's mostly self-contained anyway. On Linux, approximately nobody still uses 32 bit systems.
Honestly I would criticise if it was 32-bit.
When can I finally get rid of this stupid "Program Files (x86)" folder which annoys me every time I click into the wrong one looking for my program, when even new programs are released as 32-bit?
> it's still quite large for a native app
It's not native (as in native windowing toolkit), it's Qt based which is probably where most of that 30MB is going, MSN Messenger is/was built on win32. Still, in the age of electron apps that's a huge improvement, it's good to see real desktop developers still exist.
Its not like 32 bit applications are more efficient than 64 bit applications.
There is place for 32 bit applications but not here! The job of a program is to do what it is supposed to do efficiently and get out of the way, and it better use all registers and instructions needed to do it.
Its not like 32 bit applications are more efficient than 64 bit applications.
Yeah it is. You need to move 7 bits through memory and through the CPU, is it more efficient to pad it with 25 blank bits and move 32 bits overall, or pad with 57 blank bits and move 64 bits overall?
Which is doing things "more efficiently" and "better using" the hardware?
thats not the question you have to ask though.
your cpus arent capable of 32 bit calculations anymore... so the questions is: is the software emulation of your OS for 32 bit more efficient than the programming language overprovisions.
The CPU is still perfectly capable of 32bit calculations. Even 8 bit calculations. What you can't do is use 32bit pointers (though, strictly, you can, but x86-32 isn't well supported, I wonder why?)
You are technically right, but only because I expressed myself very poorly.
The CPU is naturally still able to do 32 bit calculations.
What you can't do is run a 32 bit application without emulation after a 64 bit system has booted.
The libraries are obviously also required, but it still won't be able to start without the emulation adding 0 to the memory blocks.
Source? Not that I don't believe you, I just don't understand from your comment
It's not -entirely- true but it's not false, either as far as I'm aware.
Windows in specific uses WOW64 -- Windows 32 on Windows 64. It's an emulation layer that doesn't actually hamper performance but does do things a bit differently than a native OS -- such as running all 32bit programs in 'user mode' rathe than with elevated permissions.
You can get a brief synopsis here - https://www.techsupportalert.com/content/how-windows7-vista6...
If you use eax instead of rax, you can do both. Compilers are smart these days and will use the appropriate register size when necessary. If you need to move 7 bits, it'll likely use the al register.
I can't edit, but it seems my reasons for thinking 32-bit can be faster aren't entirely daft - but the gains of 64-bit x64 include it having simply more registers, having smaller faster floating point precision, being able to request more memory at once, and the hits to pointer size overheads or processor cache holding less real data are rare and mostly from buggy or odd conditions, and that for a lot of normal programs there'll be no difference either way:
https://stackoverflow.com/questions/2378399/are-64-bit-progr...
https://stackoverflow.com/questions/324015/supplying-64-bit-...
https://stackoverflow.com/questions/2334148/is-there-any-rea...
interesting.
Most of the stuff is taken from the fact that Ripcord is multiplatform. It uses Qt5, it takes lots of space, but works everywhere. Ripcord also bundles lots of libraries for lots of file formats (audio, video), bundles OpenSSL for cryptography support (although the library is from 2014, and probably should be updated), should theoretically support Wayland (at least it has some libs for supporting it), etc.
MSN Messenger probably uses WinAPI and being a Windows-only program it can get away with it.
I like that "Not made from a web browser" is a headlining feature. My laptop has 16 GB of RAM, and still doesn't have enough memory to run all the Electron apps I use without grinding to a halt.
I think this meme needs to die. I run 3 massive electron apps on the regular, in addition to my multiple IntelliJ IDE instsances and RDBMS clients on a 16gb Macbook Pro, the latter category being the biggest resource hogs.
Just because it doesn't affect you doesn't make it an untrue meme. Electron apps are notorious for bloat, that isn't a meme, it's a fact.
The only apps that consistently send my laptop fans in to a flying rage are Electron based apps.
It's not a meme if it's true. Here's my current system.
https://i.imgur.com/Eqo3pcv.png
800Mb to VS Code
650Mb to Slack
Is slack's web socket taking 600Mb?
It's 3.7% of your total RAM, hardly a "grinding to halt" amount.
Is 800Mb acceptable for a chat app?
When we pay less than $10/gb for ram and our systems have 32 gb and more, I do consider it acceptable. As long as the speed of development and feature implementation is sufficiently improved of course.
My system doesn't have 32GB RAM, and I really don't want that because my users don't have 32GB of RAM, they have 4GB. I don't want to get in the habit of just throwing away RAM because some target devices may have much less available, and I may want to port to such limited devices (phones, Raspberry Pi, small VPS instances, etc) where RAM is hard to come by or expensive.
An app's resource use should just justified by what the app does. It's really telling when a 3D game engine uses about the same resources as an electron app.
Who is our? Most systems do not have 32gb of RAM. My grandma isn't going to be writing emails on a MBP with maxed out specs, neither will a majority of people have more than 4 or 8GB of RAM.
Source: https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
No.
Ripcord is currently running in 23.3MB on my machine
Is all 800mb resident, and just for that app? On osx people often just look a the 'Memory' column in activity monitor, which says slack + the slack helpers are using 1.4GB of memory (OMG Electron sucks!) - but it is using 633MB of real memory. So not great if you are used to bitchx or something. But not terrible - half of what it initially looks like. Memory management is complicated.
You're shifting the goalposts. Original text contained mention of 650MB Slack making your 16GB system "grind to a halt".
IntelliJ has much more functionality than Slack so it's a poor choice to compare it to. Also... comparing slow cross platform tool to another sluggish cross platform tool isn't really a great place to start.
The fact that this Rip Cord does 99% of what Slack does and uses a fraction of the memory and runs faster pretty much says it all. Javascript/ Electron are resource hogs.
Badly written Javascript/Electron apps are resource hogs.
Compared to virtually any compiled language, Javascript is a resource hog, regardless of how well written.
It is also single-threaded (without workers, which have their own limitations), and any large calculation can block that main thread.
Sure, it may be efficient but what percentage of feature compatibility do you think they'll be able to reproduce and maintain?
Largely depends on how quickly Slack/ Discord move their APIs and how aggressively those platforms block this kind of app. This has little to do with app performance though. Slack is a sluggish pig because the way it's written, not because of it's feature-set
It makes me sad that people continue to put their time and effort into supporting these closed communication systems. If anyone else is considering making something like this, please base your efforts on Matrix. It's so much better for us and so much more deserving of our attention.
Chicken and Egg. People don't use Matrix.
To be fair, for an internal communications usecase you just need to convince your company, not half the world
I’d open source comms tools leaned more into business use cases (mattermost does this well) then there could be more usage
> To be fair, for an internal communications usecase you just need to convince your company, not half the world
I imagine that's true for companies whose users stick to internal workspaces, but often the most active/vocal users (1) participate in multiple (often professional) non-company workspaces, and (2) don't want to run Yet Another Chat client.
That's less of a problem with Matrix. I set up a WhatsApp bridge because all my friends are on WhatsApp, and now I can use any matrix client, even a very lightweight CLI one, to talk with them.
xmpp as well (matrix is getting a lot of love right now, but it's also got some warts deep in areas that are not the plushy UX)
YES! This is awesome. Have it up and running with Slack.
I checked for:
* Thread support (yes)
* Drag n drop images (yes)
* SSO support (yes)
* Quick Switcher (yes)
* Default dark mode (yes (!!))
There are some things missing, like search, fine grained notification controls for muting, profile editing, code snippets, moving emojis, etc. But for daily communication, I'll give it a try. Feels fast and light.
Edit: After some time, I think I will keep it around for when I am on the go and want to preserve battery. I do not think I'll use it full time because I miss some of the colourful whimsy of the Slack client.
> There are some things missing, like .... moving emojis, etc.
Isn't that a feature?
Looks like a good project, I may give it a try on Windows.
On Linux, I use weechat to connect to a local bitlbee for Discord and Hangouts. When I was using Slack I used wee-slack [0] with success, but it looks like bitlbee has a plugin for Slack, too [1]. This lacks a few of the features of Ripcord (e.g. voip, graphical emoji, emoji completion), but it works.
[0] - https://github.com/wee-slack/wee-slack
[1] - https://wiki.bitlbee.org/
How does this work? Discord has been notorious in shutting down third-party clients; what makes this different than the others?
This one is different in that is says that they will one day charge for it so instead of just shutting it down the author will have a lawsuit on his lap.
Are there examples where an alternative client was successfully sued? Seems like it would be like suing Firefox because you want your users to use the browser you provided.
I would think that worst case, slack could kick users off for breaking their terms of service (assuming there is a clause for that). But a random software maker is not subject to slack's terms.
Well I don't know any paid alternative clients. All of the ones I know are free.
Not exactly an alternative client scenario, but Blizzard successfully shutdown a US company that developed and sold World of Warcraft botting software.
https://en.wikipedia.org/wiki/MDY_Industries,_LLC_v._Blizzar....
The gist of Blizzard’s argument was that the software was designed for the sole purpose of facilitating customer violations of their EULA causing monetary harm to Blizzard.
Disclaimer: I used to be a customer service representative of Blizzard Europe, but not since 2012.
Ya, I'd say that case is quite a bit different due to the actively harmful effect it would have on other users.
Slack would also need to prove monetary harm. I can't imagine a more efficient client would hurt their service. Maybe just their pride.
Depends on the country this developer is based, 3rd party clients are legal in a most places regardless of what they say in their TOS.
Unfortunately, there isn't a chance this survives, especially if it's closed-source and for money. Discord doesn't allow third-party clients (which I swear should be a legal issue since it's a PUBLIC API but whatever), and Discord is known to aggressively block and prevent third-party clients.
If you want something that doesn't suck, look somewhere other than Discord. It sucks that it's so embedded into so many groups but Discord isn't a very friendly entity.
I love the interface, but how does it connect with Discord and how long until they try to shut it down?
I'm not very familiar with Discord, but I thought the same about Slack. Slack has been aggressive in the past sending C&D letters to those who threaten their walled garden. I'm not saying it'll definitely happen in this case and I wish all the best to the developers and users of Ripcord. I sympathize with their want for non-electron desktop clients. But I wouldn't be surprised at all if they received a terse and disapproving letter from Slack's legal team.
> Slack has been aggressive in the past sending C&D letters
Could you elaborate? Slack provides client tokens and they don't seem to forbid that in the way Discord does (in fact they explicitly provide client tokens via OAuth).
To be fair, the ones I specifically remember were various browser extensions and plug-ins that would modify the browser version of Slack's official client.
However, I could have sworn there were a few full-fledged clients that Slack didn't like. I feel like one of them was a terminal-based client.
It's pretty rough really, within Discord's native or webapp you have to pop open the devtools/network-tab and grab an auth token from a request header, heh
Works really well though. I've been lazy about addressing a mic-not-working issue on the linux client, and had been resorting to using the webapp when I wanna voice
This ends up working fine for me though re: voice
Low footprint is nice too
Thoughts after around 5 minutes. It's fast, really fast. Cmd + P Fuzzy Find for switching chats between Discord/Slack and person/channel is amazing. Will continue to use as it doesn't appear to be near as buggy as Volt.
However I do wish this was an open source project. Seems odd to close something like this off in this day and age. Seems like another one of these chat clones destined to die off unfortunately.
It's a better client for a proprietary service. If you / your org cared about freedom, you'd be using Matrix or Rocket.chat.
Unfortunately it's not so much me, but my friends in this case. If I want to stay in touch with a large group of past co-workers who are all in the same slack, it isn't feasible to convince them all to switch to a self hosted service.
Even in the case of those programs you mentioned though, aren't they still plagued by a slow/electron based client?
*edit: I just looked into Matrix. Looks awesome. Wish my friends used chat programs like this. I will try to implement this with some of my closer friends.
I have this problem myself, I like very little about Slack but I have to use it for work. And since it's all proprietary anyway, I don't particularly care about the client being Free.
I just wish the client was free in this case because it would be a shame to see it turn into abandonware. I've only used it since yesterday now, but it's quite performant.
Feels like IRC with Trillian mixed in.
Pretty funny the iterations chatting over the internet has went through over the years. Feels like bell-bottoms just came back into fashion.
I miss Trillian. That was a fine program. I actually wrote an extension for it that allowed me to automate things with Tcl/Tk.
I still use Trillian
I hate what Google did to GTalk and Hangouts
Trillian isn't dead though. I still use it, despite the internet becoming more and more of a walled garden. Trillian still works just fine with Google hangouts, and facebook messenger too, as long as it's not a group chat.
> and facebook messenger too
Mostly. It doesn't show messages with the facebook link-preview.
Another Trillian user chiming in.
They are working mainly on their own server and Trillian for web, but the desktop version is still alive https://trillian.im/news/
I tried Ripcord but my main problem is that it just looks ugly on macOS. That's why I decided to build a new Slack client instead (Ben [1]). It started out as a dogfood for my other side-project (ReactQML [2]) but then I believe we can build high performance yet good looking native applications, using front-end technologies (no, not Electron/webview). Currently here is Ben's tech stacks:
- Back-end: Qt5, breakpad, QtKeychain
- Front-end: TypeScript, webpack, babel, react, redux, redux-observable, redux-persist, QML.
The best part is that we can truly "code one, deploy everywhere". I was able to compile Ben to both desktop (MacOS, Windows) and mobile (iOS, Android) from same one codebase.
Though it's still far from feature-complete but I hope I can finally uninstall the official Slack app for good. You can try latest build here [3]
[1]: https://github.com/longseespace/ben
[2]: https://github.com/longseespace/react-qml
[3]: https://github.com/longseespace/ben/releases/download/v0.2/B....
Your app looks great, and props to completing a project for something you wanted. However, I'd reconsider using the word "native" in your marketing since TypeScript and QML on a macOS desktop is not by any means native. TypeScript compiles into JavaScript which must run in a virtual machine like any other JavaScript program.
The business logic may be in JavaScript, but the rendering is all native opengl/c++.
I think it's fair to refer to it as native.
Too bad it's closed source.
Ah, so cool to see this on HN! I've kinda snooped on the development of this software over quite some time and always been impressed by the author's persistent attention to performance/optimization. The "minimalistic" approach has been refreshing to see when nearly every popular new online software seems to require gigabytes of RAM for its embedded web-rendering engine. ;)
I exclusively use the web interface for both, as its easier to shut off from work when its just a tab I can close, as well of not liking the bloat of chromium based apps.
But if this is stable and lightweight I might use it. Gonna test it for a while.
Thanks.
Why not just make a new client? As others have mentioned, I don't see this landing well with Discord.
Just because there are a bunch of group chat apps already, doesn't mean people won't switch to a better one.
Does this support Azure login on Slack?
This seems to be a common hurdle on non-Electron Slack clients (well at least on the one or two others I tried within the last few years that I can't remember the names of now).
There's support for importing your login from your browser. This has to be used if your slack domain doesn't use the generic slack login page.
If you're familiar with HAR files, this is what's used
I'd try and even use it because Electron-based Discord client acts like resource hungry pig on my machine, especially when I'm already running multiprocess browser and GW2 who happens to use CoherentUI to render some of its UI (which happens to be also based on Chromium fork), but: I'm afraid being banned and creating new account every now and then, getting onto servers, asking for invitations isn't something I'd like to do.
So, what are chances that Discord may feel "offended" by user login with and using Ripcord?
This is awesome!! really. like really. Great job! As a power user myself, I tend to go for the CLI style of view, in most cases that txt heavy.
I do have one question. <!here> is how you notify everyone in a channel about your msg. Can you customize this in the settings? otherwise, its a small adjustment I can make as you already have an app that I like more than the native slack app on macOS.
Will this support Mattermost as well?
The client feels fantastic! Is there any way to have unread channels bubble-up to the top of the cmd-k quick switcher?
This seems like the only functionality that would keep me from using Ripcord full-time.
I have to reload Discord every hour or so when the audio goes down the tubes and starts constantly breaking up so if this client doesn't do that I will consider it a winner.
Fantastic! I’ve been running some memory-heavy jobs on my computer recently and literally had to close Slack so I could get a chunk of memory back and it have my job killed.
I'd rather someone would spend time on a better Matrix or XMPP client but assuming the Discord staff have a hissy fit over ToS it looks quite nice.
Looks great! What technology is it built on? Did you reverse engineer Discord's API or is there a documentation or library?
The discord api is pretty well documented. The bot api and the user api are actually the same thing, but you're only allowed to use the bot api. You can still use the user api but if they catch you they'll ban you, so we'll see how this client pans out.
There's only been one known case of someone being banned from Ripcord usage, due to too many requests being sent, triggering spam protection. Their account was unlocked after contacting support.
The software now doesn't sync users to a sqlite local database if there's over 10k members in a guild, as a precaution
Oh that's cool, are you affiliated with Ripcord?
Discord is a pretty decent company so far IMO, I figure if they're okay with 3rd party clients then they'll be extra lenient on the rules. So far their success has been how much the community loves love (not to mention how well it works).
Ripcord was written in C++ with the Qt framework — https://pastebin.com/raw/RLZ4A9fa
This is nice. Not perfect - I wish it was FLOSS for one, and the icons are a bit clunky. But much better than the alternative.
Been using it for a while. Fits perfectly for every day use, except it lacks searching feature present on official client
Same, works very nicely, especially for memory-hogging slack, a shame the search isn't integrated
I just wanted to check in -- I've been using this for a few days now and love it. I would pay for this.
I was skeptical but this looks p feature rich already! I love it :)
If this had Telegram support I wouldn't need anything else.