Clyde should be removed until it can adhere to the same API standards as apps

[panley01]

Clyde's implementation has been relatively controversial, in concept and execution. This is not a discussion about AI, or really even a discussion about what Clyde does. This discussion is about the various ways Clyde seems to bypass limitations that normal apps have to adhere to - and how this is an accident waiting to happen when large libraries rely on the API acting as documented and expected.

Below is a list of ways that clyde can, and does, break API conventions.

1. Clyde was able to create threads past 1,000 with no upper limit - this has since been patched
2. Clyde can create messages with no text content, no embeds, nothing.
3. Clyde can cause users to create threads without a starting message - this is usually impossible in-client but possible via the API
4. Clyde ignores permissions and will continue to respond if it has a backlog
5. Clyde seems to have no ratelimits. A raid group can effectively double their message count by abusing this
6. Clyde acts like a webhook but does not exist in server integrations
7. Clyde's user object is entirely clientside, why not make an actual app for it? Even just for show?
8. The CLYDE_ENABLED feature could be arbitrarily enabled but now cannot be disabled & prevents any changes to guild settings on guilds that manually enabled this without having the experiment.

So, what can be done? Clyde seems quite rushed, in concept and execution. There have been patches (like the >1,000 thread patch) that innately change how you interact with Clyde. If Clyde was created first as an app, and therefore forced to adhere to the same restrictions normal apps face with those restrictions observed or reflected in the final execution, I'm confident none of these issues would have existed from day one. I think Clyde should be stepped back until it proeprly respects Discord's API standards, so there's no risk of bot libraries getting data inconsistent with what they expect and throwing uncaught errors. Discord seems to care a lot about not pushing breaking changes that could cause uncaught errors in libs - why change this attitude now?

Alternatively, Clyde could stop using the API in these unexpected ways. Introduce new message types, new message flags, new thread flags, document them and give developers plenty of time to account for them. This has been done in the past with new API features. The bots & API team at Discord is consistently communicative in ways that are well above industry standard and devrel is incredible - usually. Clyde is standout here, it's something that's interacting with the API in unexpected ways that developers were given no heads up for. It's being patched rapidly to account for it doing this showing it clearly wasn't rigorously tested.

I think Clyde needs to go back to the drawing board for a while, to assess how it's actually doing what it does and if anything it does causes unexpected API behaviours. I can only see more issues being found in future with quick hotfixes having to come in from Discord before someone abuses them to crash bots. Again, these are my thoughts and opinions, this is a discussion and I'd like to hear from others. I think Discord should strive to hold their first party integrations to the same restrictions they impose on third party ones and there should be some standards and testing to prevent the behaviours we've seen from Clyde - that are usually impossible to achieve when using the Discord API.

No ill will to the team(s) at Discord working on Clyde, I understand it's very early on and things can and will change, but until Clyde can act in line with other apps on the platform or have dedicated message types/flags, it should be stepped back in my opinion.

[advaith1]

• 3 and 6 are already possible for third-party apps with the API so I don't think those are valid points for "breaking conventions"
• Why would there be a new message flag or type? Clyde just sends normal messages
• There is a new thread channel flag, but it generally does not matter to bots so I don't see a need to document that before release (as the standard process is to document it after it releases)

There is nothing that bots or libraries need to account for here - Clyde does not violate any documented behavior so there is nothing that should be causing errors in bots or libs (although it looks like some libs are/were relying on undocumented hash properties that Clyde does not currently respect but will in the future). It is standard for new features to be released without being documented or communicated to developers in advance, and I don't see any reasons for Clyde to be an exception to that.

[erkinalp]

how this is an accident waiting to happen when large libraries rely on the API acting as documented and expected.

If you are receiving an unexpected data in the response, you are supposed to ignore it, not crash due to it.

However, I agree that Clyde should have had got its own bot user and be subjected to the same restrictions bot users have.

[jhgg]

These are bugs. They will be fixed of course. It's important to note that Clyde is not an application, but a core feature of Discord. As such, Clyde may operate in unique ways/differently from other third party applications.