Provide information on which client the user sent an interaction from

[bignutty]

I love the ansi codeblock highlighting that was added during hack week, sadly it looks garbage for mobile users.

Mobile also has other issues like no inline embed fields, providing which client (desktop/mobile/web) the user sent the interaction from would allow bot developers to send optimized responses which are able to account for lack of feature parity or screen sizes without having to make compromises on the user experience for desktop/mobile respectively.

The optimal implementation here would be a simple property along the lines of "used_client": "mobile" on the recieved interaction payload.

[promise]

A really hacky workaround is to use the user's presence to see if they're online on mobile or not, but not all bots have access to presence so this would be nice, +1

[GamingGeek]

Even if you have access to the presence intent, you need to open the flood gates for presence events even if you only want to fetch presence when you need it 😞

[panley01]

A field like this sent in interaction payloads would fix a symptom of a problem rather than the underlying issue of feature-parity lacking between clients. That same feature parity also allows for unique attack vectors per-client, which makes identifying the client used marginally dangerous.
While there are hacky workarounds (deep links, status tracking etc.), they're about as hacky as providing client information over interactions, and I think fixing the root issue would be vastly superior.
That said, I think the fact the inline property of embed fileds is ignored on mobile clients is very annoying to account for in development, however it's far from the only inconsistency with how embeds & links as a whole are handled between clients & while I understand programming for feature-parity is especially challenging with embeds due to differing frameworks across clients, it's frankly vastly overdue for some futher attempts to be made here. The lack of feature parity in embeds not only makes life difficult for bot developers (which contribute significantly to the safety & experiences of the platform) as evidenced here (and countless times in the past), but they also pose unique security concerns as these exact inconsistencies already allow you to specifically target mobile/desktop users & make nightmare for automoderation as certain embed providers (like youtube) only show certain data on some clients.
I understand there's alot of challenges with cross-client feature partiy but the amount of features that dictate how content is accessiable in-client that only function properly on certain clients is actively a problem, given 66+% of users (predicted) will use Discord from mobile clients, there realy should be much more focus on feature-parity for mobile experiences.
TL;DR, this would be nice but it's just evidence that the underlying problem here needs fixing and has needed fixing for years.

[bignutty]

Fixing the root issue isn't reasonably feasible, most mobile app versions of services provide a degraded user experience in comparison to desktop since that usually includes getting designers to come up with entirely new ways of interacting with features. Especially when coming into territories of hack week projects or small QoL changes porting them is going to take way more effort.
The feature parity issue itself is just one half of the problem, I've often encountered the issue of mobile splitting long text in unexpected ways due to screen width, which gets especially awkward once you try to display much information in a formatted way using embed fields.
While I do agree that the proposal is in some ways a band-aid fix for the feature parity issues developers have to constantly work around, I believe its a necessary one, for discord it just doesn't make sense to port really minor features over.

[erkinalp]

That would block Discord from allowing third party clients in future, and also degrade user's privacy.

[Rapptz]

It wouldn't preclude it (not that I think Discord would ever be willing...). However the gateway already does this type of splitting with activities so I think there's precedence for this already.

[bignutty]

If discord ever did allow third party clients this would simply have to be documented as to how clients are supposed to identify themselves on the gateway? The privacy part is also kind of eh since the users presence data already provides if they are on mobile, desktop or web. This feature proposal would just make that accessible for serverless bots.

[renhiyama]

Instead of asking for "mobile" I would suggest to ask for "android" or "iOS" since both the discord apps are quite different on these two platforms.

[bignutty]

Android is soon going to use the iOS react native app, removing the necessity to identify which is which.

[renhiyama]

Also I would suggest this idea to be allowed for slash commands, and/or provide us the user agent (for more specific information about the device).
There might be some times different way of tweaking server/account settings for different devices, and Letting us know about the device a user is on, definitely helps us understand and give help in a better way.

[bignutty]

Providing the full user agent is kind of privacy intrusive imo, the implementation I thought of effectively only provides data bot developers can already access via other methods, just in an easier and more intuitive way.

[Hyperclaw79]

Embeds aside, this is a really useful feature for devs implementing commands which use images in response.
Portrait oriented images get compressed based on width on desktop. Getting the user's device (at least the approx. width and height) could enable the dev to send the correct image conditionally.