Dissent – A GTK4 Discord client written in Go(github.com)
github.com
Dissent – A GTK4 Discord client written in Go
https://github.com/diamondburned/dissent
87 comments
Warning: alternative Discord clients will get you banned. I got my account permanently banned for no other reason other than using a 3rd party client, even though it (Ripcord) had insanely better UX.
Its so sad, that Discord is too small that the DMA kicks in and they would be forced to allow third party software.
This is a community of Tech enthusiasts and yet, so many entertain this party of leopards eating people's faces by accepting anything less than open federated/P2P protocols.
And so far, the DMA has only served to show malicious compliance on the side of Facebook. Nothing to better the lives of those who reject the walled gardens.
And so far, the DMA has only served to show malicious compliance on the side of Facebook. Nothing to better the lives of those who reject the walled gardens.
I don't want to speculate why this is the case, but tech enthusiasts rarely have the social capital that it takes to move friend groups or local forums over to specific platforms.
The sad reality is that we can either accept the monopolizing forces like everyone else, or make ourselves apart from important social contexts.
The sad reality is that we can either accept the monopolizing forces like everyone else, or make ourselves apart from important social contexts.
I like to use Mumble https://www.mumble.info/ for voice chat while gaming. It's really effective at voice chat and runs on a toaster. The server was really easy to set up on my raspberry pi. Is there another software that might be helpful that you can think of? Free software would be preferable
[deleted]
> This is a community of Tech enthusiasts
Eh no, I’d say it’s precisely the subset of tech enthusiasts who aspire to work for a profitable company like discord, or even build one. There are a few of us here who reject corporate tech, but i don’t think it’s the majority.
Eh no, I’d say it’s precisely the subset of tech enthusiasts who aspire to work for a profitable company like discord, or even build one. There are a few of us here who reject corporate tech, but i don’t think it’s the majority.
They also do very, very little in terms of personal data protection.
Which is often related - there's no way to batch delete your data, trying to do so with third-party tooling could get you banned, and once you're banned you can't delete it. In fact, you can't even delete messages from channels that an ordinary user has kicked you out of. And IIRC banned accounts still have unique public identifiers, so any PII can still be correlated (as opposed to the [deleted] pseudononymization that Reddit does)
I used cordless exclusively. I too got my main account banned as part of the initial round where they did this.
When was that? It's a shame that they seem to have changed positions in the past few years
https://news.ycombinator.com/item?id=28438440
https://news.ycombinator.com/item?id=28438440
Early 2021, as shortly after the dev shut down cordless.
I don't think they've actually reversed position at all. I think the bottom line is they don't like anything that isn't their client because they can't pump nitro at you.
And considering part of their TOS is basically they can do whatever they want, I don't know why people would even risk it anymore.
I don't think they've actually reversed position at all. I think the bottom line is they don't like anything that isn't their client because they can't pump nitro at you.
And considering part of their TOS is basically they can do whatever they want, I don't know why people would even risk it anymore.
This would be very useful if it wasn't for Discord:
> Note: Using an unofficial client at all is against Discord's Terms of Service and may cause your account to be banned! Use at your own risk!
> Note: Using an unofficial client at all is against Discord's Terms of Service and may cause your account to be banned! Use at your own risk!
I know that we all work on what we want to work on for reasons even we do not understand sometimes, but I do wish people motivated to work on projects like this would dedicate that time elsewhere, somewhere they are wanted. Why not make a great Matrix client or improve that ecosystem somehow otherwise? Why make a Discord client when Discord literally does not want you to?
> somewhere they are wanted.
While Discord might officially not allow it, a lot of folks do want the option of using different clients. There are a few out there and generally speaking it does like discord doesn't crack down on it unless they see odd api usage. *DISCLAIMER:* Still very much use at your own risk. I am not responsible for banned accounts.
> Why not make a great Matrix client or improve that ecosystem somehow otherwise?
Likely for the same reason there are still relatively few feature complete matrix clients out there. Don't get me wrong, there are a ton of clients out there with some functionality. But few that support all functionality. For the longest time it was just Element.
A large reason for that has to do with how complex the Matrix protocol is to deal with. To be fair, the discord API also has become a hot mess with all the features tagged on over the years. But the basic API for just chat is fairly straightforward. Not to mention that there are multiple wrapper libraries for various languages out there that make things even easier.
Also, people work on projects they benefit from themselves. Or at least the ones they are motivated to do. If someone isn't on Matrix why should they invest the time and effort to get effectively nothing in return?
While Discord might officially not allow it, a lot of folks do want the option of using different clients. There are a few out there and generally speaking it does like discord doesn't crack down on it unless they see odd api usage. *DISCLAIMER:* Still very much use at your own risk. I am not responsible for banned accounts.
> Why not make a great Matrix client or improve that ecosystem somehow otherwise?
Likely for the same reason there are still relatively few feature complete matrix clients out there. Don't get me wrong, there are a ton of clients out there with some functionality. But few that support all functionality. For the longest time it was just Element.
A large reason for that has to do with how complex the Matrix protocol is to deal with. To be fair, the discord API also has become a hot mess with all the features tagged on over the years. But the basic API for just chat is fairly straightforward. Not to mention that there are multiple wrapper libraries for various languages out there that make things even easier.
Also, people work on projects they benefit from themselves. Or at least the ones they are motivated to do. If someone isn't on Matrix why should they invest the time and effort to get effectively nothing in return?
What's complex about the Matrix Protocol?
Hi, developer here! I have worked on a Matrix client before (diamondburned/gotktrix)! I abandoned it because I couldn't be bothered to handle E2EE or rewrite it in a different Matrix library, but Fractal is also fairly stable now and it scratches the same itch, so I didn't see a point.
Everyone says "Discord bad" (and I agree, it has issues) but few bother to understand and learn about what makes it successful and makes people use it (even in spite of its badness).
Alternatives bring in their own set of issues and generally focus on technicalities rather than delivering a good Discord/etc competitor, so nobody uses them.
Do you want to chat with people or do you want to waste time dealing with protocol fragmentation, half-baked clients (or no clients at all), fundamental protocol-level flaws (that can't be fixed without effectively starting from scratch on a new protocol), etc? Most people pick the first option and then tolerate the badness of Discord as a necessary evil.
Alternatives bring in their own set of issues and generally focus on technicalities rather than delivering a good Discord/etc competitor, so nobody uses them.
Do you want to chat with people or do you want to waste time dealing with protocol fragmentation, half-baked clients (or no clients at all), fundamental protocol-level flaws (that can't be fixed without effectively starting from scratch on a new protocol), etc? Most people pick the first option and then tolerate the badness of Discord as a necessary evil.
> Why not make a great Matrix client or improve that ecosystem somehow otherwise?
From my dabbling, I would say Discord's API is a lot easier and better documented. Matrix has a billion different standards, a complex message format, and encryption to deal with. There are libraries, but they're not easy to use, sometimes incomplete, and are rarely documented beyond "this is how you send a ping bot".
Also, people actually use Discord a lot. Matrix is big, but not Discord big. In practice, Discord rarely ever bans anyone for using alternative clients either.
I don't like the way Discord is now the standard for communities, but I'm not too surprised about it either. At least open source projects seem to use Matrix, but I wouldn't recommend it to my gaming buddies because of how odd the clients generally are.
From my dabbling, I would say Discord's API is a lot easier and better documented. Matrix has a billion different standards, a complex message format, and encryption to deal with. There are libraries, but they're not easy to use, sometimes incomplete, and are rarely documented beyond "this is how you send a ping bot".
Also, people actually use Discord a lot. Matrix is big, but not Discord big. In practice, Discord rarely ever bans anyone for using alternative clients either.
I don't like the way Discord is now the standard for communities, but I'm not too surprised about it either. At least open source projects seem to use Matrix, but I wouldn't recommend it to my gaming buddies because of how odd the clients generally are.
> Matrix has a billion different standards
There is one specification, available on the official site. It isn't, and never will be, required to implement all of it.
> a complex message format
It is a very simple format. Here's an example message (as sent by a client; additional fields are added by the server, such as server-side timestamp):
This is also optional. If you want to talk in unencrypted public rooms, for example, you needn't bother with it.
The spec is so simple that you can send a Matrix message from a shell with curl. It's just JSON over HTTP.
There is one specification, available on the official site. It isn't, and never will be, required to implement all of it.
> a complex message format
It is a very simple format. Here's an example message (as sent by a client; additional fields are added by the server, such as server-side timestamp):
{
"content": {
"body": "Hello, world.",
"msgtype": "m.text"
},
"type": "m.room.message",
}
This is also optional. If you want to talk in unencrypted public rooms, for example, you needn't bother with it.
The spec is so simple that you can send a Matrix message from a shell with curl. It's just JSON over HTTP.
With all due respect but
> This is also optional.
If you are making a client for anyone besides yourself at some point people will expect to be able to use one of the many "optional" features. At that point it doesn't matter if you technically don't need to support it as users will then simply see it as a shortcoming of your client.
So if we are talking about anything more than a MVP client these optional specs should be included in the argument as only being optional in theory.
> This is also optional.
If you are making a client for anyone besides yourself at some point people will expect to be able to use one of the many "optional" features. At that point it doesn't matter if you technically don't need to support it as users will then simply see it as a shortcoming of your client.
So if we are talking about anything more than a MVP client these optional specs should be included in the argument as only being optional in theory.
The official spec is a combination of hundreds of tiny specs and extensions, akin to XMPP. There may be one single reference, but it's constantly evolving.
> It is a very simple format.
In a best case scenario, sure. The Discord version of your example would just be "Hello, world" without any of the other JSON.
In practice, you need to deal with a whole range of message types with various references and slight variations. Inner Matrix message bodies are essentially freeform, which makes Matrix quite powerful but also difficult to deal with compared to the "different HTTP endpoint per request type" approach Discord takes.
> This is also optional. If you want to talk in unencrypted public rooms, for example, you needn't bother with it.
Sure, if you accept having your users install two different apps, one for encrypted chat and one for group chats.
> It is a very simple format.
In a best case scenario, sure. The Discord version of your example would just be "Hello, world" without any of the other JSON.
In practice, you need to deal with a whole range of message types with various references and slight variations. Inner Matrix message bodies are essentially freeform, which makes Matrix quite powerful but also difficult to deal with compared to the "different HTTP endpoint per request type" approach Discord takes.
> This is also optional. If you want to talk in unencrypted public rooms, for example, you needn't bother with it.
Sure, if you accept having your users install two different apps, one for encrypted chat and one for group chats.
> The official spec is a combination of hundreds of tiny specs and extensions, akin to XMPP.
You could say the same thing about any specification that involved multiple features.
> There may be one single reference, but it's constantly evolving.
So is HTML. But one of my Matrix clients from 7 years ago still works. How well would a 7-year-old Web browser work on today's Web? Could you use a 7-year-old version of a third-party Discord client?
> In a best case scenario, sure. The Discord version of your example would just be "Hello, world" without any of the other JSON.
So Discord encodes the message type in the URL instead of the body. So what? It has to go somewhere, and I'd generally rather have URLs include less, not more.
I actually messed up earlier: The `type` field is included in the event as seen after sending. The sent event could just be, e.g.
> In practice, you need to deal with a whole range of message types with various references and slight variations.
Is the same not true for Discord? It supports a variety of message types as well, and Discord also constantly evolves the system and adds new features (every time I log on to it I'm bombarded with news of updates, yet I still can't find a way to view a simple list of "servers" I'm in by names instead of by unintelligible icons).
> In practice, you need to deal with a whole range of message types with various references and slight variations. Inner Matrix message bodies are essentially freeform, which makes Matrix quite powerful but also difficult to deal with compared to the "different HTTP endpoint per request type" approach Discord takes.
That seems to conflate two issues. And I don't see how it's more difficult to deal with than any key-value store in any program. You collect the values from the keys you care about. That's it. Every Matrix event has certain basic fields in common. A few are specific for message type (e.g. a filename field for a file or image upload event). Where's the problem? Destructuring incoming data is probably the easiest part of writing a messaging client.
> Sure, if you accept having your users install two different apps, one for encrypted chat and one for group chats.
I use unencrypted 1:1 chats as well (in which case it's no worse than IRC or Discord, where the server operator could read your messages).
I think that's pretty cool, frankly: that a modern system with well-audited end-to-end encryption still allows it to be used optionally. You're not required to deal with the complexity of key management and session verification if you don't need or want it. Matrix lets me choose.
And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
The only significant appeal I see for Discord is the existing user base. Well, that didn't save AOL. I guess we'll see how it turns out.
You could say the same thing about any specification that involved multiple features.
> There may be one single reference, but it's constantly evolving.
So is HTML. But one of my Matrix clients from 7 years ago still works. How well would a 7-year-old Web browser work on today's Web? Could you use a 7-year-old version of a third-party Discord client?
> In a best case scenario, sure. The Discord version of your example would just be "Hello, world" without any of the other JSON.
So Discord encodes the message type in the URL instead of the body. So what? It has to go somewhere, and I'd generally rather have URLs include less, not more.
I actually messed up earlier: The `type` field is included in the event as seen after sending. The sent event could just be, e.g.
{
"content": {
"body": "Hello, world.",
"msgtype": "m.text"
}
}
> In practice, you need to deal with a whole range of message types with various references and slight variations.
Is the same not true for Discord? It supports a variety of message types as well, and Discord also constantly evolves the system and adds new features (every time I log on to it I'm bombarded with news of updates, yet I still can't find a way to view a simple list of "servers" I'm in by names instead of by unintelligible icons).
> In practice, you need to deal with a whole range of message types with various references and slight variations. Inner Matrix message bodies are essentially freeform, which makes Matrix quite powerful but also difficult to deal with compared to the "different HTTP endpoint per request type" approach Discord takes.
That seems to conflate two issues. And I don't see how it's more difficult to deal with than any key-value store in any program. You collect the values from the keys you care about. That's it. Every Matrix event has certain basic fields in common. A few are specific for message type (e.g. a filename field for a file or image upload event). Where's the problem? Destructuring incoming data is probably the easiest part of writing a messaging client.
> Sure, if you accept having your users install two different apps, one for encrypted chat and one for group chats.
I use unencrypted 1:1 chats as well (in which case it's no worse than IRC or Discord, where the server operator could read your messages).
I think that's pretty cool, frankly: that a modern system with well-audited end-to-end encryption still allows it to be used optionally. You're not required to deal with the complexity of key management and session verification if you don't need or want it. Matrix lets me choose.
And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
The only significant appeal I see for Discord is the existing user base. Well, that didn't save AOL. I guess we'll see how it turns out.
> You could say the same thing about any specification that involved multiple features.
You could, which is why I find APIs like Discord's easier to program for.
> So is HTML.
Web dev had a certain reputation, partially because of that.
> Is the same not true for Discord?
Discord sure has a bunch of weird format options, but the core messaging API hasn't changed significantly in years as far as I can tell. You have text messages, sometimes with attachments, and that's about it. Even the base structure of usernames changing has been backwards compatible without API changes.
> Destructuring incoming data is probably the easiest part of writing a messaging client.
That depends on the structure of the data, really.
> I use unencrypted 1:1 chats as well
That does make things easier. But I don't. A fancy GTK version of Cinny would he completely useless to me without basic encryption support. I still run into encryption bugs from time to time using multiple types of client.
> And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
So do I! And I can't, obviously. But realistically, who cares? The Venn diagram between "people who want to be able to run their own server" and "people I know who know how to install Arch" is pretty much a single circle.
I want Matrix/XMPP/the Fediverse to succeed, but nobody but technology enthusiasts seems to care about any of this. A chat service I can use to talk to developers and fellow server admins is great in its own right, but it's not a replacement for Discord where the normal people hang out.
From what I can tell, dissent is built in a way that shouldn't make it too hard to convert into a Matrix client. You'll need to fight with Spaces to get the "Discord server" concept across, though. For the people who don't want to use Discord, most of the work is there. All you need is to grab a Matrix library for go (gomatrix died a month ago so you'd need to fork/vendor that I guess?) and rework the data store.
I think my biggest issue with Matrix is mostly the status of most existing libraries. Many of them are outdated, partially cover the stack, and there's not a lot of info on how to use them. Libraries get partially developed, and then abandoned for various reasons. Because of this, it's easier to maintain your own data model code rather than reusing existing work.
Another thing that's rather annoying to work with is the way Matrix deals with things like emoji reactions and state. Everything is one big additive list of messages that needs to be read completely to get a proper view of the room.
Whatever the exact reasons may be, I had an easier experience writing a small Discord client than I had writing a small Matrix client. Perhaps my expectations were simply too high.
You could, which is why I find APIs like Discord's easier to program for.
> So is HTML.
Web dev had a certain reputation, partially because of that.
> Is the same not true for Discord?
Discord sure has a bunch of weird format options, but the core messaging API hasn't changed significantly in years as far as I can tell. You have text messages, sometimes with attachments, and that's about it. Even the base structure of usernames changing has been backwards compatible without API changes.
> Destructuring incoming data is probably the easiest part of writing a messaging client.
That depends on the structure of the data, really.
> I use unencrypted 1:1 chats as well
That does make things easier. But I don't. A fancy GTK version of Cinny would he completely useless to me without basic encryption support. I still run into encryption bugs from time to time using multiple types of client.
> And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
So do I! And I can't, obviously. But realistically, who cares? The Venn diagram between "people who want to be able to run their own server" and "people I know who know how to install Arch" is pretty much a single circle.
I want Matrix/XMPP/the Fediverse to succeed, but nobody but technology enthusiasts seems to care about any of this. A chat service I can use to talk to developers and fellow server admins is great in its own right, but it's not a replacement for Discord where the normal people hang out.
From what I can tell, dissent is built in a way that shouldn't make it too hard to convert into a Matrix client. You'll need to fight with Spaces to get the "Discord server" concept across, though. For the people who don't want to use Discord, most of the work is there. All you need is to grab a Matrix library for go (gomatrix died a month ago so you'd need to fork/vendor that I guess?) and rework the data store.
I think my biggest issue with Matrix is mostly the status of most existing libraries. Many of them are outdated, partially cover the stack, and there's not a lot of info on how to use them. Libraries get partially developed, and then abandoned for various reasons. Because of this, it's easier to maintain your own data model code rather than reusing existing work.
Another thing that's rather annoying to work with is the way Matrix deals with things like emoji reactions and state. Everything is one big additive list of messages that needs to be read completely to get a proper view of the room.
Whatever the exact reasons may be, I had an easier experience writing a small Discord client than I had writing a small Matrix client. Perhaps my expectations were simply too high.
> You could say the same thing about any specification that involved multiple features.
You could, which is why I find APIs like Discord's easier to program for.
> So is HTML.
Web dev had a certain reputation, partially because of that.
> Is the same not true for Discord?
Discord sure has a bunch of weird format options, but the core messaging API hasn't changed significantly in years as far as I can tell. You have text messages, sometimes with attachments, and that's about it. Even the base structure of usernames changing has been backwards compatible without API changes.
> Destructuring incoming data is probably the easiest part of writing a messaging client.
That depends on the structure of the data, really.
> I use unencrypted 1:1 chats as well
That does make things easier. But I don't. A fancy GTK version of Cinny would he completely useless to me without basic encryption support. I still run into encryption bugs from time to time using multiple types of client.
> And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
So do I! And I can't, obviously. But realistically, who cares? The Venn diagram between "people who want to be able to run their own server" and "people I know who know how to install Arch" is pretty much a single circle.
I want Matrix/XMPP/the Fediverse to succeed, but nobody but technology enthusiasts seems to care about any of this. A chat service I can use to talk to developers and fellow server admins is great in its own right, but it's not a replacement for Discord where the normal people hang out.
From what I can tell, dissent is built in a way that shouldn't make it too hard to convert into a Matrix client. You'll need to fight with Spaces to get the "Discord server" concept across, though. For the people who don't want to use Discord, most of the work is there. All you need is to grab a Matrix library for go (gomatrix died a month ago so you'd need to fork/vendor that I guess?) and rework the data store.
I think my biggest issue with Matrix is mostly the status of most existing libraries. Many of them are outdated, partially cover the stack, and there's not a lot of info on how to use them. Libraries get partially developed, and then abandoned for various reasons.
Another thing that's rather annoying to work with is the way Matrix deals with things like emoji reactions and state. Everything is one big additive list of messages that needs to be read completely to get a proper view of the room.
Whatever the exact reasons may be, I had an easier experience writing a small Discord client than I had writing a small Matrix client. Matrix can be as easy as Discord, but only if you don't try to do anything more complex than an IRC client.
You could, which is why I find APIs like Discord's easier to program for.
> So is HTML.
Web dev had a certain reputation, partially because of that.
> Is the same not true for Discord?
Discord sure has a bunch of weird format options, but the core messaging API hasn't changed significantly in years as far as I can tell. You have text messages, sometimes with attachments, and that's about it. Even the base structure of usernames changing has been backwards compatible without API changes.
> Destructuring incoming data is probably the easiest part of writing a messaging client.
That depends on the structure of the data, really.
> I use unencrypted 1:1 chats as well
That does make things easier. But I don't. A fancy GTK version of Cinny would he completely useless to me without basic encryption support. I still run into encryption bugs from time to time using multiple types of client.
> And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?
So do I! And I can't, obviously. But realistically, who cares? The Venn diagram between "people who want to be able to run their own server" and "people I know who know how to install Arch" is pretty much a single circle.
I want Matrix/XMPP/the Fediverse to succeed, but nobody but technology enthusiasts seems to care about any of this. A chat service I can use to talk to developers and fellow server admins is great in its own right, but it's not a replacement for Discord where the normal people hang out.
From what I can tell, dissent is built in a way that shouldn't make it too hard to convert into a Matrix client. You'll need to fight with Spaces to get the "Discord server" concept across, though. For the people who don't want to use Discord, most of the work is there. All you need is to grab a Matrix library for go (gomatrix died a month ago so you'd need to fork/vendor that I guess?) and rework the data store.
I think my biggest issue with Matrix is mostly the status of most existing libraries. Many of them are outdated, partially cover the stack, and there's not a lot of info on how to use them. Libraries get partially developed, and then abandoned for various reasons.
Another thing that's rather annoying to work with is the way Matrix deals with things like emoji reactions and state. Everything is one big additive list of messages that needs to be read completely to get a proper view of the room.
Whatever the exact reasons may be, I had an easier experience writing a small Discord client than I had writing a small Matrix client. Matrix can be as easy as Discord, but only if you don't try to do anything more complex than an IRC client.
[deleted]
>Why make a Discord client when Discord literally does not want you to?
Discord's hostility is irrelevant if you desire to write a client. Kind of like climbing a mountain because it's there; who cares if the mountain will probably kill you.
>I do wish people motivated to work on projects like this would dedicate that time elsewhere, somewhere they are wanted.
If that desire was expressed in the form of compensation, more devs would probably start lining up.
I realize the very concept of compensation is heresy for FOSS, though.
Discord's hostility is irrelevant if you desire to write a client. Kind of like climbing a mountain because it's there; who cares if the mountain will probably kill you.
>I do wish people motivated to work on projects like this would dedicate that time elsewhere, somewhere they are wanted.
If that desire was expressed in the form of compensation, more devs would probably start lining up.
I realize the very concept of compensation is heresy for FOSS, though.
I wholeheartedly agree but working on something you can use is much more fun, and the chances this person uses discord are much higher than of them using matrix
What's a dev to do when their friends are on Discord?
While I agree with the sentiment, there is no lack of Matrix client side-projects.
At the time when yim,icq,msnm had their primetime no company behind it wanted third party clients.
"Why make a Discord client when Discord literally does not want you to?" Why make another X when you could improve Y. Because most of the time if they wouldn't build X they wouldn't improve Y. This is no company that balance human resources.
"Why make a Discord client when Discord literally does not want you to?" Why make another X when you could improve Y. Because most of the time if they wouldn't build X they wouldn't improve Y. This is no company that balance human resources.
nobody cares what discord wants, their client sucks and lots of people want an alternative.
Why are companies like Discord, Slack, Reddit etc. so hellbent on having users stick to their god awful front end clients? You can easily perform all the data harvesting you want on the backend. Just provide some open-source api clients, and let the community build the UIs they want.
Why are users, especially technically-inclined ones, hellbent on using these proprietary services? Throw them all out if they are going to be this way since there are great alternatives. The last thing communities should do is build UIs around these types of services instead of building ones for systems/services that aren’t so hostile towards users.
> Why are users, especially technically-inclined ones, hellbent on using these proprietary services?
Because that's where people are.
Because that's where people are.
> Why do you rob banks?
> Because that’s where the money is
— Willie Sutton, career bank robber, caught 11 times
Perhaps there’s a better solution out there
> Because that’s where the money is
— Willie Sutton, career bank robber, caught 11 times
Perhaps there’s a better solution out there
Analogous to the metaphor you just made, the "better solution" is not talking to people. I'm all-for open and secure communication protocols, but the layman isn't going to agree if you cast it as an all-or-nothing mentality.
You can a) set up a gateway/bridge or b) contribute to those platforms to make them better so users like them more as the open+secure options are more worth the long-term investment into instead of making users choose between privacy/security or having the ability to communicate.
For 99% of normal people, neither A nor B is something they are capable of. If the success of free alternatives is contingent on this behavior, we might as well throw in the towel now.
If the average Discord user read your comment, I think it would reaffirm their assumption that free Discord alternatives aren't for them.
If the average Discord user read your comment, I think it would reaffirm their assumption that free Discord alternatives aren't for them.
Versus myself that would see that there is a security/privacy concern & would immediately see if I can use an alternative.
> since there are great alternatives
No. There aren’t.
No. There aren’t.
Control over premium features. Which in a sense is valid, I rather have a product supported by people paying for premium features than a product that runs on ads or only does exist by the grace of venture capital.
Of course some premium features can be controlled server side, but not all of them.
For example, the extended message limit can quite easily be done by a custom client by splitting up the message. Similar for custom color themes.
Having said all that, in the case of Discord I honestly don't think they need to lock down third party clients for this. As most Nitro features are mostly server side anyway.
Of course some premium features can be controlled server side, but not all of them.
For example, the extended message limit can quite easily be done by a custom client by splitting up the message. Similar for custom color themes.
Having said all that, in the case of Discord I honestly don't think they need to lock down third party clients for this. As most Nitro features are mostly server side anyway.
They have it in their hands to display inbound advertisment?
Because they want complete control over your experience.
It tarnishes their grand 'vision' for the user experience.
i suppose because of engagement metrics
Apparently, the developers of Dissent have never read Discord's Terms of Service, because it doesn't even mention third-party clients.
I'm actually fully aware of this! Discord's ToS just says they can ban you for any reason, and it also touches on API abuse. A lot of past Discord clients (e.g. cordless) don't try to minimize API calls (especially some sensitive ones), and some of that counted towards API abuse.
Dissent tries to minimize API calls by requesting information over the Gateway Websocket and caching them instead. This is actually what the official client does!
It's just way easier to say that it violates the ToS instead of explaining the whole deal, though. You might still get banned, use it at your own risk.
Dissent tries to minimize API calls by requesting information over the Gateway Websocket and caching them instead. This is actually what the official client does!
It's just way easier to say that it violates the ToS instead of explaining the whole deal, though. You might still get banned, use it at your own risk.
After a quick look at their ToS I too do not see a clear mention.
In a previous HN discussion from September 2021:
> [zorkian] It's still against the TOS -- my point is only that we don't specifically look for third party client users and we have no specific plans to do so.
[Note zorkian’s HN profile: “VP, Core Tech @ Discord. Opinions are my own and I do not speak for my employer (unless noted explicitly.)”]
> [tumult] Just curious -- where in the TOS are third party clients forbidden? I've read it a few times, and I'm not seeing it.
> [dge2020] Probably:
> You agree not to (and not to attempt to) (i) use the Service for any use or purpose other than as expressly permitted by these Terms;(ii) copy, adapt, modify, prepare derivative works based upon, distribute, license, sell, transfer, publicly display, publicly perform, transmit, stream, broadcast, attempt to discover any source code, reverse engineer, decompile, disassemble, or otherwise exploit the Service or any portion of the Service, except as expressly permitted in these Terms;
> It's a catch-all but the best restriction that prevents third-party clients is probably 'prepare derivative works based on' and 'reverse engineer' (which you would need if you want your third party client to use any regular client API calls, or if you want to support signing in with the user-facing login page/qr login).
> [tumult] A third party client like Ripcord isn't a derivative work. It also wasn't made by reverse engineering any of Discord's code. Even if it were, these rules still wouldn't apply to using third party clients.
So it seems that, as you note, the ToS do not explicitly mention third-party clients but Discord themselves believe that it forbids third-party clients.
https://news.ycombinator.com/item?id=28435490
In a previous HN discussion from September 2021:
> [zorkian] It's still against the TOS -- my point is only that we don't specifically look for third party client users and we have no specific plans to do so.
[Note zorkian’s HN profile: “VP, Core Tech @ Discord. Opinions are my own and I do not speak for my employer (unless noted explicitly.)”]
> [tumult] Just curious -- where in the TOS are third party clients forbidden? I've read it a few times, and I'm not seeing it.
> [dge2020] Probably:
> You agree not to (and not to attempt to) (i) use the Service for any use or purpose other than as expressly permitted by these Terms;(ii) copy, adapt, modify, prepare derivative works based upon, distribute, license, sell, transfer, publicly display, publicly perform, transmit, stream, broadcast, attempt to discover any source code, reverse engineer, decompile, disassemble, or otherwise exploit the Service or any portion of the Service, except as expressly permitted in these Terms;
> It's a catch-all but the best restriction that prevents third-party clients is probably 'prepare derivative works based on' and 'reverse engineer' (which you would need if you want your third party client to use any regular client API calls, or if you want to support signing in with the user-facing login page/qr login).
> [tumult] A third party client like Ripcord isn't a derivative work. It also wasn't made by reverse engineering any of Discord's code. Even if it were, these rules still wouldn't apply to using third party clients.
So it seems that, as you note, the ToS do not explicitly mention third-party clients but Discord themselves believe that it forbids third-party clients.
https://news.ycombinator.com/item?id=28435490
I just read all of the ToS and also didn't find anything which disallows third party clients. I did find some older references to it on Google. Perhaps they changed the rule?
No, it was never there. Some people assumed it was, said it out loud, and it spread like a meme (as in the original meaning of the word.)
I wonder if there are open source Discord server impls around that could help making a switch from the walled garden?
maybe this: https://github.com/spacebarchat/spacebarchat
maybe this: https://github.com/spacebarchat/spacebarchat
In that case you might as well use other options like Mattermost, Rocket.chat or of course the Matrix route.
You can't reach Discord users that way.
No sane voice support.
Yeah fair if you do require an all in one solution. It honestly didn't occur to me as I rarely use voice on Discord.
why do you need voice support?
& is there no lower-level solution? IE why do you need your discord client to do voice transcription?
& is there no lower-level solution? IE why do you need your discord client to do voice transcription?
Because people like to talk to each other sometimes.
And voice channels are a convenient feature people prefer rather than handling yet another tool with its own idiosyncrasies.
And voice is not enough, it also needs video and screen sharing. It all needs to be "free" (AKA someone else pay for it) too, or people will keep using Discord.
People should also be able to create their own servers without worrying about technical details, and again, without directly paying for it.
That's how high the bar is.
And voice channels are a convenient feature people prefer rather than handling yet another tool with its own idiosyncrasies.
And voice is not enough, it also needs video and screen sharing. It all needs to be "free" (AKA someone else pay for it) too, or people will keep using Discord.
People should also be able to create their own servers without worrying about technical details, and again, without directly paying for it.
That's how high the bar is.
doh, I forgot about voice chat.
> People should also be able to create their own servers without worrying about technical details, and again, without directly paying for it.
I think this is the real reason why Discord is so ubiquitous nowadays. I remember back in 2017/18, it was really only (PC) gamers who used Discord - because your average PC gamer is somewhat more tech literate than the general. Nowadays, every community and their mother has a Discord server.
> People should also be able to create their own servers without worrying about technical details, and again, without directly paying for it.
I think this is the real reason why Discord is so ubiquitous nowadays. I remember back in 2017/18, it was really only (PC) gamers who used Discord - because your average PC gamer is somewhat more tech literate than the general. Nowadays, every community and their mother has a Discord server.
More people choose to make clients for a proprietary services that will ban people for using them or even invent their own protocol than people choose to make clients for Matrix. This should worry the Matrix folks.
i'd never heard of matrix until now, and i had to search for it on two different search engines before i eventually found it (very far down on the list of results).
after briefly scanning their website, i don't get it. there are multiple providers you can create an account with and multiple clients? is this for direct messaging to individuals or are there "rooms"? can accounts on different providers talk to each other? how do i know which provider i should sign up with?
these are mostly rhetorical questions because i've already lost interest and all of my online friends are already on discord. but the experience i just had is what they should be worried about imo.
after briefly scanning their website, i don't get it. there are multiple providers you can create an account with and multiple clients? is this for direct messaging to individuals or are there "rooms"? can accounts on different providers talk to each other? how do i know which provider i should sign up with?
these are mostly rhetorical questions because i've already lost interest and all of my online friends are already on discord. but the experience i just had is what they should be worried about imo.
It's fediverse but for chat. It has group chats, but netsplits somehow behave even worse than they do on IRC and if you join public ones you'll get sent extremely unwanted images by bots on a regular basis.
There are a million clients because the official one has horrible UX and everyone thinks they can make a better one.
I know quite a few people who think it's the future of chat but every time I've tried to use it I've ended up having a bad time. I'd advise against trying personally.
There are a million clients because the official one has horrible UX and everyone thinks they can make a better one.
I know quite a few people who think it's the future of chat but every time I've tried to use it I've ended up having a bad time. I'd advise against trying personally.
I'm wearing a Matrix T-Shirt right now and can't disagree much about the experience not being great.
> There are a million clients because the official one has horrible UX and everyone thinks they can make a better one.
I wish. My experience is that there are few clients and a lot of them have similarly ... beginner-unfriendly UX due to the SDKs, the protocol itself and cultural factors (there seems to be a good amount of "this is good enough"/"you don't actually need that" hubris in the community).
Matrix, besides XMPP, is the only federated chat protocol with any kind of traction, so I figure that it makes sense to invest in improving it rather than building something new. Ideally using it would be a no-brainer choice for delivering chat apps: Why would you invent something new when you could use a protocol that already exists and already has a vast ecosystem of libraries and users? That's where I wish it was, reality unfortunately looks quite different.
> There are a million clients because the official one has horrible UX and everyone thinks they can make a better one.
I wish. My experience is that there are few clients and a lot of them have similarly ... beginner-unfriendly UX due to the SDKs, the protocol itself and cultural factors (there seems to be a good amount of "this is good enough"/"you don't actually need that" hubris in the community).
Matrix, besides XMPP, is the only federated chat protocol with any kind of traction, so I figure that it makes sense to invest in improving it rather than building something new. Ideally using it would be a no-brainer choice for delivering chat apps: Why would you invent something new when you could use a protocol that already exists and already has a vast ecosystem of libraries and users? That's where I wish it was, reality unfortunately looks quite different.
> Why would you invent something new when you could use a protocol that already exists and already has a vast ecosystem of libraries and users?
Unfortunately that's exactly what Matrix did, and people keep repeating the same mistake. Just this week, i was seeing a new federated IM protocol whose main selling point is "not XMPP/Matrix":
https://github.com/tinode/chat
If only these Matrix/Tinode people spent their energy on making a decent XMPP client, Discord would not even be born. Alas, my interpretation is it's a hard-sell to investors to make a client for an existing network and these devs want to put bread on their tables.
Unfortunately that's exactly what Matrix did, and people keep repeating the same mistake. Just this week, i was seeing a new federated IM protocol whose main selling point is "not XMPP/Matrix":
https://github.com/tinode/chat
If only these Matrix/Tinode people spent their energy on making a decent XMPP client, Discord would not even be born. Alas, my interpretation is it's a hard-sell to investors to make a client for an existing network and these devs want to put bread on their tables.
i mean it is also totally fair enough to just make another version of something that already exists for the sake of it, making things is fun and that's a good enough reason imo.
personally i'm really not a fan of the "x already exists so everybody should always use that and nobody should ever spend time making a different one" school of thought that seems to be so prevalent here. i just think it goes without saying that if their thing isn't obviously better and easy to adopt, it probably won't gain any traction.
personally i'm really not a fan of the "x already exists so everybody should always use that and nobody should ever spend time making a different one" school of thought that seems to be so prevalent here. i just think it goes without saying that if their thing isn't obviously better and easy to adopt, it probably won't gain any traction.
> still no x-super-properties use
Unsafe. Discord uses the aforementioned header for client identification for certain endpoints. Lack of usage of this header is dangerous.
Unsafe. Discord uses the aforementioned header for client identification for certain endpoints. Lack of usage of this header is dangerous.
Hi, Dissent actually makes no effort to try and hide itself from Discord! In fact, API calls via Dissent have their User-Agent header set to "Dissent (https://libdb.so/dissent)" to emphasize the fact that they're NOT performed by the official client.
https://news.ycombinator.com/item?id=28435490 goes into this, but Discord doesn't actually care if you use a third-party client. They only care if said client misuses the API, and that happens to include a lot of past clients. I've been developing a handful of Discord clients for several years now and have never had my account banned, but I have a backup account just in case this scenario happens.
Of course, people may still be banned for using Dissent, so use it at your own risk.
https://news.ycombinator.com/item?id=28435490 goes into this, but Discord doesn't actually care if you use a third-party client. They only care if said client misuses the API, and that happens to include a lot of past clients. I've been developing a handful of Discord clients for several years now and have never had my account banned, but I have a backup account just in case this scenario happens.
Of course, people may still be banned for using Dissent, so use it at your own risk.
You're misusing the API by not following what headers are used by Discord itself, so this comes off as fairly irresponsible. 2021 was a long time ago, so I wouldn't take anything said there as accurate to current times.
Could you elaborate? What exactly is in that header and what's dangerous about not passing it?
Hmmm... I don't use Discord a lot, but (depending on how resource intensive this app is) I wish someone would combine this with https://github.com/jpbruinsslot/slack-term into a lightweight Slack client. Not sure about how Slack's policy regarding unofficial clients is though...
This looks like a very slick project and might just use it. GG!
Any chance something similar exists for slack? The discord client is not that much of a pain, but slack you have to pick between a client that OOMs the machine, and a browser tab that OOMs the browser.
Any chance something similar exists for slack? The discord client is not that much of a pain, but slack you have to pick between a client that OOMs the machine, and a browser tab that OOMs the browser.
https://revolt.chat/ looks like a good alternative to Discord.
I have tried quite a lot of alternative discord clients, my favorite is still Abaddon[0]. It works great, and its UI is fonctionnal enough for my needs.
[0] https://github.com/uowuo/abaddon
[0] https://github.com/uowuo/abaddon
I simply wanted to write a user bot which reads messages from a channel (to write them to another messenger). After reading tos it seems to be a reason to get a ban, but did this ever happen for simply reading? I bet this stuff only triggers on actions.
they actually provide a pretty complete bot api that's perfect for what you want to do. since it's a bot api, the "user" will appear as a bot in discord clients, and a few restrictions will apply (e.g. bots cannot interact with each other). but for simply reading a channel, it's pretty trivial to do.
I did use it in the past using the Rust library Serenity [0] (unofficial library ofc) to make a geoguesser-like bot [1] for a private server with friends. Pretty simple to use actually! Do note they have some pretty harsh ratelimits when it comes to API calls though, so pay attention to caching when fetching data (not likely to be an issue for your usecase at it'll mostly be server-sent events.
[0]: https://docs.rs/serenity/latest/serenity/
[1]: https://github.com/Tuetuopay/bot-ticelli (don't judge, this was thrown together between amongus games during lockdown)
I did use it in the past using the Rust library Serenity [0] (unofficial library ofc) to make a geoguesser-like bot [1] for a private server with friends. Pretty simple to use actually! Do note they have some pretty harsh ratelimits when it comes to API calls though, so pay attention to caching when fetching data (not likely to be an issue for your usecase at it'll mostly be server-sent events.
[0]: https://docs.rs/serenity/latest/serenity/
[1]: https://github.com/Tuetuopay/bot-ticelli (don't judge, this was thrown together between amongus games during lockdown)
I know about the bot api, but I want to use that as a user account.
I don't get why you would want that but what do i know :DI
Indeed since clients have a websocket connection to stream incoming messages, it should be nigh indistinguishable for them from a regular clients.
Also, the API abuse they are worried about is spam and scams, so just pulling out messages is likely to be the last of their problems.
Indeed since clients have a websocket connection to stream incoming messages, it should be nigh indistinguishable for them from a regular clients.
Also, the API abuse they are worried about is spam and scams, so just pulling out messages is likely to be the last of their problems.
I mean that’s kinda the same as the linked project Dissent - they also use a user account. That’s why I thought about it that way.
What perfect timing, I started going down the GJS (Javascript) route for a custom app. Maybe it's time to build a Go + templ like package w/ GTK4 widgets.
> Using an unofficial client at all is against Discord's Terms of Service and may cause your account to be banned!
Remind me again, why do people still use this garbage?
Remind me again, why do people still use this garbage?
This would be great if it supported voice calls.