-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Get a specific member's presence without the intent #1624
Comments
Very much needed. I have no intention of upgrading to v12 of discord.js before nor after intents are required due to personal complications. |
As far as I'm aware, the reason guild presences are locked behind a whitelisted intent in the first place is so that it's much harder to harvest presence data without Discord knowing that you can do so, and why. Even if this endpoint had a very high ratelimit, as in something like 1 request/60s or something of the nature, I don't know that Discord would want to add itsince that would allow harvesting without their knowledge, even if slowly. |
But you could say the same for members, but we can request those on demand without the intent.. |
I don't think you can? The |
No, you can't. That's why this issue exists. What I said there was just about regular member data without presences |
It's not necessarily just a question of privacy. Recall that the original reason to restrict presence intents was technical, namely a want to avoid the bandwidth/processing costs of distributing updates to large bots. It's easy to imagine that as a matter of systems architecture, data about presences simply might not exist in a location where the servers that answer REST requests can get at them. There's a lot of churn in these data (e.g. every time someone foregrounds or backgrounds Discord on their phone) and no existing need to store them persistently -- if the server that knows the presences goes down irretrievably they can just rebuild them all when the clients reconnect. |
If you have the intent(s) you can already get them even for the whole memberlist. If that was true, then it would not have been possible for the |
@ziad8727 I think you're misunderstanding. I was trying to say that an endpoint to get one user's presence would sort of defeat the purpose of GUILD_PRESENCES being behind a whitelist, as while you can no longer get all presences in one call, you would still be able to eventually harvest enough presence data (even at a slower speed) to be a problem. This has very little to do with the member list. If Discord wanted to restrict the member list with that intent, they would have done so. My comment (and this feature request) only concerned the presence part of it all. |
The |
We have no current plans to expose presence data without the intent due to privacy concerns. You can access a single member's presence via |
The issue is that if you have a use case such as userinfo where you only need to get one user's presence, you get denied the intent because that doesn't justify getting all presence updates. Maybe allow bots to get whitelisted to only get a single user's presence? however that would be more work for Discord |
Currently, you need the GUILD_PRESENCES intent to access any presences, even a specific member's, because there is no endpoint to get a member's presence. #666 previously requested a presence endpoint, but it was closed due to #1116, which does let you get one member's presence. However, getting presences via this is locked to bots with the intent, likely because you can get many members using this. Since many bots just use presences for a command like userinfo, which only needs getting one member's presence, many bots would not need to get all presence updates if this is added. Also, it looks like bots are being denied the intent if this is their only use case, so this would be useful for those bots. This could be implemented with an endpoint, or just not requiring the intent on Guild Members Chunk if only one user id is requested.
The text was updated successfully, but these errors were encountered: