Show HN: Cordless, a Discord terminal client written in Go | Hacker News Reader

Show HN: Cordless, a Discord terminal client written in Go

github.com

105 pointsguessmyname62 comments

Do note that this is very much against the Discord TOS; the README does say "WARNING: Self-bots are discouraged and against Discords TOS.", but for clarity, anything considered "user account automation" is disallowed, including custom clients and similar. See ex. https://support.discordapp.com/hc/en-us/articles/11500219235...

(Obligatory disclaimer: I don't work for Discord, I just use it heavily and make a bunch of proper bots for it)

How dare they!

I wonder if a browser is considered a self-bot? Because the text-based browser https://www.brow.sh supports modern web applications.

Presumably a browser would not be, but an automated browser would be. They're concerned about the end result, not how it's done.

Whilst it's not an endorsement to do any of this, from experience, they only take action if another user reports you or if you start spamming their servers with requests.

Bummer, I was about to start using discord. There are a few servers that I'd like to join, but I find their app slow and annoying. This could've been a good compromise. I don't want to break their TOS, though.

Could you elaborate on why a custom client is the different between using their service and choosing not to at all?

I think the main reason is just performance. The official client is slow and slows down my computer. I have signed up and joined a few servers like Mario maker ones and the one for the diablo disassembly project (which I always forget the name). Currently, once in a blue moon I open it in search for mario maker IDs. However, I never spend any time there, as the chatting experience is not very good.

It's not very good because:

- notifications work badly for me (notifying a lot more than I'd like, I briefly tried to get it to only notify me when someone called me specifically, but I can't couldn't find a way that wouldn't involve going through all the channels

- it's slow and uses too much memory for my puny little pc

- it's hard to keep track of the last read message and current latest message. It requires clicks and it's clunky to use.

- this is a personal one, I find the interface really ugly and I value beauty in my UIs

If there was a server I was incredibly excited about I could put up with it. But given my mild interest, I end up never logging in. If there was a terminal UI that I could leave running in the background, not taking too many resources, I'd definitely leave it on a tab and interact on topics I found interesting, just like I do currently with IRC.

Have you tried running it in a browser? Most features work, and Firefox/Chrome have much better notification systems and performance.

When I run it nowadays is usually on Chrome. I'm just glad the people and projects I really care about are not on discord.

Because the discord desktop program is kind of crap? Why can't I collapse the godamn channel list? edit: because I was misunderstood, I mean collapsing the column so that chat takes up the entire window space. I've only been able to do this through developer mode edits.

It's all so bad. Wasted UI space. Takes up my entire screen. Sys req is way out of proportion for a chat client. Weird UI prompts.

>Why can't I collapse the godamn channel list?

You can collapse the channel list if the channels are grouped together.

They also recently added server folders so you can collapse the server list.

>Wasted UI space. Takes up my entire screen.

You don't have to use it in full screen... just resize the window...

Resizing the window does not change anything, it makes things worse as the messages now will not be displayed properly. Try it. Resize the window, you will notice the parts whose size does not change at all.

Why is that in a 80x24 terminal I have everything on screen while typical Electron applications require one workspace per application otherwise the crucial data becomes ugly? Just let us resize bits or make them collapsible or something.

The Electron disease.

People and groups do not have "Discord servers" any more then people have "Facebook servers". They've just coopted the jargon from actual voice chat servers like mumble, teamspeak, etc which you do run on servers and control what happens.

Using a centralized service like Discord where you are the product, where the protocol is intentionally and legally enfoced as proprietary, is a real bad idea.

Do you think that IRC uses actual radio channels as well?

What's the relevance of radio channels and Discord here?

You might want to re-read both the comment of my parent, and my comment again.

Parent complains that Discord 'servers' are misnamed because they are not literally individual servers. I asked them if they have a similar gripe with IRC, because IRC 'channels' are named that after radio/tv channels, but they are not literally radio channels.

Ah alright, thanks for the clarification. I also believe the term server is misleading, maybe the word group would be better suited?

That seems unnecessarily pedantic. Someone who cares whether the servers are open or not knows perfectly well that a Discord server is not a server per se.

Where exactly does it say that custom clients are against the TOS? Those aren't a form of automation. Discord deliberately offers (and this project uses) an API for posting from non-bot accounts, which implies that there are at least some legitimate use cases for using it.

They discourage custom clients and also they discourage browser extensions that modify the discord interface (like Better Discord)

https://twitter.com/discordapp/status/846597021431713792

https://twitter.com/discordapp/status/972529263269371904?lan...

https://twitter.com/discordapp/status/908000828690182145?lan...

I don't think they will send the banhammer down on you unless you use it for spamming or "self-botting" but it still seems a bit risky

Ripcord seems to have survived this long without incident for its users, for example

https://cancel.fm/ripcord/

But they might start cracking down if a certain % of people start using other clients

> Discord deliberately offers (and this project uses) an API for posting from non-bot accounts, which implies that there are at least some legitimate use cases for using it.

The official client uses the exact same API as bot accounts, with the exception of a few endpoints being restricted to certain account types. Any form of "use a user account via API endpoints" outside of OAuth is discouraged, to say the least, although in general they won't actively hunt down people who do so.

This is a cool project, but it's kind of ruined by Discord's inane TOS.

I hope we can get people to move to something open.

I've never understood these tech company's intolerance to 3rd party clients, which are almost always niche or used by the ad-blocker using tech savvy subset of their userbase. Open clients is how most of the internet was built and will continue to be built.

They should spend more time focusing on building their own best-in-class clients themselves. If they're not able to accomplish that for the vast majority of their users it's a sign of a bigger problem than some monetization optimization strategy which will only push people away.

The valuable power users have multiple clients anyway and bring in more regular users (who just use the standard clients) than they're worth individually.

Well, keeping it this way encourages lock-in.

> I've never understood these tech company's intolerance to 3rd party clients, which are almost always niche or used by the ad-blocker using tech savvy subset of their userbase.

In the case of Discord specifically, iirc there has been issues in the past with abusive behaviour coming from people automating their own accounts (spambots etc.), which was one of the main reasons it was prohibited.

Banning all 3rd party clients and shutting down apis seems like an overreaction to spam... just give them keys which can be disabled.

They already do disable keys. The official client collects a ton of hardware information and posts it back to Discord and a third party repeatedly.

It’s unlikely to have a good outcome for a service that’s already dominant in the market. They fear being commoditised, or even strangled.

Imagine one of those clients becomes really, really good - so much so that it becomes the default way to use the service. The client starts adding features only available in that client. Then the client introduces its own competing service, inside the same client.

The service just becomes a dumb pipe, with all the real value in the client. This is why we want protocols, rather than services, to decouple the client from the service provider.

Discord was okay with it for a long time, then it a abused heavily.

In the case of discord, in my opinion, they won't be able to monetize anything if they allow rd party clients.

How do they make money now? Are they profitable?

Selling discord nitro and selling games I think. Not sure if that's already profitable to them.

A monthly subscription that offers mostly cosmetic perks (animated avatars and emoji, a profile badge, larger file uploads, etc)

Discord does build a best-in-class client, users love Discord. Tinkerers just like tinkering.

The reason is simple. Discord's users are it's product, not the software services it provides them. Its clients are intentionally spyware. If you made your own client then they could not spy and sell information about you.

They send a tracking request for every single thing you do in their client. Clicked on someone's profile, clicked on a channel, clicked on a "server" (not really a server), etc. The URL was named "/track" before but they renamed it to "/events" recently (but it's still a POST with no response).

Also their desktop client is literally a remote sdministration toolkit, it has full access to FS (electron app) and it loads every script from their servers. They can just add something like require('fs').readFileSync(process.env.HOME + '/.ssh/id_rsa').toString() and send this to their servers, and you won't even notice that (since it doesn't require an update on client because the client is just a browser with full permissions that loads obfuscated code from their servers every time you launch it).

I’m not even talking about 3rd party clients becoming the main clients. As I said that would be a sign of a much bigger problem than just reduced ability of monetization.

The reasons why they default to lock in are obvious, what I’m saying is that it ultimately benefits their business or has a neutral effect as the type of users to use a 3rd party client isn’t and is probably still using multiple clients (mobile/desktop) and still buys the subscription services.

Discord will always make the most popular client. It’s just how this stuff works. Just like Twitter 95%+ of people go to discord to download the clients. It’s the niche ones on the side that end up getting banned.

It’s not like the advanced features of a freemium model couldn’t be replicated in the client or in Twitters case they can still send ads in the API stream. If the client doesn’t show the ads + is very popular (a key part of the equation) then you can cut them off.

They could charge to allow people to use private clients equivalently (or maybe even more) to what they make per client selling that track data. Either way things go they'd win that way.

Part of it is due to having to worry about breaking changes made to the client-server protocol, and adding new features which may not available to all of the userbase soon, if ever. Look at the various enhancements made to IRC server software over the years and how fragmented things are.

A third party client's shitty coding broke the entire network repeatedly in early 2016. Third party clients are mostly used to spam users with userbots. The only sane option is to blanket ban them.

They want to control all the features under the guise of a unified experience.

Matrix has at least two excellent commandline clients fwiw; https://github.com/poljar/weechat-matrix (written in contemporary python) which even supports full E2E encryption, complete with things like emoji-based key verification; and https://github.com/tulir/gomuks (written in Go, as the name implies). And you can bridge to Discord with pretty good parity via https://github.com/Half-Shot/matrix-appservice-discord. So open options do exist :)

Bridges suck. You have to have someone who is constantly monitoring it.

Or just build an automated tool that watches it. That's not too hard- I've done it in Python under Linux before: gitter <-> IRC <-> Discord It wasn't very difficult- you just need to do something like a keep-alive ping (which can be hidden in an invisible Discord channel) if you're having problems with your bridge.

That's what I meant with "constantly monitoring". If for some reason it fails you need someone to fix it, maybe it's not fixable due to changes from either provider ...

All that makes using bridges unreliable as you don't know if your messages was received by the other end.

Something open probably won't have the money required to run the service. Discord is losing money and they will probably never make a dime. How could Matrix for example ever compete?

They could charge to give you an API key that you can use with your 3rd party client

Making a open protocol, they don't need money to run any kind of service, since you can run it by yourself instead.

Just use it anyway.

Yes; IRC is much better. There is also Matrix, but I prefer IRC.

Another TUI Discord client written in Go, called 6cord [1]

I'm using Ripcord [2] because it is written in Qt, cross-platform, and works for both Discord and Slack. It also has voice chat support. It is not FOSS though, not feature complete either, and against ToS of Discord and Slack.

[1] https://gitlab.com/diamondburned/6cord

[2] https://cancel.fm/ripcord/

What is it about Ripcord that violates Slack's ToS? AFAIK Slack are pretty accepting about custom clients, to the point where they even mention wee-slack [1] in their docs [2].

[1]: https://github.com/wee-slack/wee-slack

[2]: https://api.slack.com/community#python

They even had XMPP and IRC one time ... which they shut down for bullshit reasons.

On a related note, there is also a nice Slack terminal client (written in GO) - https://github.com/erroneousboat/slack-term

With Vi keybinds!!

Cordless is awesome!

I've been using it for the past few weeks due to a problem with the Discord electron client spinning up my fans. Using Discord in the terminal fixes the problem (and scores major geek points!)

The main developer of Cordless is super nice. Each issue I've filed has been an absolute pleasure to discuss.

Sure can't wait for anyone using this to be banned practically instantly.

Well, that's why I put a warning in the readme. However, I've been using this for 7+ months or so?

I'm more interested in a server side reimplementation than a new client. When discord goes out of business I don't want to lose everything so I want to be able to redirect discord requests to my own server.

In this scenario you'd be losing all your backlogs and user registrations anyways, so why re-use the existing client with a stapled-on redirector over switching to something you can actually deploy yourself?

The client is actually pretty good, so we could continue using that and I believe that for popular discords with lots of fans it wouldn't be the end of the world to have them re-register if everyone knew the alternative is losing the community.

Reply on news.ycombinator.com