dasgo future: discord-api-spec

[switchupcb]

Discord released a Discord OpenAPI Specification.

Dasgo's future objective is to be solely generated using this OpenAPI specification.

Context

Prior to March 2022: @switchupcb has an idea for a growth community and requires custom Discord Bot functionality.

March 2022: @switchupcb wants to create a Discord API Wrapper in Go based on a machine readable API Spec.

https://switchupcb.com/blog/how-i-wasted-6-months-creating-disgo/#the-api-wrapper

March 2022: We created https://github.com/switchupcb/discord-api-spec because Discord did NOT provide an API Specification, but this failed due to the explanation at switchupcb/discord-api-spec#4 (comment).

Completing a JSON Discord API Specification project within the current Discord Environment will be too intensive and end up functioning in a similar manner to https://discord.com/developers/docs/topics/community-resources#api-types.

April 2022: https://github.com/switchupcb/dasgo is created to provide a direct representation of Discord API Objects in Go.

July 2022 https://github.com/switchupcb/disgo release is generated from Dasgo.

Disgo owners further promote the discussion surrounding the machine-readable API schema at discord/discord-api-docs#3235.

Disgo owner (@switchupcb) gets temporarily banned for a month after handling a critic "unprofessionally" when he documented an issue related to Gateway Rate Limit Reset Abuse.

July 2023 Discord releases the https://github.com/discord/discord-api-spec.

July 2023 https://github.com/switchupcb/disgo/releases shows Disgo development stop (mid-voice implementation).

Dasgo and Disgo halt development for some time as @switchupcb deals with homelessness.

Oct 2024 @switchupcb beats homelessness.

Feb 2025 @switchupcb is solving this problem again — not motivated by a desire to complete dasgo — but rather to finish his community.

[switchupcb]

February 7, 2025

Here is an update that helps you understand dasgo 's future.

1. Dasgo's future objective is to be solely generated using this OpenAPI specification.
2. Dasgo cannot be removed from the process of generating a Discord API Wrapper using an OpenAPI specification.
3. You — the user — are now responsible for updating dasgo (to a certain extent).

#20 (comment) contains context relevant to this update.

Objective: Generation via OpenAPI specification

This objective cannot be 100% completed at this time.

The https://github.com/discord/discord-api-spec contains issues indicating that the OpenAPI specification is missing features (e.g., discord/discord-api-spec#37).

Entitlements have been added but SKUs are incredibly complex and will be significantly delayed.
— @appellation

So, we must always use manual effort to update dasgo until this OpenAPI specification is feature complete.

So, we can autogenerate certain features (e.g., endpoints, events, codes, etc) based on the OpenAPI specification, but not the entire specification.

Objective: Generate a Discord API Wrapper in Go based on a machine-readable API specification.

We will not generate a Discord API Wrapper in Go based on a machine-readable API specification, but rather

• generate a Discord API Wrapper in Go based on a Go API Type Library,
• which is generated based on a machine-readable API specification.

Generating a Discord API Wrapper in Go based on a machine-readable API specification lowers energy costs (i.e. time, money, human mental effort) when creating a Discord bot, API wrapper, or software related to these things (e.g., other platform's API wrapper).

Here is a simple explanation.

You can theoretically use the disgo API wrapper code generator on another platform's API type library to generate an API wrapper for that platform.

Generating a Discord API Wrapper in Go based on a machine-readable API specification means there is no human-readable "separation" between the API wrapper (disgo) and the machine-readable API specification. So, the developer wouldn't be able to copy the code used to generate an API wrapper based on an API Type Library (e.g., from disgo) to another API Type Library easily.

Therefore, removing the "separation" (i.e., the type library) requires the developer to waste more energy developing Discord API wrappers and other API wrappers.

Here is a complete explanation.

The end goal of an API Wrapper is for the user to be able to input a human-readable text and output a working bot.

Generating a Discord API Wrapper in Go based on a machine-readable API specification means there is no human-readable "separation" between the API wrapper (disgo) and the machine-readable API specification. So, the developer wouldn't be able to copy the code used to generate an API wrapper based on an API Type Library (e.g., from disgo) to another API Type Library easily.

Therefore, removing the "separation" (i.e., the type library) requires the developer to waste more energy developing Discord API wrappers and other API wrappers.

dasgo is a "translation" between the Discord API machine(s) and the human-readable Go programming language when computers are conventions between people, . So, removing the "separated" dasgo "translation" layer complicates a computer convention between software developers for other people (i.e. API Wrapper developers).

Here is an example.

Input: "Create a bot that adds a role to a user when the user sends a message in channel XYZ."
Output: Bot code generated with working functionality.

Here is the reality.

Input: "Create a bot that adds a role to a user when the user sends a message in channel XYZ."
Output:

• Business Owner inputs a business function to a programmer (e.g., "create a chat server).
• Programmer of Discord API Machine programs using human-readable code to perform the business function (e.g., "create a chat server).
• Discord API Machine human-readable code gets compiled to a binary.
• Programmer of Discord API Machine documents binary compiled with human-readable code using human-readable language.
• Programmer of Bot Machine reads human-readable language documentation (of human-readable code compiled to a binary).
• Programmer of Bot Machine programs using human-readable code to perform the input (i.e. "Create a bot that adds a role...").
  • Programmer of Bot Machine must be able to interact with Discord's API machine, which requires HTTP, WebSocket, UDP/TCP logic (e.g., Disgo).
  • Programmer of the Bot Machine must be able to conceptualize how these communication protocols interact with Discord's API Machine (e.g., Dasgo).
  • Programmer of the Bot Machine must be able to use human-readable code which compiles to its own binary (e.g., Go programming language).
  • Bot Machine is binary code, but not 100% optimal due to the "human-translations" that are included in the process so the human programmer of the bot machine can create the bot.

So, using Artificial Intelligence to pattern match information such that it generates a binary code is theoretically possible. However, the human programmer may need to edit this code when the human programmer must conserve energy (e.g., money).

• So, the human programmer may use Artificial Intelligence to pattern match information such that it generates human-readable code at some point in the human process (e.g., bot using disgo, api wrapper using dasgo, type library using go, etc).
• For example, the human programmer may use Artificial Intelligence to pattern match information such that it generates human-readable code based on disgo, then edit this code instead of using the Artificial Intelligence to edit again.

So, removing dasgo from this process would complicate the human editing process and require them to use more mental energy.

Also, you cannot "copy" the rate limiting logic from disgo (which is an API consumer of the Discord API) to another API because their rate limiting logic is different.

• So, creating a code generator which generates an API Wrapper from an OpenAPI specification would not be reusable,
  -while creating a code generator which
  • generates API Wrapper from an API Type Library,
  • and an API Type Library from an OpenAPI specification,
  • may contain code generation that is reusable at a given level (e.g., API Type Library from an OpenAPI specification).

In the future, an Artificial Intelligence could ignore every human-readable concept and generate code that is 100% optimal by removing code in the binary when required. However, that future is not within the scope of this project.

Objective: You — the user — are responsible for updating dasgo.

You are responsible for keeping dasgo up-to-date for any functionality the owners of this library do not need.

So, we expect you to fix any error that you encounter.

Also, we are not aware of any errors we do not encounter.

Here is the reason for this library's maintenance process update.

• You encounter execution issues without top-down execution.
• Top-down execution disregards 100% feature completion unless 100% feature completion serves an objective.