Make Discord RPC an optional dependency

Discord RPC should be optional, not a forced dependency it's a feature most users disable anyway and adds unnecessary complexity for minimal benefit.

Consider offering separate builds (with/without Discord) or making it truly optional for users who want a minimal install. This could be addressed during the planned AO2 rework.

I was told to make this an issue by Wiso, so there you go.

#1131

This feature is almost abandoned save for the fact that "discord", the checkbox, is on by default. If it was not, there is a good chance a good number of people would not even know it existed. Such a thing is hardly worth its place as a dependency and currently mostly serves to slightly annoy first-time builders of the AO-client who forget or don't know they should have had the .dll in place.

It is a minor gripe in the grand scheme of things though, and there probably are people out there who really want to use discord to show their courtroom or character and playtime.

If this is not outright removed in a future rework, perhaps making it optional in some form or putting it as its own separate build is an idea. It's alot to maintain, and at the moment I do not have a clean solution to offer that wouldn't drive the codebase further into random checks as is, but enough time has passed that this is a reasonable issue to be considered.

even in readme it did says "discord-rpc (optional)".. it's good tho, but what syntaxnyah meant is about people using client from the official release one.. syntaxnyah want if one day you guys release new version.. let's make it discord-rpc are "optional".. (dynamic lib or whatever it calls)..

that's syntaxnyah's idea (and wishes) if one day.. an new version release..

-DAO_ENABLE_DISCORD_RPC=OFF

AO2-Client/CMakeLists.txt

Line 15 in ccd93a3

option(AO_ENABLE_DISCORD_RPC "Enable Discord Rich Presence" ON)

we already have this

-DAO_ENABLE_DISCORD_RPC=OFF

AO2-Client/CMakeLists.txt

Line 15 in ccd93a3

option(AO_ENABLE_DISCORD_RPC "Enable Discord Rich Presence" ON)

we already have this

Thanks for your input however you're missing the point. Consider offering separate builds (with/without Discord) or making it truly optional for users who want a minimal install. This could be addressed during the planned AO2 rework. For users that don't know how to compile AO2, alternatively this could even be an option on the launcher install or some other way of maintaining a build without being discord dependent. That doesn't really address the core issue of the point I was trying to make but yes that is one tedious way of doing it, installing 35gb of QT, amazing option every user will love doing that.

Alright I'll be real with you regarding this issue.

Disabling Discord-RPC is already a toggle within the client. With it disabled, the library is never initialized. This means that no IPC is opened and that the Discord process is not accessed, therefor nothing is transmitted. The DLL just sits on disk as inert data. So the request of "a user who wants nothing to do with Discord" is already fully covered today, without any code change.

What's proposed goes beyond the current design: dynamically load the library so the file can be deleted and the client can still launch. The problem is that it doesn't change behavior. A disabled but present DLL and a deleted DLL are identical in every observable way; the Discord activity is still EXACTLY zero in both cases. The only difference is whetever a few kbs of unused data exist on the disk. In exchange, we're adding a runtime loader and a brand new failure state. (e.g. The user enables RPC but the file being gone prevents its functionality, meaning we have to explain what is happening to the user.) All to let users delete a file that already does nothing.

The deletion is also the wrong way to design around, configuration of these options belong in settings not "delete the dll you don't recognize". A user who deletes the DLL because they don't like the name is the same user who deletes a Qt DLL for the same reason and then report that the client does not work at all. Making the client resilient to removal of its own dependencies, specifically so that removing them become a support config method is backward. We'd just be strengthening the client against user error in order to encourage the error to happen. As I said, backward.

We already have a build option that disables linking the DLL entirely. That's the supported way to get a Discord-free build, and the build is exactly where that call belongs. What's being asked is a different thing, making the Discord-included build survive someone deleting that DLL by hand. Those aren't the same topic, and the dynamic loading change doesn't get you the no-Discord build, we already have that.

As for the mention that a user shouldn't have to download ~35gb of Qt stuff just to remove discord-rpc, they don't need to. The toggle already kills all Discord activity without compiling anything, so there's nothing to compile in the first place. And even if we had the CI produce a build without the packaged DLL, the typical user is no more likely to go hunting for that than they are to know which DLL to delete, the in-game toggle is the only one of these three they'd actually find.

So in conclusion the concern is already solved by the existing toggle. Deleting the file changes nothing observable and "let the user delete a required DLL" is just like giving them a shotgun fully aware that they may shoot themselves in the foot, not a feature. I don't see a problem here that that the toggle doesn't already cover and I don't think the change would be justified.

Oh, and one last thing: if the reasoning is "let me delete discord-rpc", then why not bass, or any other DLL we ship? Either everything becomes dynamically loaded so it can all be hand-deleted, or we accept that deleting binaries was never the right mechanism. It's the latter.

Thank you for coming to my ted talk.

Alright I'll be real with you regarding this issue.

Disabling Discord-RPC is already a toggle within the client. With it disabled, the library is never initialized. This means that no IPC is opened and that the Discord process is not accessed, therefor nothing is transmitted. The DLL just sits on disk as inert data. So the request of "a user who wants nothing to do with Discord" is already fully covered today, without any code change.

What's proposed goes beyond the current design: dynamically load the library so the file can be deleted and the client can still launch. The problem is that it doesn't change behavior. A disabled but present DLL and a deleted DLL are identical in every observable way; the Discord activity is still EXACTLY zero in both cases. The only difference is whetever a few kbs of unused data exist on the disk. In exchange, we're adding a runtime loader and a brand new failure state. (e.g. The user enables RPC but the file being gone prevents its functionality, meaning we have to explain what is happening to the user.) All to let users delete a file that already does nothing.

The deletion is also the wrong way to design around, configuration of these options belong in settings not "delete the dll you don't recognize". A user who deletes the DLL because they don't like the name is the same user who deletes a Qt DLL for the same reason and then report that the client does not work at all. Making the client resilient to removal of its own dependencies, specifically so that removing them become a support config method is backward. We'd just be strengthening the client against user error in order to encourage the error to happen. As I said, backward.

We already have a build option that disables linking the DLL entirely. That's the supported way to get a Discord-free build, and the build is exactly where that call belongs. What's being asked is a different thing, making the Discord-included build survive someone deleting that DLL by hand. Those aren't the same topic, and the dynamic loading change doesn't get you the no-Discord build, we already have that.

As for the mention that a user shouldn't have to download ~35gb of Qt stuff just to remove discord-rpc, they don't need to. The toggle already kills all Discord activity without compiling anything, so there's nothing to compile in the first place. And even if we had the CI produce a build without the packaged DLL, the typical user is no more likely to go hunting for that than they are to know which DLL to delete, the in-game toggle is the only one of these three they'd actually find.

So in conclusion the concern is already solved by the existing toggle. Deleting the file changes nothing observable and "let the user delete a required DLL" is just like giving them a shotgun fully aware that they may shoot themselves in the foot, not a feature. I don't see a problem here that that the toggle doesn't already cover and I don't think the change would be justified.

Oh, and one last thing: if the reasoning is "let me delete discord-rpc", then why not bass, or any other DLL we ship? Either everything becomes dynamically loaded so it can all be hand-deleted, or we accept that deleting binaries was never the right mechanism. It's the latter.

Thank you for coming to my ted talk.

Hey thanks for the response I genuinely appreciate your TED talk. I feel like I just sat through a well thought out lecture on why I should never question a DLL again, complete with slides and foot notes. Okay I'll give you credit where it's due, your right about the toggle it exists and works. By toggling it off, you successfully kill all Discord activity. Youve also brought up a valid point that dynamic loading is overkill for a problem that basically doesn't exist.

Also you're right that users are definitely too dangerous to be trusted with files........ We wouldn't want any user, accidentally deleting something they don't possibly understand! That would be complete chaos, the entire client might explode, or dare I say, they might feel a false sense of control over their own system. How scary! However my whole point was never just about the toggle though i was more on the angle of like, 'why are we shipping a dead file that does absolutely nothing when disabled?' Like, if it's already idle, doing zero things whatsoever, already just sitting there taking up space and contributing nothing why does it need to be there at all? But I get it. I genuinely do .

Oh right next thing to address, fair point about the 35GB Qt thing I'll be sure to tell every user who just wants a minimal install that they don't have to compile anything, heck they don't have to touch CMake!! Even better, they don't have to install anything! All they have to accept the dead DLL as a permanent, non-negotiable resident on their disk, like a tiny digital landlord that does nothing but demands to exist. This is very normal. Nothing strange or weird about this whatsoever at all. Completely standard software design.

Thanks for the breakdown honestly it's been an eye opener. Next time I'll know better than to question a harmless file sitting there doing absolutely nothing. The silly thing taking up space, living its best possible life on my computer, completely untouched and unused.

In conclusion, clearly I was the problem all along. I think the next step for me to do is to go compile my own client in a cave now, surrounded by 35GB of Qt, contemplating my life choices... and why I ever thought questioning a dead DLL was a good idea.

Enjoy the win, you've absolutely earned it. I'll be here if anyone needs me. Probably not though. I'll just be in my cave staring at my dead DLL wondering what could have been.

So when I suggest it, it's overkill and rejected by Leifa themselves. But when Leifa suggests it, it's a force pushed PR within hours. Glad I could be the inspiration again. Hypocrisy at its finest. I'm done thanks for rubbing salt in the wound.

Just for fun, let's look at the timeline:

I opened my PR (#1124) with a working fix March 15.

I waited three full weeks with zero comments, zero feedback, zero anything.

Leifa opened a duplicate PR (#1129) — April 5.

Leifa's PR was reviewed, approved, and merged within 24 hours.

Mine was closed the same day with a polite 'thanks but we went with this one.'

Fast forward to this issue (#1132):

I suggested separate Discord-free builds June 20th.

I was told it was overkill, unnecessary, and that the toggle already exists.

Leifa opened a PR implementing that exact suggestion — June 23rd, force-pushed within hours.

So to recap: my ideas are overkill when I suggest them, but urgent when Leifa does. My PRs sit for weeks, but Leifa's get merged instantly. I get silence, Leifa gets instant credit and force push and I get nothing back.

I'm not mad - I'm just genuinely impressed by the consistency at this point. Scooped twice, credited zero times. Thanks for the experience. I'm done.

For what it's worth, I don't think we're actually on opposite sides here. Discord-free build is exactly what #1138 produces. It's a separate build rather than the runtime-loading route from #1131, but it gets you the same end result: no Discord, no compiling. No hard feelings.

For what it's worth, I don't think we're actually on opposite sides here. Discord-free build is exactly what #1138 produces. It's a separate build rather than the runtime-loading route from #1131, but it gets you the same end result: no Discord, no compiling. No hard feelings.

Hey thank you for replying. I appreciate you saying that we are not on opposites do. I'm glad the Discord-free build is actually happening now.

That said, I think it's fair for me to be honest about why this whole process has been so frustating.

I opened PR #1124 with a working fix. It sat for three weeks with zero communication. You then opened the same fix, got it merged within 24 hours, and my PR was closed with a polite 'thanks but we went with this one.' That stung and hurt but I let it go and was all for it.

Then I opened this issue (#1132 suggesting separate builds. I was told it was overkill, unnecessary, and that the toggle already existed by YOU. Then you opened a PR (#1138) implementing that exact suggestion force-pushed and merged within hours. No mention of my issue. No credit. Just pushing seeing my PRS and not even communicating hurts a lot.

That hurts a lot more than you probably realize.

That's the part that really gets me and makes me not want to contribute here. Not once did you say 'hey, I saw your PR' or 'good idea, let me take a crack at it' or even 'thanks for the suggestion.' or even .'Hey you could've done this better or slightly different.' You just took the idea and ran with it. Twice. That's not collaboration. That's scooping. Plain and simple.

I'm not saying this was malicious. But the pattern I'm getting from this repo is pretty clear: my ideas sit and get dismissed, and then they get picked up and fast-tracked when someone else brings them up. Twice now. That's not a coincidence, that's a pattern.

So yes, I'm glad the feature is being added. I truly am. But I'm also disappointed that it took being ignored, replaced, and scooped twice for something to happen, and that at no point did anyone say 'hey, good idea, let's work on this together.' This is not a good environment for me, honestly. And I'm not sure I'd recommend contributing here to anyone else.

No hard feelings honestly. I just think open source works better when contributors feel heard and valued, not when they feel like they're being silently outrun by people who saw their work and said nothing.

I'm not looking for an apology or a fight. I just wanted to say it plainly, so that maybe the next person doesn't have to go through the same thing.

Take care, and good luck with the project. I genuinely mean that.

I have little interest in dramatic ramble, and I would kindly ask both of you not to go at odds with amicable social standards on a public repository over a .dll made by discord inc. It's not worth the while. There are guidelines to be followed and unspoken rules that go expected.

This issue is going to be re-opened. No one approved any of this and issues are not closed until they are resolved, not until people get fed up about it.

Alright I'll be real with you regarding this issue.

Disabling Discord-RPC is already a toggle within the client. With it disabled, the library is never initialized. This means that no IPC is opened and that the Discord process is not accessed, therefor nothing is transmitted. The DLL just sits on disk as inert data. So the request of "a user who wants nothing to do with Discord" is already fully covered today, without any code change.
Thank you for coming to my ted talk.

Then why commit the time to not only patch a fix for it, and cause the same issue you've been kindly asked not to do prior? The issue maker clearly wanted it solved, sure, but that does not mean you, having read the prior interactions as they have so kindly listed now, should opt to sacrifice all preexisting notions to get it done. Thank you for your time on it and I imagine it was done in good faith, but this is not the way, and should have been consulted with the concerned parties first.

we already have this

That's not the point. You need to have a dev environment installed to do this. The point is not to make the user have to do that. For a dependency that little people if ever depend on.

So when I suggest it, it's overkill and rejected by Leifa themselves. But when Leifa suggests it, it's a force pushed PR within hours. Glad I could be the inspiration again. Hypocrisy at its finest. I'm done thanks for rubbing salt in the wound.

Hey thank you for replying. I appreciate you saying that we are not on opposites do. I'm glad the Discord-free build is actually happening now.

That said, I think it's fair for me to be honest about why this whole process has been so frustating.

Take care, and good luck with the project. I genuinely mean that.

Irrespective of the reasons as to why things occurred the way they did, you are justified in this case and I appreciate being open about these points, even though they have made you annoyed. It is a better outcome than having not said them.

I understand that these words give you little reprieve. And you saw many examples that would lead to the conclusion that you are being left to dry. This is not the case, for whatever that may mean to you. I do not expect you to care, but I do expect all of you to understand basic social norms.

Despite their long post listing a multitude of reasons as to why the change was not required, you replied to them with a sarcastic tone and continued to list the same reasons with little regard to trying to reach any semblance of a resolution. That is a waste of both your time and theirs, and whoever else is trying to read this issue to solve your issue only to see a bunch of nonsense and leave.

You had every right to push forward for a more justified resolution and then chose to undermine it over some squabble. Don't do that. Nothing was force pushed and you can see that one click away. The one that was merged had your own comment under it. Why would you even claim that?

That's the part that really gets me and makes me not want to contribute here. Not once did you say 'hey, I saw your PR' or 'good idea, let me take a crack at it' or even 'thanks for the suggestion.' or even .'Hey you could've done this better or slightly different.' You just took the idea and ran with it. Twice. That's not collaboration. That's scooping. Plain and simple.

Not everyone does that at all. I understand the expectation, but there are many people who would not begin to feel the way you do, they just wanted the issue solved. Most people do, without caring if it was they or others who did it.

I'm not saying this was malicious. But the pattern I'm getting from this repo is pretty clear: my ideas sit and get dismissed, and then they get picked up and fast-tracked when someone else brings them up. Twice now. That's not a coincidence, that's a pattern.

This is a fair reason. This repository has higher standards and that was a failure to follow them. I will be putting down proper punishment for this, but twice over minor changes aren't really something to get so worked up about. You're not the first person and won't be the last, no matter how hard you push for it to be. It was a coincidence and became a pattern when an active developer thought to try and help the issues you created in an attempt to try and alleviate the tension. That in of itself is not a crime. If you believe it was malicious intent, make a ticket and it will be investigated. Maybe you're right, and if so, they'll be banned. And that will be the end of it.

So yes, I'm glad the feature is being added. I truly am. But I'm also disappointed that it took being ignored, replaced, and scooped twice for something to happen, and that at no point did anyone say 'hey, good idea, let's work on this together.' This is not a good environment for me, honestly. And I'm not sure I'd recommend contributing here to anyone else.

Because it was bad. I don't see why this needs to be spelled out. This was politely declined because it was a bad addition to the codebase. You attempted something good and it didn't get executed very well, so it was responded to. Theres nothing wrong with a failed attempt at coding an issue, and theres nothing wrong with someone seeing that attempt, working off of it, and trying to do better. There is no need to pass fault for it.

The other implementation frankly isn't even that much better, but its a start. And you admitted to it yourself with your own comment under the relevant issue. Who would say "Lets work together" on something they clearly view as unviable when they can start over and do it in a way even the original author would be fine with?

Were you fine with it or just saying that? Did you understand then that it was better to acquiesce for the sake of it to get it done? Whatever it is, that's on you. You don't get to blame others for that. Maybe we're all wrong and your implementation was the best thing ever and needs to be pushed and handled... right now! Right NOW!

Or maybe that's stupid. If you want to work with them for an even better one than the one they already submitted, say so. You are not in anyway barred from doing anything. You are more than welcome and the older one will be commented on, told that it is now obsolete, and that's it.

I have already discussed on the long wait in the prior thread and will not do so here. That was a coincidence in every meaning of the word. Choose to believe what you will, but no one here is out to get you and your code.

No hard feelings honestly. I just think open source works better when contributors feel heard and valued, not when they feel like they're being silently outrun by people who saw their work and said nothing.

Clearly. Honestly, it is nice that you are trying to be amicable about this despite what you've said. The dozens of posts are not silence, I would know, there have been enough reports and tickets about it.

While this issue has been re-opened, it does not mean it is an invite to keep going back and forth. This is a place for proper discussion of the issue at hand. Despite all in this thread and the ones prior, no action has been taken directly because it is two people who genuinely wanted better for the program, thats as far as we can believe, anyway. That is the sole reason, but it fails to become a good reason when every two paragraphs is a "Oh, I'm so done.. you're so... stupid!". There will be further action taken if conduct is not followed. That goes for anyone here.

You may not target individuals, you may not trash talk other contributors, even while providing constructive criticism, you may not impose whatever oppressive thoughts onto the people who manage it and you may not cry wolf because two issues were handled poorly. This did not have to be said, and this was a giant waste of people's time. I would like to believe that despite all of that, a good resolution can be reached that is fair to involved parties. This does not help make it easier.

Thank you for your contributions. Anyone may continue posting in this issue as they see fit until it is properly addressed. You can talk more about the other relevant issues as long as it is civil. This is a public place. Don't push it.

I have little interest in dramatic ramble, and I would kindly ask both of you not to go at odds with amicable social standards on a public repository over a .dll made by discord inc. It's not worth the while. There are guidelines to be followed and unspoken rules that go expected.

This issue is going to be re-opened. No one approved any of this and issues are not closed until they are resolved, not until people get fed up about it.

Alright I'll be real with you regarding this issue.
Disabling Discord-RPC is already a toggle within the client. With it disabled, the library is never initialized. This means that no IPC is opened and that the Discord process is not accessed, therefor nothing is transmitted. The DLL just sits on disk as inert data. So the request of "a user who wants nothing to do with Discord" is already fully covered today, without any code change.
Thank you for coming to my ted talk.

Then why commit the time to not only patch a fix for it, and cause the same issue you've been kindly asked not to do prior? The issue maker clearly wanted it solved, sure, but that does not mean you, having read the prior interactions as they have so kindly listed now, should opt to sacrifice all preexisting notions to get it done. Thank you for your time on it and I imagine it was done in good faith, but this is not the way, and should have been consulted with the concerned parties first.

we already have this

That's not the point. You need to have a dev environment installed to do this. The point is not to make the user have to do that. For a dependency that little people if ever depend on.

So when I suggest it, it's overkill and rejected by Leifa themselves. But when Leifa suggests it, it's a force pushed PR within hours. Glad I could be the inspiration again. Hypocrisy at its finest. I'm done thanks for rubbing salt in the wound.
Hey thank you for replying. I appreciate you saying that we are not on opposites do. I'm glad the Discord-free build is actually happening now.
That said, I think it's fair for me to be honest about why this whole process has been so frustating.
Take care, and good luck with the project. I genuinely mean that.

Irrespective of the reasons as to why things occurred the way they did, you are justified in this case and I appreciate being open about these points, even though they have made you annoyed. It is a better outcome than having not said them.

I understand that these words give you little reprieve. And you saw many examples that would lead to the conclusion that you are being left to dry. This is not the case, for whatever that may mean to you. I do not expect you to care, but I do expect all of you to understand basic social norms.

Despite their long post listing a multitude of reasons as to why the change was not required, you replied to them with a sarcastic tone and continued to list the same reasons with little regard to trying to reach any semblance of a resolution. That is a waste of both your time and theirs, and whoever else is trying to read this issue to solve your issue only to see a bunch of nonsense and leave.

You had every right to push forward for a more justified resolution and then chose to undermine it over some squabble. Don't do that. Nothing was force pushed and you can see that one click away. The one that was merged had your own comment under it. Why would you even claim that?

That's the part that really gets me and makes me not want to contribute here. Not once did you say 'hey, I saw your PR' or 'good idea, let me take a crack at it' or even 'thanks for the suggestion.' or even .'Hey you could've done this better or slightly different.' You just took the idea and ran with it. Twice. That's not collaboration. That's scooping. Plain and simple.

Not everyone does that at all. I understand the expectation, but there are many people who would not begin to feel the way you do, they just wanted the issue solved. Most people do, without caring if it was they or others who did it.

I'm not saying this was malicious. But the pattern I'm getting from this repo is pretty clear: my ideas sit and get dismissed, and then they get picked up and fast-tracked when someone else brings them up. Twice now. That's not a coincidence, that's a pattern.

This is a fair reason. This repository has higher standards and that was a failure to follow them. I will be putting down proper punishment for this, but twice over minor changes aren't really something to get so worked up about. You're not the first person and won't be the last, no matter how hard you push for it to be. It was a coincidence and became a pattern when an active developer thought to try and help the issues you created in an attempt to try and alleviate the tension. That in of itself is not a crime. If you believe it was malicious intent, make a ticket and it will be investigated. Maybe you're right, and if so, they'll be banned. And that will be the end of it.

So yes, I'm glad the feature is being added. I truly am. But I'm also disappointed that it took being ignored, replaced, and scooped twice for something to happen, and that at no point did anyone say 'hey, good idea, let's work on this together.' This is not a good environment for me, honestly. And I'm not sure I'd recommend contributing here to anyone else.

Because it was bad. I don't see why this needs to be spelled out. This was politely declined because it was a bad addition to the codebase. You attempted something good and it didn't get executed very well, so it was responded to. Theres nothing wrong with a failed attempt at coding an issue, and theres nothing wrong with someone seeing that attempt, working off of it, and trying to do better. There is no need to pass fault for it.

The other implementation frankly isn't even that much better, but its a start. And you admitted to it yourself with your own comment under the relevant issue. Who would say "Lets work together" on something they clearly view as unviable when they can start over and do it in a way even the original author would be fine with?

Were you fine with it or just saying that? Did you understand then that it was better to acquiesce for the sake of it to get it done? Whatever it is, that's on you. You don't get to blame others for that. Maybe we're all wrong and your implementation was the best thing ever and needs to be pushed and handled... right now! Right NOW!

Or maybe that's stupid. If you want to work with them for an even better one than the one they already submitted, say so. You are not in anyway barred from doing anything. You are more than welcome and the older one will be commented on, told that it is now obsolete, and that's it.

I have already discussed on the long wait in the prior thread and will not do so here. That was a coincidence in every meaning of the word. Choose to believe what you will, but no one here is out to get you and your code.

No hard feelings honestly. I just think open source works better when contributors feel heard and valued, not when they feel like they're being silently outrun by people who saw their work and said nothing.

Clearly. Honestly, it is nice that you are trying to be amicable about this despite what you've said. The dozens of posts are not silence, I would know, there have been enough reports and tickets about it.

While this issue has been re-opened, it does not mean it is an invite to keep going back and forth. This is a place for proper discussion of the issue at hand. Despite all in this thread and the ones prior, no action has been taken directly because it is two people who genuinely wanted better for the program, thats as far as we can believe, anyway. That is the sole reason, but it fails to become a good reason when every two paragraphs is a "Oh, I'm so done.. you're so... stupid!". There will be further action taken if conduct is not followed. That goes for anyone here.

You may not target individuals, you may not trash talk other contributors, even while providing constructive criticism, you may not impose whatever oppressive thoughts onto the people who manage it and you may not cry wolf because two issues were handled poorly. This did not have to be said, and this was a giant waste of people's time. I would like to believe that despite all of that, a good resolution can be reached that is fair to involved parties. This does not help make it easier.

Thank you for your contributions. Anyone may continue posting in this issue as they see fit until it is properly addressed. You can talk more about the other relevant issues as long as it is civil. This is a public place. Don't push it.

Thank you for acknowledging that I'm justified. That genuinely does mean a lot.

I also appreciate you re-opening the issue to make sure it's properly addressed, that's the right thing to do.

To be clear, I'm not looking for anyone to be punished or banned. I never was. I just wanted to be heard, and I wanted to point out a pattern that made contributing here feel discouraging. I think I've done that.

I don't think anyone here acted with bad intent. I just think the process could have been better and I hope it will be, for the sake of future contributors.

I've said everything I need to say. I genuinely wish the project well. Take care.

Navigation Menu

Repository navigation

Make Discord RPC an optional dependency #1132

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Make Discord RPC an optional dependency #1132

Description

Activity

WisoAltred commented on Jun 19, 2026

Ganty1999 commented on Jun 19, 2026

stonedDiscord commented on Jun 21, 2026

SyntaxNyah commented on Jun 21, 2026

TrickyLeifa commented on Jun 22, 2026

SyntaxNyah commented on Jun 22, 2026

SyntaxNyah commented on Jun 22, 2026

SyntaxNyah commented on Jun 22, 2026

TrickyLeifa commented on Jun 22, 2026

SyntaxNyah commented on Jun 22, 2026

WisoAltred commented on Jun 23, 2026

SyntaxNyah commented on Jun 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions