Expand @me
usage
#4219
Unanswered
VelvetToroyashi
asked this question in
API Feature Requests & Ideas
Replies: 1 comment
-
I don't even know what any of this means but cool |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
There are many endpoints that allow for referencing the current user via a special pseudo-snowflake (
@me
).This is great, because it doesn't require knowing what the ID of the current user is, and shows express intent when written in code somewhere.
This is used in many places, such as
[/oauth2]/users/@me
,/thread-members/@me
, and even/guilds/members/@me
There are obviously many many more, but the latter of those three is especially important.
That endpoint allows for PATCHing to update the current member (your about me, avatar, and nickname), but it does not allow you to GET that very same endpoint to fetch information about yourself.
Now from a user standpoint this argument is moot; you're sent information about a guild including yourself via the gateway.
But from a bot standpoint, this can pose inconveniences. There's no doubt that it can prove difficult to scale, especially when caching can scale exponentially, while the rest of a bot's infrastructure may not be as flexible or scalable.
For this reason (as well as just trying to limit memory usage in general), a bot may opt to limit their caching, especially of guild members.
This typically includes the current member (
@me
). For a majority of bots, this is fine.For anything that relies on specific permissions, however, this does pose an issue. Some libraries provide convenience methods for fetching the current member, which usually rely on also caching the current application. This is...fine, generally speaking, but if neither of those things are cached, then it's a problem.
One could also just hard-code their bot's ID in a file or database. This is also a valid solution, but not entirely practical.
It would be nice to simply be able to pass
/@me
as the snowflake, not only to save a call (to a DB, cache, or god forbid an API request). Someone's bound to call be lazy, and that's fair, but this also extends to just general consistency within the API; the error message received if you attempt to GET/guilds/members/@me
, you receiveValue "@me" is not snowflake.
I'd assume the same applies anywhere else a snowflake is expected, even if
@me
would make some/more sense.Much like my previous discussion I don't expect this kind of change to come to fruition any time soon, but It'd be interesting to see staff's response.
Also if this discussion is a duplicate of an issue let me know; CTRL + F is not my friend.
Beta Was this translation helpful? Give feedback.
All reactions