Self-bots: the documentation/why is it there?

[ThrowItThisWay]

I was wondering why there are no warnings about self-bots in the docs: http://discordpy.readthedocs.io/en/latest/api.html#discord.Client.login vs. https://discordapp.com/developers/docs/topics/oauth2#bot-vs-user-accounts https://support.discordapp.com/hc/en-us/articles/115002192352-Automated-user-accounts-self-bots-

This is clearly something that easily enables violation of ToS by accident - in fact: I've done just that thinking that this is all okay (I did not automate messages/DMs/voice/friend requests/invites or anything like that).

Unless there's something I've missed: why is that parameter is still present?

[ThrowItThisWay]

Additionally, by the looks of it others are posting code that contains bot=False too in the unofficial Discord API server.

[Gorialis]

This library dates back to before bot accounts, or an official API for them, even existed, and userbots were the only way to create bots for the platform. This is why user/password login is still present and documented in async, but this method has been removed from rewrite.

As for user token login, it was implemented because doing so was simple enough, and at the time of its implementation this support article, and Discord's vocality against userbots, were not a thing. In fact, the only suggestion against it was a friendly reminder to not try and automate 2FA, using tokens instead to avoid a ban.

These features haven't been removed since their implementation because doing so achieves very little, Discord still maintains discord.py's placement as a recommended library even with it, and some people still use it (at their own peril). A warning isn't included because acquiring your own user token requires insight alone, you have to explicitly set bot=False to use it, and mentioning such matters in detail within the documentation may infact induce the opposite effect and increase userbotting (people are less likely to fiddle with this option if they're not sure what it does).

That's not to say that removal or documentation won't happen, but it's very low priority to mess with this at the present moment.

[ThrowItThisWay]

Hold on, that makes no sense: why not simply mention in the docs that setting Bot=False is actually against the ToS while working with the rewrite?

I wrote my script assuming that the API wouldn't lead me straight into potentially getting my account banned by merely logging in a certain way.

[ThrowItThisWay]

@gogurtenjoyer why not reply instead of reacting with an emoji?

[Gorialis]

Documenting in detail, as aforementioned, would likely cause more people to try and use it, regardless of whether you mention it as ToS-violating or not (see: almost every existing userbot).

Documenting without detail and just mentioning that it violates ToS would inspire a lot more issues similar to this one - asking either why such a function exists at all or what it does (which would also inspire greater usage, while frustrating users who respond to the already large volume of issues on this repository).

As for the assumption the API won't get your account banned, I'm afraid you're out of luck, regardless of what library you use. There are multiple endpoints (such as the role update endpoint) that may get your account banned with incorrect usage even though Discord does not document this, and similarly Discord may ban your account for any reason at all if they please.

On the other hand, advancing far enough into using a userbot as acquiring and using the token without having ever heard about the possible consequences is an impressive feat within itself - most reputable sources such as the discord.py and Discord API guild will warn you about such things, and they are by far the most common places to learn of such functionality at all. If you've heard from a different detached source, I can't offer you much consolation - it is not our duty to moderate hearsay.

[ThrowItThisWay]

On the other hand, advancing far enough into using a userbot as acquiring and using the token without having ever heard about the possible consequences is an impressive feat within itself - most reputable sources such as the discord.py and Discord API guild will warn you about such things, and they are by far the most common places to learn of such functionality at all. If you've heard from a different detached source, I can't offer you much consolation - it is not our duty to moderate hearsay.

It is really not that hard getting that far without even hearing about it. The literal second hit for "getting user token discord" or "getting token discord" (on google) is this page: https://github.com/TheRacingLion/Discord-SelfBot/wiki/Discord-Token-Tutorial (not exactly what I did, but there aren't exactly many places you can find out that you shouldn't do this)

Fyi, I've not received a ban, so no need for consolations. I'm trying to help others avoid doing the same thing as I did.

Documenting without detail and just mentioning that it violates ToS would inspire a lot more issues similar to this one - asking either why such a function exists at all or what it does (which would also inspire greater usage, while frustrating users who respond to the already large volume of issues on this repository).

The solution isn't too hard: mention that this is a deprecated mode of operation scheduled to removed soon(tm) and link to one of the two links I posted in the topic in the documentation. This is much better than not mentioning this at all.

Heck, even removing the parameter and releasing an updated version of the current API would be better.

Edit: Hooold up: You wrote this:

most reputable sources such as the discord.py and Discord API guild will warn you about such things, and they are by far the most common places to learn of such functionality at all. 

From 3 days ago on the Discord API server:

Fire597: ?tag user token
BOTR. Danny: 1. Open Discord
2. Press Ctrl+Shift+i
3. Click "Application" tab
4. Expand Storage > Local Storage > https://discordapp.com/
5. Find "token" under "key"
6. Copy the text in quotes on the same row

No warning.

[Gorialis]

Marking the argument as deprecated doesn't really work - as of the current moment, there are no plans to deprecate this functionality in the library (some people do still use userbots despite the risks, and it's not really the job of the library to be opinionated on this matter, especially when preserving the functionality takes less work than removing it).

Marking the argument as deprecated anyway, while it may reduce interest in using it, also brings up the possibility of issues and questions about deprecation time that we can't answer if it's not actually being deprecated (yet).

I'll see about introducing a warning anyway - a warning with a link may deal with the previous brevity issues without overcompromising. If, in the mean time, you have a specific idea for how to manage this, you can always make a pull request.

[ThrowItThisWay]

Marking the argument as deprecated doesn't really work - as of the current moment, there are no plans to deprecate this functionality in the library (some people do still use userbots despite the risks, and it's not really the job of the library to be opinionated on this matter, especially when preserving the functionality takes less work than removing it).

Maybe this should be a decision that you need to make? Is there any good reason to continue letting people do the whole self-bot thing? It'll just lead to problems down the line for you as Discord seem to have plans about getting stricter about this stuff given the fact that this was posted 18 hours ago.

If you think this complaint or any of the other complaints are bad, it'll be a fun time once the drek hits the fan.

Marking the argument as deprecated anyway, while it may reduce interest in using it, also brings up the possibility of issues and questions about deprecation time that we can't answer if it's not actually being deprecated (yet).

That's why you mark it as deprecated so people get warnings about using the function that way. You don't want people using this functionality as it is all-around a bad idea and you should force people to get proper API keys.

In fact, your documentation was one of the factors that lead me to believe that this was okay - "oh hey, this lib that is acknowledged by Discord is doing it this way - must be okay!"

[gogurtenjoyer]

@ThrowItThisWay you're right; my apologies.

👎

[Gorialis]

There's no real decision to make, removing the functionality causes extra work to be done, a breaking change to the library (which would require a version bump), and inconveniences those who use or vaguely interact with the feature for any reason. The case would be different if keeping the functionality caused extra work, but it doesn't.

As it stands, the only real negative is posed by this issue - being that people who don't acquire information through the 'traditional' support sources may miss the risk, which is a particularly rare case in my experience and can be rectified through a documentation warning.

Unless a real reason stands to prohibit usage at this level, I don't see why people who understand the risks shouldn't be able to use the functionality. This library, and every recommended library, makes no effort to hide itself from Discord. If anything, Discord could have just blocked userbots through this library and every other library outright but that hasn't happened due to their lukewarm actual response to the issue in practice.

I'd also like to mention that your support article is not 18 hours old. It is over a year old as of now and even since then reported cases of userbot bans have been extremely scarce outside of spam botnets.

[ThrowItThisWay]

I'm sorry, but what?

"Oh, we have this feature that some people use that may get your user banned, we don't tell you about it and the most official unofficial channel tells you how to use it (as seen above) without ANY warning, but really - why would we inconvenience people in the face of all of this by making them spend 5 minutes removing bot=False from their code and acquiring a proper API key! Also, no warnings in our docs making people believe this is an okay way of doing things!"

If anything, Discord could have just blocked userbots through this library and every other library outright but that hasn't happened due to their lukewarm actual response to the issue in practice.

Have you considered that this library may in fact be actively contributing to the problem?

PS: @gogurtenjoyer I prefer it if you went back to using reactions. You're now being worse than useless in this conversation. Same with your friend that I would guess you linked the thread to.

[Rapptz]

I'm going to close and lock this conversation after this reply, especially after your little argumentative fit where you start insulting people.

In any case, the reason why it's there is because there's no reason for it for me personally to remove it. I do not particularly care about the Discord Terms of Service to the point of removing things that conflict with it, in fact if you were to look a little closer to the code you'd even see things such as a header bypass which is against the developer ToS to bypass bugs in Discord's implementation.

There are a couple of things that are allowed with user tokens logging in that could be useful for anyone who partakes on the risk, you know, on their own accord.

1. The ability to self-bot is the most obvious one, and one I don't particularly care for.
2. The ability to create a custom lightweight client that doesn't rely on a browser, e.g. a CLI client or a GUI client using PyQt. This one is technically forbidden by Discord's own Terms of Service but no one is going to prosecute you for doing it.

In all of your comments and insulting in this issue you could have instead opened a pull request with your motive to add the warning but instead you decided to for some reason go on a spree of berating the very people who are answering your request.

I suggest next time you open an issue like this in another project to instead spend the effort making a pull request for the 3 or 5 lines of code that would have accomplished this without the incandescent charade.