Disallow setting presence for bots

[erkinalp]

To prevent stress of bulk presence updates caused by bot users, I propose the presence data for applications (including bots and webhooks) to be synthesised as follows:

• Online: Gateway connected + more than 100 successful requests in the last minute
• Do not disturb: Gateway connected + more than 20 failed requests in the last minute
• Idle: (Gateway connected + less than 100 successful requests in the last minute) or (more than 20 successful webhook interactions in the last minute)
• Offline: None of the above satisfied

Visibility of presence need not be affected by this change.

[Tropony]

That sounds like it would incentivize bot operators to keep doing pointless requests simply to avoid their bot being downgraded to "idle".

[Stalruth]

If you really wanted to prevent users from stalling their bots by doing pointless presence updates, you could at least make it binary.

• Online/No presence like webhook bots: Webhook ping satisfied/Gateway connected
• Offline: Above condition not met

I think there's a reasonable argument to be made for at least allowing gateway bots the no-presence presence like how webhook bots are shown, but setting arbitrary requirements will just incentivise API abuse.

[erkinalp]

If you think of the bot's presence status as a traffic lights style indicator for its health, the proposed four-way distinction (full service/broken/limited service/no service or unknown) will make sense, albeit precise values of these thresholds might be different in an actual implementation.

[Mehgugs]

If you think of the bot's presence status as a traffic lights style indicator for its health

I think the crux of everyone's issue here is that this is not what the indicator is for.

[Stalruth]

Presences already have semantic meaning to users. Giving them an alternative meaning like this is confusing to users, as a bot being "Idle" or "Do not Disturb" is meaningless.

[bignutty]

This really just seems like an unnecessary proposal encouraging developers to spam the API for a green icon instead of a yellow one.
Forcing people to send requests is an inaccurate way of representing the bots actual status, some bots only exist to forward events onto other platforms or respond to a few events (think reaction roles or ticket tools), not even getting close to reaching the 100 request requirement per minute.

[NovaFox161]

Requiring something like N requests/minute puts way more strain in everyone. Some bots are small and even some large bots may not have anywhere close to that many requests (as mentioned several times above). I'd argue that forcing an arbitrary request count would cause more stain than that of a bot updating it's status.

And this isn't even mentioning the fact that the vast vast majority of the status update throughput is from users. Bots make up a negligible amount of that compared to the literal millions of users all updating their status at the same time.

This is a solution to a seemingly non-existent problem, that just creates additional problems.

[erkinalp]

I'd argue that forcing an arbitrary request count would cause more stain than that of a bot updating it's status.

Nothing forces you to do that. Yellow light indicator does not and will not mean the bot is not working.

[dolfies]

This idea would probably lead to even more presence updates.

Most bots don't change their status much. If the status is an indicator like this, it would change much more often.

[pro-bot-coder]

merhaba hocam ben de sizin gibi bir bot geliştiricisi ve turk'üm. İnsanlara her zaman bot yapmayı teklif ediyorum ama onlar hep benim kötü olduğumu düşünüyorlar. sizin gibiler biz namuslu türklere kötü bir isim veriyorsunuz. dizlerimin üstüne çökeceğim ve durman için yalvaracağım.