Show HN: Eul – a lightweight desktop client for Skype, Slack, Gmail, and more(eul.im)
eul.im
Show HN: Eul – a lightweight desktop client for Skype, Slack, Gmail, and more
https://eul.im
100 comments
Three things:
- THANK YOU! It's near impossible to find a client that isn't either run in a console (admittedly not the worst problem) or horribly bloated (what the hell are people thinking when the bundle a browser to show a single page!?).
- What do you think of adding Matrix (https://matrix.org)? The protocol is HTTP + JSON based and well documented.
- Have you thought about open sourcing? My guess is either you want to sell this eventually or your coding standards are quite high and you doubt people can contribute too much while meeting them. In the case of the latter, I'd still like for it to be around, even if your standards for PRs would be too high for me to meet.
- THANK YOU! It's near impossible to find a client that isn't either run in a console (admittedly not the worst problem) or horribly bloated (what the hell are people thinking when the bundle a browser to show a single page!?).
- What do you think of adding Matrix (https://matrix.org)? The protocol is HTTP + JSON based and well documented.
- Have you thought about open sourcing? My guess is either you want to sell this eventually or your coding standards are quite high and you doubt people can contribute too much while meeting them. In the case of the latter, I'd still like for it to be around, even if your standards for PRs would be too high for me to meet.
I have to agree about matrix. In fact I think at this point effort should be focused on bridging protocols to matrix instead of each different client implementing support for protocols by themselves. Then the client can only implement matrix support.
Protocol bridges always only provide a subset of the original functionality, mostly because it's impossible to fully map one protocol to another.
Of course, the same problem can happen for a multi protocol client as well, but at least it's not inherently impossible to solve it there.
Of course, the same problem can happen for a multi protocol client as well, but at least it's not inherently impossible to solve it there.
Ideally yes, that's what should happen. But it's very unlikely...
Thanks!
Matrix will definitely be implemented at some point. Not within the first 2 months unfortunately.
Yes, my standards are pretty high, but like I said before here, I do consider open sourcing it.
Matrix will definitely be implemented at some point. Not within the first 2 months unfortunately.
Yes, my standards are pretty high, but like I said before here, I do consider open sourcing it.
The in browser Slack is getting slower each day. If I don't do a full refresh of the page after about an hour, the interface is so slow that even typing text is painful.
So having a lightweight client is definitely appealing to me. However Slack keeps adding features often and every one using Slack assumes the recipient runs the same version of Slack as his.
I wonder how can your unofficial client can deal with this problem the next time Slack releases the next update that is as big as adding threaded conversations for example.
So having a lightweight client is definitely appealing to me. However Slack keeps adding features often and every one using Slack assumes the recipient runs the same version of Slack as his.
I wonder how can your unofficial client can deal with this problem the next time Slack releases the next update that is as big as adding threaded conversations for example.
Good point. I'm planning to make sure all protocols and latest features are supported.
I came across the new threaded conversations yesterday, and they can be implemented in one or two days.
I came across the new threaded conversations yesterday, and they can be implemented in one or two days.
My coworkers and I have been looking for something exactly like this, and we've been let down by numerous Electron projects like Franz that don't really offer any different, simplifying experience.
I will definitely be trying this out.
However a question essential for our pending use is: any plans to support HipChat? That would pretty near seal the deal for my current group.
I will definitely be trying this out.
However a question essential for our pending use is: any plans to support HipChat? That would pretty near seal the deal for my current group.
Hi,
Eul's target audience is primarily professionals, so it's silly of me to forget about HipChat. I just had a look at its API, and yes, it will absolutely be supported. In fact, most likely this is going to be the next protocol implemented.
Should be done by mid-August.
Eul's target audience is primarily professionals, so it's silly of me to forget about HipChat. I just had a look at its API, and yes, it will absolutely be supported. In fact, most likely this is going to be the next protocol implemented.
Should be done by mid-August.
Hi again! That's great news. I passed the app around to my coworkers already, however we can't actually use it!
If it's at all possible, we'd love to have a build compatible back to macOS 10.10. Right now, it can only run on 10.12 and we work in a large enterprise where updates are withheld for mostly software-compatibility reasons (a lot of media software relies on older systems).
If it's at all possible, we'd love to have a build compatible back to macOS 10.10. Right now, it can only run on 10.12 and we work in a large enterprise where updates are withheld for mostly software-compatibility reasons (a lot of media software relies on older systems).
Hopefully you'll make your gui mini-framework opensource.
Though I would think it would be similar to something like https://github.com/ocornut/imgui
Though I would think it would be similar to something like https://github.com/ocornut/imgui
Nice idea. FYI I just tried it on my Mac (10.12.5) with Safari as a default browser and Safari crashes every time it's opened to do the login to any service. After a couple try also eul crashed.
Will stay at the window for updates :)
Will stay at the window for updates :)
Thanks for testing it. Strange that it crashes on Mac, I'll check the logs and investigate.
[deleted]
Sir, what's the obstacle for supporting El Capitan, I think it is not too old?
It doesn't run on El Capitan? What kind of an error do you get? Can you send more details to [email protected]?
Thanks
Thanks
I sent you a report. Thanks for addressing. Looking forward to using your app!
added gmail and Skype just Skype shows up
added slack too but nothing happens !!!
theres an empty shared window whats that
Initial thoughts:
- This is a native application, but does not use any native controls, so currently lacks text selection or navigation, tab to change input focus, or anything else you'd expect from a native application (apart from speed). One of the things that bothers me most about the Slack application is it's lack of interoperability with macOS, for example in drag and drop - this application does not appear to be targeting that interoperability either.
- Slack authentication doesn't appear to be working at the moment - it directs me to my browser to authenticate, but after doing that I'm left in the Slack web-app, not redirected back to the application.
- This is a native application, but does not use any native controls, so currently lacks text selection or navigation, tab to change input focus, or anything else you'd expect from a native application (apart from speed). One of the things that bothers me most about the Slack application is it's lack of interoperability with macOS, for example in drag and drop - this application does not appear to be targeting that interoperability either.
- Slack authentication doesn't appear to be working at the moment - it directs me to my browser to authenticate, but after doing that I'm left in the Slack web-app, not redirected back to the application.
You are right. You can't even copy text right now. These little UI things will gradually be implemented very soon.
Are you a member of multiple Slack orgs?
Are you a member of multiple Slack orgs?
Looks really cool! Just a couple of questions:
1. Are you planning to release this as open source? I really want this to have a native Cocoa interface on macOS.
2. When you say Gmail, do you mean email or Hangouts?
3. Where are you getting these APIs from?
1. Are you planning to release this as open source? I really want this to have a native Cocoa interface on macOS.
2. When you say Gmail, do you mean email or Hangouts?
3. Where are you getting these APIs from?
Is it possible to fix the scale factor for Linux desktop hidpi display? It doesn't seem to pickup system global setting for the display. Does it use GTK on Linux or what is it using otherwise?
Yup, same problem here on a XPS 13 with Fedora 26.
Hey - I wanted to give you a BIG thank you for creating a native / non-JavaScript client for this, JavaScript (no matter the framework) has been the death of me and my peers with regards to desktop ‘apps’ for the last few years and it’s so damn good to see someone stop, think and give a $#!+ about performance. I’ll add that the last thing I (and I’ve heard my team say the same) want is another app that has to run in a web browser.
When I get to work tomorrow I’ll be trying this out (knowing it’s in beta) for XMPP / Jabber, if it doesn’t already support OTR encryption - that’d be a killer feature. A big problem I see is that a lot of places want to or do run internal XMPP/Jabber because they have engineers working that don’t want to / can’t run ‘enterprise’ rubbish like Skype or those of us that are sick of JavaScript heavy SaaS apps like slack - but then you’ll have a few managers or project managers that still run Windows likely for excel or out of habit etc... and they have to use Pidgin - which while it works across a lot of IM systems - is very awkward and ugly as anything, so it gives the better protocols a bad name, on Mac there’s Adium which is a pretty decent multi-IM client but has stagnated somewhat. So a clean, easy to use, stable and well performing chat client that supports XMPP/Jabber with MUC and OTR would be an absolute killer.
When I get to work tomorrow I’ll be trying this out (knowing it’s in beta) for XMPP / Jabber, if it doesn’t already support OTR encryption - that’d be a killer feature. A big problem I see is that a lot of places want to or do run internal XMPP/Jabber because they have engineers working that don’t want to / can’t run ‘enterprise’ rubbish like Skype or those of us that are sick of JavaScript heavy SaaS apps like slack - but then you’ll have a few managers or project managers that still run Windows likely for excel or out of habit etc... and they have to use Pidgin - which while it works across a lot of IM systems - is very awkward and ugly as anything, so it gives the better protocols a bad name, on Mac there’s Adium which is a pretty decent multi-IM client but has stagnated somewhat. So a clean, easy to use, stable and well performing chat client that supports XMPP/Jabber with MUC and OTR would be an absolute killer.
There is no mention of this supporting XMPP, but I use profanity for XMPP, and love it. The fact that it's a console application may or may not suit your tastes, of course.
Windows Defender detects it as Win32/Lineage password stealer :(
Even without defender activated, the fact that the binary is not signed is triggering windows 10 security. Not an issue for me but you might want to sign the binary to avoid this.
Yes, that's a very important point. I'll update the website to notify the user about the unsigned binary issue.
I can't sign them at this point, but I will apply as soon as possible.
Right now macOS and Windows 10 complain about an unreliable executable (as they should).
I can't sign them at this point, but I will apply as soon as possible.
Right now macOS and Windows 10 complain about an unreliable executable (as they should).
Thanks for reporting! What's Lineage?
Did some research as I was interested.
Win32/Lineage[0] is a bit of malware (or perhaps a characteristic of malware) that steals credentials. It looks like other software has had false-positives for this before (i.e. optipng[1]). You can also submit eul as a false-positive here[2].
[0]: https://www.microsoft.com/en-us/wdsi/threats/malware-encyclo...
[1]: https://github.com/madskristensen/WebEssentials2013/issues/5...
[2]: https://www.microsoft.com/en-us/wdsi/filesubmission
Win32/Lineage[0] is a bit of malware (or perhaps a characteristic of malware) that steals credentials. It looks like other software has had false-positives for this before (i.e. optipng[1]). You can also submit eul as a false-positive here[2].
[0]: https://www.microsoft.com/en-us/wdsi/threats/malware-encyclo...
[1]: https://github.com/madskristensen/WebEssentials2013/issues/5...
[2]: https://www.microsoft.com/en-us/wdsi/filesubmission
Thanks, I think I know what causes it. Will fix asap.
I appreciate all these new clients with some interesting twists, but I would appreciate more if people spent at least a relatively small portion of their time contributing to existing (very good and solid) messengers like Pidgin, instead of re-inventing the wheel. Every now and then, someone hacks a new client, which begs the question about the value of that effort.
How is this different from Franz - http://meetfranz.com or Manageyum - https://manageyum.com/
What technology & frameworks are used to create Eul?
Does Eul support being able to use multiple accounts of Telegram, Gmail, Skype etc?
What technology & frameworks are used to create Eul?
Does Eul support being able to use multiple accounts of Telegram, Gmail, Skype etc?
These are basically browsers with multiple tabs open.
Eul is a native desktop app built in Go. It has all your contacts in one place, it's much faster, and it uses an order of magnitude fewer resources.
Very good question about multiple accounts. Not right now, but it will be implemented very soon. This is going to be another unique advantage.
Eul is a native desktop app built in Go. It has all your contacts in one place, it's much faster, and it uses an order of magnitude fewer resources.
Very good question about multiple accounts. Not right now, but it will be implemented very soon. This is going to be another unique advantage.
What did you use to make the GUI using Go?
I'm drawing it with OpenGL :)
cool!
i wanted to do something like that, di you use something like nanovg o is from scratch?
have you considered doing a small tutorial/blog series, to explain how to do somethign similar or can you raccomend a resource to learning?
i wanted to do something like that, di you use something like nanovg o is from scratch?
have you considered doing a small tutorial/blog series, to explain how to do somethign similar or can you raccomend a resource to learning?
From scratch, I was inspired by gxui.
It's very basic right now (you can't even move a cursor with the mouse).
I will definitely write a couple of posts about this!
It's very basic right now (you can't even move a cursor with the mouse).
I will definitely write a couple of posts about this!
amazing, i always wondered why people don't create more GUI stuff with Go, the performance of Go is pretty nice and a lot of good multi platform desktop apps could be build using it, keep up the good work!
This looks great - the Slack app is a massive PITA because it's so slow. The only thing stopping me junking Franz for this is that Franz has whatsapp (which you probably can't integrate into Eul anyway because it has to be the web client).
WhatsApp is very tricky, but not impossible.
I thought it had to be via WhatsApp web, no?
Well there is https://github.com/tgalal/yowsup/
but i would not recommend using it
but i would not recommend using it
I find this interesting, as I've been toying with similar ideas in head. In particular the messenger / facebook side of things is of great value to me. However implementing and more importantly maintaining support for this protocol seems like something which will require a vast amount of time and work. Could you briefly describe the status of this support and what hurdles there are to overcome. Messenger used to be XMPP right, I remember and miss the time when you could use pidgin to access this particular service!
THANK YOU FOR THIS!
My company uses Slack, and I hate the iOS app, Windows app and the Linux app. It's bloated and slow!
I paid for the Mailbird app, and I'd pay for a fast and efficient Slack app too.
My company uses Slack, and I hate the iOS app, Windows app and the Linux app. It's bloated and slow!
I paid for the Mailbird app, and I'd pay for a fast and efficient Slack app too.
Is this just for IM (as in messages only) or does it also support audio/video calls (at least for Skype)?
Unfortunately right now it's IM only. I'm almost certain it's not possible to implement Skype audio calls, but I'll look into that.
I've been getting frustrated with Slack for a while now, so thank you!
I'm running into some issues on my Linux machine with the login experience - I sent you an email with more details.
I'm running into some issues on my Linux machine with the login experience - I sent you an email with more details.
Thanks for reporting. I haven't received anything from you yet. The e-mail is [email protected]
edit
Ah! I see it now. Went into spam for some reason.
edit
Ah! I see it now. Went into spam for some reason.
Hmm, doesn't seem to log into slack. Linux version, FF as default browser. It takes me into the web app of slack but eul stays empty.
Wow, awesome. Will you add IRC?
I was considering adding IRC but I thought that almost no one uses it these days (sadly!)
Ideally yes, I'd like to implement it. It's a stable protocol that's not going to change, so there's not much cost in maintaining it.
What are you using IRC for?
Ideally yes, I'd like to implement it. It's a stable protocol that's not going to change, so there's not much cost in maintaining it.
What are you using IRC for?
There already exist tons of high quality irc clients, so there's no reason for irc support to be high priority. I see eul's reason to exist to be more to alleviate the weight of having several low quality messaging apps open at the same time.
You are right. On the other hand it would be nice to have all protocols supported in one app, so one day IRC support will definitely be there.
IRC is still very active in certain circles, though relatively few these days. Many open source projects have channels for discussion and support for example.
#blender and related, the freenode community is still very active for real time support for many projects.
I think IRC still could have a great place in the world - decentralised, open, etc. The ui is just very expectant that you already know and understand the ecosystem.
Needing to know user /auth stuff happens by sending private messages to bots, and other insane hacks.
Needing to know user /auth stuff happens by sending private messages to bots, and other insane hacks.
Not OP but I use IRC daily in channels like #nodejs and #elixir to get help and help others.
I use irc pls add
[deleted]
I'm wondering, what library do you use for skype ?
Would it be possible for you to upload this to the AUR?
Any chance to make it work on OSX 10.11?
How can I be 100% sure of security?
I am most likely going to open source it, so you will be able to build your own version and control everything.
For now I guess you can only monitor the traffic with a tool like WireShark and see for yourself that eul only fetches current version for the autoupdates and submits error reports.
For now I guess you can only monitor the traffic with a tool like WireShark and see for yourself that eul only fetches current version for the autoupdates and submits error reports.
Slack, Skype and Gmail? What else?
VK, FB, Jabber, Telegram, and Signal.
After that Viber and Discord most likely.
After that Viber and Discord most likely.
... and Mattermost, please? :)
Mattermost is the open source Slack alternative, right? I haven't considered these smaller projects yet, because there are a lot of them. Implementing new protocols takes time.
There are still a lot of crucial features I need to implement, but after eul is out of beta, Mattermost support should be there.
There are still a lot of crucial features I need to implement, but after eul is out of beta, Mattermost support should be there.
I understand it's early in the project and you are still nailing things down, but please consider open sourcing your project. Not being able to support things like smaller protocols (Spark, MS Teams, etc.) and legacy platforms (IRC) go away when others have the ability to contribute. Don't get me wrong, nothing comes for free and managing contributors is often times very difficult. Regardless, I think it's worth it. Plus, being able to see the source and build it ourselves is very important for this type of security sensitive project.
Thank you for your effort and I'm looking forward to using Eul quite a bit in the future. :)
Thank you for your effort and I'm looking forward to using Eul quite a bit in the future. :)
[deleted]
This is pretty stupid. Dev machines come with at least 8 gb or ram, why would anyone run a closed source software to save a hundred megabytes and risk compromising their machine. Meanwhile the account is 1 day old and the exe is being flagged by antiviruses.
Security concerns with this particular project aside, my dev machine does indeed have 8 GB of RAM, which Slack alone readily consumes 1/8th of whilst also using 15% of my total CPU power at rest, doing nothing at all.
There is no excuse for this - it is shoddy engineering. Sending text messages is a simple task. Ruining my battery life and performance for the sake of making it easier for the billion dollar company to ship a cross platform app which feels wrong on every platform is something I despise and I for one am extremely happy that people are trying to counter this ridiculous trend.
There is no excuse for this - it is shoddy engineering. Sending text messages is a simple task. Ruining my battery life and performance for the sake of making it easier for the billion dollar company to ship a cross platform app which feels wrong on every platform is something I despise and I for one am extremely happy that people are trying to counter this ridiculous trend.
I'm saying this as a past user of slack and knowing that this doesn't help, but if they can't keep their frontend solid we can probably surmise their backend is just as shoddy, so we shouldn't be using it, no matter what client we choose to use.
If only I could convince my company of that!!
What a ridiculous comment.. I can assure you that the majority of the developers do not own a 8GB dev machine, and surely you can see why this application would be valuable for the average user chatting with their friends on Skype/whatever on their 2GB, i3 laptop (assuming they're lucky enough to be able to afford such a device).
I have browsed Show HN every day for over a year now, and I can't think of any project that made me as excited as this (although https://github.com/google/xi-editor and https://github.com/limetext come close). I bet that almost every Go developer on HN would love to read, study and learn from his code, so how about we ask him nicely instead of attempting to attack his credibility in hope of pressuring him into releasing his source code..
I have browsed Show HN every day for over a year now, and I can't think of any project that made me as excited as this (although https://github.com/google/xi-editor and https://github.com/limetext come close). I bet that almost every Go developer on HN would love to read, study and learn from his code, so how about we ask him nicely instead of attempting to attack his credibility in hope of pressuring him into releasing his source code..
> attack his credibility
His credibility is already at 0, because he's an anon.
> in hope of pressuring him into releasing his source code..
Not my hope, I don't even install official slack client because I don't trust it to be built by competent people (it's web app for me tyvm), my hope is that everybody who installed this software formats their hard drives for the sake of other people if not for themselves. How do you think things like this http://www.nbcnews.com/id/15316394/ happen?
EDIT:
> I can assure you
How? In a cursory attempt I couldn't find any meaningful statistics, but that wasn't my impression when reading topics like this https://news.ycombinator.com/item?id=13038114.
Also, 5 hour old account. Weird. Don't install warez people.
His credibility is already at 0, because he's an anon.
> in hope of pressuring him into releasing his source code..
Not my hope, I don't even install official slack client because I don't trust it to be built by competent people (it's web app for me tyvm), my hope is that everybody who installed this software formats their hard drives for the sake of other people if not for themselves. How do you think things like this http://www.nbcnews.com/id/15316394/ happen?
EDIT:
> I can assure you
How? In a cursory attempt I couldn't find any meaningful statistics, but that wasn't my impression when reading topics like this https://news.ycombinator.com/item?id=13038114.
Also, 5 hour old account. Weird. Don't install warez people.
are there mac binaries for xi and lime text editors
With you here. I don't really care how much ram something uses as long as it's fast. Biggest problem I have are all these "native" apps just being electron wrappers. I miss the old days of real chat apps. Unfortunately they've all gone to hell - looking at you trillian.
I think RAM usage is important. My machine only has 8 GB of RAM, and I had to quit Telegram (1.1 GB) and Skype (550 MB) every time I launched a virtual machine to compile eul for other platforms :)
Because some people want to do more than keep a couple chat windows open at once? Anyways, which antivirus is flagging this?
Someone is this thread mentioned windows defender and I checked with virustotal where there are some others as well. These might all be false positives, even then it still seems wrong to run a random executable from some anon from the internet.
It absolutely is!
I'm going to work on signing the executables for all platforms.
I'm going to work on signing the executables for all platforms.
Here's why I don't use Tox, the executable are provided by a bunch of anons and while I could compile the code myself I'm not really bothered, especially because I can't force everybody to do the same. I like my software to have some collateral, usually it's either someone's good name or their company. On the other hand, I can't find anything about you, your records show you live at Pobedi (victory) 112, 84, Moscow. Really?!
Thanks for pointing that out, I need to update whois data. I'm using an 8 year old throwaway name registrar account, because my primary registrar doesn't support .im domains.
I should get the code signing certificate by the end of the next week.
I should get the code signing certificate by the end of the next week.
eul is a very lightweight and fast native desktop client for Skype, Slack, Gmail, VK, FB, Jabber, Telegram, and Signal. Right now only the first four are supported, and the rest should be done by the end of August.
Why did I create this? To solve two big problems I see with the current IM solutions: there are too many of them, and the clients are ridiculously bloated for what they are built to do. For example, everyone knows what a huge resource hog the Skype client is. Even the Telegram client, which is supposed to be lightweight, is using 1.3 GB of RAM on my desktop right now.
I'm obsessed with performance. The entire application is about 4 MB, and it's never going to be more than 10 MB. In fact there are still many things to optimize. It's native, so you don't need to download a 100 MB browser just to use your IM client.
eul can display thousands of messages in one conversation without the constant page fetching. The scrolling is instant and smooth. You can jump to any message without waiting. I've tested it with 50 000 messages in one chat. No lags, instant scrolling to any point, instant search. That should be enough for most :)
This is a very early alpha release. A lot of essential features are still missing (for example, images and other attachments are not supported yet). Automatic updates will be released every day. There's a built in contact form, please use it to submit bugs and suggestions.
Looking forward to hearing your feedback :)
Thanks