Discord API

Package disgord provides Go bindings for the documented Discord API, and allows for a stateful Client using the Session interface, with the option of a configurable caching system or bypass the built-in caching logic all together. Create a Disgord client to get access to the REST API and gateway functionality. In the following example, we listen for new messages and respond with "hello". Session interface: https://pkg.go.dev/github.com/andersfylling/disgord?tab=doc#Session You don't have to use a callback function, channels are supported too! Never close a channel without removing the handler from Disgord, as it will cause a panic. You can control the lifetime of a handler or injected channel by in injecting a controller: disgord.HandlerCtrl. Since you are the owner of the channel, disgord will never close it for you. Disgord handles sharding for you automatically; when starting the bot, when discord demands you to scale up your shards (during runtime), etc. It also gives you control over the shard setup in case you want to run multiple instances of Disgord (in these cases you must handle scaling yourself as Disgord can not). Sharding is done behind the scenes, so you do not need to worry about any settings. Disgord will simply ask Discord for the recommended amount of shards for your bot on startup. However, to set specific amount of shards you can use the `disgord.ShardConfig` to specify a range of valid shard IDs (starts from 0). starting a bot with exactly 5 shards Running multiple instances each with 1 shard (note each instance must use unique shard ids) Handle scaling options yourself You can inject your own cache implementation. By default a read only LFU implementation is used, this should be sufficient for the average user. But you can overwrite certain methods as well! Say you dislike the implementation for MESSAGE_CREATE events, you can embed the default cache and define your own logic: > Note: if you inject your own cache, remember that the cache is also responsible for initiating the objects. > See disgord.CacheNop Whenever you call a REST method from the Session interface; the cache is always checked first. Upon a cache hit, no REST request is executed and you get the data from the cache in return. However, if this is problematic for you or there exist a bug which gives you bad/outdated data, you can bypass it by using Disgord flags. In addition to disgord.IgnoreCache, as shown above, you can pass in other flags such as: disgord.SortByID, disgord.OrderAscending, etc. You can find these flags in the flag.go file. `disgord_diagnosews` will store all the incoming and outgoing JSON data as files in the directory "diagnose-report/packets". The file format is as follows: unix_clientType_direction_shardID_operationCode_sequenceNumber[_eventName].json

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package disgo is a collection of packages for interaction with the Discord Bot and OAuth2 API. Package discord is a collection of structs and types of the Discord API. Package bot connects the Gateway/Sharding, HTTPServer, Cache, Rest & Events packages into a single high level client interface. Package gateway is used to connect and interact with the Discord Gateway. Package sharding is used to connect and interact with the Discord Gateway. Package cache provides a generic cache interface for Discord entities. Package httpserver is used to interact with the Discord outgoing webhooks for interactions. Package events provide high level events around the Discord Events. Package rest is used to interact with the Discord REST API. Package webhook provides a high level client interface for interacting with Discord webhooks. Package oauth2 provides a high level client interface for interacting with Discord oauth2. Package voice provides a high level client interface for interacting with Discord voice.

Package disgo is a collection of packages for interaction with the Discord Bot and OAuth2 API. Package discord is a collection of structs and types of the Discord API. Package bot connects the Gateway/Sharding, HTTPServer, Cache, Rest & Events packages into a single high level client interface. Package gateway is used to connect and interact with the Discord Gateway. Package sharding is used to connect and interact with the Discord Gateway. Package cache provides a generic cache interface for Discord entities. Package httpserver is used to interact with the Discord outgoing webhooks for interactions. Package events provide high level events around the Discord Events. Package rest is used to interact with the Discord REST API. Package webhook provides a high level client interface for interacting with Discord webhooks. Package oauth2 provides a high level client interface for interacting with Discord oauth2. Package voice provides a high level client interface for interacting with Discord voice.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package harmony provides an interface to the Discord API (https://discord.com/developers/docs/intro). The first thing you do with Harmony is to create a Client. NewClient does just that by returning a new Client pre-configured with sain defaults which should work fine in most cases. However, should you need a more specific configuration, you can always tweak it with optional `ClientOption`s. See the documentation of NewClient and the ClientOption type for more information on how to do so. Once you have a Client, you can start interacting with the Discord API, but some methods (such as event handlers) won't be available until you connect to Discord's Gateway. You can do so by simply calling the Connect method of the Client: It is only when successfully connected to the Gateway that your bot will appear as online and your Client will be able to receive events and send messages. Harmony's HTTP API is organized by resource. A resource maps to a core concept in the Discord world, such as a User or a Channel. Here is the list of resources you can interact with: Every interaction you can have with a resource can be accessed via methods attached to it. For example, if you wish to send a message to a channel, first access to the desired channel resource, then send the message: Endpoints that do not fall into one of those resource (creating a Guild for example, or getting valid Voice Regions) are directly available on the Client. To receive messages, use the OnMessageCreate method and give it your handler. It will be called each time a message is sent to a channel your bot is in with the message as a parameter. To register handlers for other types of events, see Client.On* methods. Note that your handlers are called in their own goroutine, meaning whatever you do inside of them won't block future events. When connecting to Discord, a session state is created with initial data sent by Discord's Gateway. As events are received by the client, this state is constantly updated so it always have the newest data available. This session state acts as a cache to avoid making requests over the HTTP API each time. If you need to get information about the current user, you can simply query the current state like so: Because this state might become memory hungry for bots that are in a very large number of servers, you can fine-tune events you want to track with the WithGatewayIntents option. State can also be completely disabled using the WithStateTracking option while creating the harmony client.

Package disgord provides Go bindings for the documented Discord API, and allows for a stateful Client using the Session interface, with the option of a configurable caching system or bypass the built-in caching logic all together. Create a Disgord session to get access to the REST API and socket functionality. In the following example, we listen for new messages and write a "hello" message when our handler function gets fired. Session interface: https://godoc.org/github.com/andersfylling/disgord/#Session Disgord also provides the option to listen for events using a channel. The setup is exactly the same as registering a function. Simply define your channel, add buffering if you need it, and register it as a handler in the `.On` method. Never close a channel without removing the handler from Disgord. You can't directly call Remove, instead you inject a controller to dictate the handler's lifetime. Since you are the owner of the channel, disgord will never close it for you. Here is what it would look like to use the channel for handling events. Please run this in a go routine unless you know what you are doing. Disgord handles sharding for you automatically; when starting the bot, when discord demands you to scale up your shards (during runtime), etc. It also gives you control over the shard setup in case you want to run multiple instances of Disgord (in these cases you must handle scaling yourself as Disgord can not). Sharding is done behind the scenes, so you do not need to worry about any settings. Disgord will simply ask Discord for the recommended amount of shards for your bot on startup. However, to set specific amount of shards you can use the `disgord.ShardConfig` to specify a range of valid shard IDs (starts from 0). starting a bot with exactly 5 shards Running multiple instances each with 1 shard (note each instance must use unique shard ids) Handle scaling options yourself > Note: if you create a CacheConfig you don't have to set every field. > Note: Only LFU is supported. > Note: Lifetime options does not currently work/do anything (yet). A part of Disgord is the control you have; while this can be a good detail for advanced Users, we recommend beginners to utilise the default configurations (by simply not editing the configuration). Example of configuring the Cache: If you just want to change a specific field, you can do so. The fields are always default values. > Note: Disabling caching for some types while activating it for others (eg. disabling Channels, but activating guild caching), can cause items extracted from the Cache to not reflect the true discord state. Example, activated guild but disabled channel caching: The guild is stored to the Cache, but it's Channels are discarded. Guild Channels are dismantled from the guild object and otherwise stored in the channel Cache to improve performance and reduce memory use. So when you extract the cached guild object, all of the channel will only hold their channel ID, and nothing more. To keep it safe and reliable, you can not directly affect the contents of the Cache. Unlike discordgo where everything is mutable, the caching in disgord is immutable. This does reduce performance as a copy must be made (only on new Cache entries), but as a performance freak, I can tell you right now that a simple struct copy is not that expensive. This also means that, as long as discord sends their events properly, the caching will always reflect the true state of discord. If there is a bug in the Cache and you keep getting the incorrect data, please file an issue at github.com/andersfylling/disgord so it can quickly be resolved(!) Whenever you call a REST method from the Session interface; the Cache is always checked first. Upon a Cache hit, no REST request is executed and you get the data from the Cache in return. However, if this is problematic for you or there exist a bug which gives you bad/outdated data, you can bypass it by using Disgord flags. In addition to disgord.IgnoreCache, as shown above, you can pass in other flags such as: disgord.SortByID, disgord.OrderAscending, etc. You can find these flags in the flag.go file. `disgord_diagnosews` will store all the incoming and outgoing JSON data as files in the directory "diagnose-report/packets". The file format is as follows: unix_clientType_direction_shardID_operationCode_sequenceNumber[_eventName].json `json_std` switches out jsoniter with the json package from the std libs. `disgord_removeDiscordMutex` replaces mutexes in discord structures with a empty mutex; removes locking behaviour and any mutex code when compiled. `disgord_parallelism` activates built-in locking in discord structure methods. Eg. Guild.AddChannel(*Channel) does not do locking by default. But if you find yourself using these discord data structures in parallel environment, you can activate the internal locking to reduce race conditions. Note that activating `disgord_parallelism` and `disgord_removeDiscordMutex` at the same time, will cause you to have no locking as `disgord_removeDiscordMutex` affects the same mutexes. `disgord_legacy` adds wrapper methods with the original discord naming. eg. For REST requests you will notice Disgord uses a consistency between update/create/get/delete/set while discord uses edit/update/modify/close/delete/remove/etc. So if you struggle find a REST method, you can enable this build tag to gain access to mentioned wrappers. `disgordperf` does some low level tweaking that can help boost json unmarshalling and drops json validation from Discord responses/events. Other optimizations might take place as well. `disgord_websocket_gorilla` replaces nhooyr/websocket dependency with gorilla/websocket for gateway communication. In addition to the typical REST endpoints for deleting data, you can also use Client/Session.DeleteFromDiscord(...) for basic deletions. If you need to delete a specific range of messages, or anything complex as that; you can't use .DeleteFromDiscord(...). Not every struct has implemented the interface that allows you to call DeleteFromDiscord. Do not fret, if you try to pass a type that doesn't qualify, you get a compile error.

Package disgord provides Go bindings for the documented Discord API, and allows for a stateful Client using the Session interface, with the option of a configurable caching system or bypass the built-in caching logic all together. Create a Disgord client to get access to the REST API and gateway functionality. In the following example, we listen for new messages and respond with "hello". Session interface: https://pkg.go.dev/github.com/andersfylling/disgord?tab=doc#Session You don't have to use a callback function, channels are supported too! Never close a channel without removing the handler from Disgord, as it will cause a panic. You can control the lifetime of a handler or injected channel by in injecting a controller: disgord.HandlerCtrl. Since you are the owner of the channel, disgord will never close it for you. Disgord handles sharding for you automatically; when starting the bot, when discord demands you to scale up your shards (during runtime), etc. It also gives you control over the shard setup in case you want to run multiple instances of Disgord (in these cases you must handle scaling yourself as Disgord can not). Sharding is done behind the scenes, so you do not need to worry about any settings. Disgord will simply ask Discord for the recommended amount of shards for your bot on startup. However, to set specific amount of shards you can use the `disgord.ShardConfig` to specify a range of valid shard IDs (starts from 0). starting a bot with exactly 5 shards Running multiple instances each with 1 shard (note each instance must use unique shard ids) Handle scaling options yourself You can inject your own cache implementation. By default a read only LFU implementation is used, this should be sufficient for the average user. But you can overwrite certain methods as well! Say you dislike the implementation for MESSAGE_CREATE events, you can embed the default cache and define your own logic: > Note: if you inject your own cache, remember that the cache is also responsible for initiating the objects. > See disgord.CacheNop Whenever you call a REST method from the Session interface; the cache is always checked first. Upon a cache hit, no REST request is executed and you get the data from the cache in return. However, if this is problematic for you or there exist a bug which gives you bad/outdated data, you can bypass it by using Disgord flags. In addition to disgord.IgnoreCache, as shown above, you can pass in other flags such as: disgord.SortByID, disgord.OrderAscending, etc. You can find these flags in the flag.go file. `disgord_diagnosews` will store all the incoming and outgoing JSON data as files in the directory "diagnose-report/packets". The file format is as follows: unix_clientType_direction_shardID_operationCode_sequenceNumber[_eventName].json

Align is a scheduling tool that allows users to schedule events with other users. It is designed to be modular, so that users can easily receive schedule reminders and updates through different platforms. Align's configuration file has settings described below: ```yaml settings: persons: name: "Person 1" # Name of the person request_method: "discord" # Method to request information from response_method: "discord" # Method to respond with information id: "PERSONS_ID" # Identifiying string for the person (Discord ID, Telegram ID, etc.) name: "Person 2" ... ``` Currently, the `request_method` and `response_methods` must be the same value, but this will be changed in future updates. Examples for each module can be found in the 'examples/' directory. These directories contain the most barebones setup align needs to function. If you are using align in a more complicated package, you can provide the same types in the examples to get align working. ## SQL Align has an option to use SQL to store availability data. This is useful if align ever stops running (server resetting, power outages, etc). If align is restarted without persisting data, the availability data may be lost, and the subsequent schedule alignment may be incorrect (align tries to mitigate this fact as much as possible, but some necessary data cannot be recovered in this case, such as discord message IDs). You can provide SQL credentials to the align configuration file to use SQL. The yaml format is as follows: ```yaml sql: ``` ## Discord Discord is easy to set up with align. Simply providing a Discord session to align will allow it to send and receive messages. Keep in mind that, in order for a Discord bot to send a message to a user, it must be in a mutual server with said user. This is a limitation of the Discord API, and align cannot bypass this. To collect Discord IDs, you can right click on a profile you want to contact and click 'Copy User ID.' You can provide this information to align's configuration file. ## Telegram To initialize telegram with align, you can start a telegram session using [telegram-bot-api](https://github.com/go-telegram-bot-api/telegram-bot-api). This package is used to interact with the Telegram Bot API. Once you have started this session, align can use it to send and receive messages for easy and convienient scheduling. However, Telegram is more difficult to set up and maintain with align. These constraints originate from the [Telegram Bot API](https://core.telegram.org/bots/api) itself. These reasons are: * Telegram bots are not allowed to send messages to users who have not initiated some sort of conversation with the bot * Telegram servers only store updates for 24 hours, so if the bot is down for more than 24 hours, it may not receive poll updates So, to use Telegram with align, you must: * Have users initiate a conversation with the bot using '/start', or clicking the bottom of the bar when messaging the bot. The bot does not have to be online, but it must be activated within 24 hours to receive the update * Keep the bot online at least once every 24 hours so it can receive updates from telegram. If the bot is down for more than 24 hours, it may not receive poll updates and return incorrect schedule times The best way to do this in practice is to approach the user you want to contact using Telegram and have them start a conversation with the bot while the bot is online (or during the 24 hour update period). This way, the bot can send messages to the user without any issues. Secondly, you need to receive this user's Telegram User ID (not username). This can be done by having that user message '@userinfobot', clicking 'start', and recording the 'User Id Information' field.

Package cchat is a set of stabilized interfaces for cchat implementations, joining the backend and frontend together. Almost anything in the backend comes with an ID. For example, a Server must have an ID, or a Session must have a user ID. The backend is required to guarantee that IDs are somehow unique. This should already be the case for most chat services; for example, Discord provides IDs for guilds, channels, members, and more. The only time that the backend should not guarantee ID uniqueness is across Sessions, because it doesn't make sense to do so. In this case, the frontend should guarantee uniqueness instead, either by discarding duplicated items, overriding them, or anything reasonable and explicit. Methods implemented by the backend that have frontend containers as arguments can do IO. Frontends must NOT rely on individual backend states and should always assume that they will block. Methods that do not return an error must NOT do any IO to prevent blocking the main thread. As such, ID() and Name() must never do any IO. Methods that do return an error may do IO, but they should be documented per method. Backend implementations have certain conditions that should be adhered to: Note: IO in most cases usually refer to networking, but they should files and anything that is blocking, such as mutexes or semaphores. Note: As mentioned above, contexts are optional for both the frontend and backend. The frontend may use it for cancellation, and the backend may ignore it. Some interfaces can be extended. Interfaces that are extendable will have methods starting with "As" and returns another interface type. The implementation may or may not return the same struct as the interface, but the caller should not have to type assert it to a struct. They can also return nil, which should indicate the backend that the feature is not implemented. To avoid confusing, when said "A implements B," it is mostly assumed that A has a method named "AsB." It does not mean that A can be type-asserted to B. For future references, these "As" methods will be called asserter methods. Note: Backends must not do IO in the "As" methods. Most of the time, it should only conditionally check the local state and return value or nil. Below is an example of checking for an extended interface. Frontend contains all interfaces that a frontend can or must implement. The backend may call these methods any time from any goroutine. Thus, they should be thread-safe. They should also not block the call by doing so, as backends may call these methods in its own main thread. It is worth pointing out that frontend container interfaces will not have an error handling API, as frontends can do that themselves. Errors returned by backend methods will be errors from the backend itself and never the frontend errors.

Package fasthttp provides fast HTTP server and client API. Fasthttp provides the following features: Optimized for speed. Easily handles more than 100K qps and more than 1M concurrent keep-alive connections on modern hardware. Optimized for low memory usage. Easy 'Connection: Upgrade' support via RequestCtx.Hijack. Server provides the following anti-DoS limits: The number of concurrent connections. The number of concurrent connections per client IP. The number of requests per connection. Request read timeout. Response write timeout. Maximum request header size. Maximum request body size. Maximum request execution time. Maximum keep-alive connection lifetime. Early filtering out non-GET requests. A lot of additional useful info is exposed to request handler: Server and client address. Per-request logger. Unique request id. Request start time. Connection start time. Request sequence number for the current connection. Client supports automatic retry on idempotent requests' failure. Fasthttp API is designed with the ability to extend existing client and server implementations or to write custom client and server implementations from scratch.

Package kafka a provides high level client API for Apache Kafka. Use 'Broker' for node connection management, 'Producer' for sending messages, and 'Consumer' for fetching. All those structures implement Client, Consumer and Producer interface, that is also implemented in kafkatest package.

Gordie is a simple wrapper over the Discord API. It aims to be fully complete but also easy to use.

Package botbuilder allows for simple Discord bot initialization utilizing the builder pattern. The Discord API functionality is provided by a well-known package discorsessiono.

Package harmony provides an interface to the Discord API (https://discord.com/developers/docs/intro). The first thing you do with Harmony is to create a Client. NewClient does just that by returning a new Client pre-configured with sain defaults which should work fine in most cases. However, should you need a more specific configuration, you can always tweak it with optional `ClientOption`s. See the documentation of NewClient and the ClientOption type for more information on how to do so. Once you have a Client, you can start interacting with the Discord API, but some methods (such as event handlers) won't be available until you connect to Discord's Gateway. You can do so by simply calling the Connect method of the Client: It is only when successfully connected to the Gateway that your bot will appear as online and your Client will be able to receive events and send messages. Harmony's HTTP API is organized by resource. A resource maps to a core concept in the Discord world, such as a User or a Channel. Here is the list of resources you can interact with: Every interaction you can have with a resource can be accessed via methods attached to it. For example, if you wish to send a message to a channel, first access to the desired channel resource, then send the message: Endpoints that do not fall into one of those resource (creating a Guild for example, or getting valid Voice Regions) are directly available on the Client. To receive messages, use the OnMessageCreate method and give it your handler. It will be called each time a message is sent to a channel your bot is in with the message as a parameter. To register handlers for other types of events, see Client.On* methods. Note that your handlers are called in their own goroutine, meaning whatever you do inside of them won't block future events. When connecting to Discord, a session state is created with initial data sent by Discord's Gateway. As events are received by the client, this state is constantly updated so it always have the newest data available. This session state acts as a cache to avoid making requests over the HTTP API each time. If you need to get information about the current user, you can simply query the current state like so: Because this state might become memory hungry for bots that are in a very large number of servers, you can fine-tune events you want to track with the WithGatewayIntents option. State can also be completely disabled using the WithStateTracking option while creating the harmony client.

Package discord implements an HTTP API client for OAuth2 flow.

Package null implements nullable types for use with Discord's API.

Package ratelimit implements a bucket-based ratelimiter for Discord's HTTP REST API.

Package beelzebub implements a REST API client for Discord.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package disgord provides Go bindings for the documented Discord API, and allows for a stateful Client using the Session interface, with the option of a configurable caching system or bypass the built-in caching logic all together. Create a Disgord session to get access to the REST API and socket functionality. In the following example, we listen for new messages and write a "hello" message when our handler function gets fired. Session interface: https://godoc.org/github.com/LaevusDexter/disgord/#Session Disgord also provides the option to listen for events using a channel. The setup is exactly the same as registering a function. Simply define your channel, add buffering if you need it, and register it as a handler in the `.On` method. Never close a channel without removing the handler from Disgord. You can't directly call Remove, instead you inject a controller to dictate the handler's lifetime. Since you are the owner of the channel, disgord will never close it for you. Here is what it would look like to use the channel for handling events. Please run this in a go routine unless you know what you are doing. Disgord handles sharding for you automatically; when starting the bot, when discord demands you to scale up your shards (during runtime), etc. It also gives you control over the shard setup in case you want to run multiple instances of Disgord (in these cases you must handle scaling yourself as Disgord can not). Sharding is done behind the scenes, so you do not need to worry about any settings. Disgord will simply ask Discord for the recommended amount of shards for your bot on startup. However, to set specific amount of shards you can use the `disgord.ShardConfig` to specify a range of valid shard IDs (starts from 0). starting a bot with exactly 5 shards Running multiple instances each with 1 shard (note each instance must use unique shard ids) Handle scaling options yourself > Note: if you create a CacheConfig you don't have to set every field. > Note: Only LFU is supported. > Note: Lifetime options does not currently work/do anything (yet). A part of Disgord is the control you have; while this can be a good detail for advanced users, we recommend beginners to utilise the default configurations (by simply not editing the configuration). Example of configuring the cache: If you just want to change a specific field, you can do so. The fields are always default values. > Note: Disabling caching for some types while activating it for others (eg. disabling channels, but activating guild caching), can cause items extracted from the cache to not reflect the true discord state. Example, activated guild but disabled channel caching: The guild is stored to the cache, but it's channels are discarded. Guild channels are dismantled from the guild object and otherwise stored in the channel cache to improve performance and reduce memory use. So when you extract the cached guild object, all of the channel will only hold their channel ID, and nothing more. To keep it safe and reliable, you can not directly affect the contents of the cache. Unlike discordgo where everything is mutable, the caching in disgord is immutable. This does reduce performance as a copy must be made (only on new cache entries), but as a performance freak, I can tell you right now that a simple struct copy is not that expensive. This also means that, as long as discord sends their events properly, the caching will always reflect the true state of discord. If there is a bug in the cache and you keep getting the incorrect data, please file an issue at github.com/LaevusDexter/disgord so it can quickly be resolved(!) Whenever you call a REST method from the Session interface; the cache is always checked first. Upon a cache hit, no REST request is executed and you get the data from the cache in return. However, if this is problematic for you or there exist a bug which gives you bad/outdated data, you can bypass it by using Disgord flags. In addition to disgord.IgnoreCache, as shown above, you can pass in other flags such as: disgord.SortByID, disgord.OrderAscending, etc. You can find these flags in the flag.go file. `disgord_diagnosews` will store all the incoming and outgoing JSON data as files in the directory "diagnose-report/packets". The file format is as follows: unix_clientType_direction_shardID_operationCode_sequenceNumber[_eventName].json `json_std` switches out jsoniter with the json package from the std libs. `disgord_removeDiscordMutex` replaces mutexes in discord structures with a empty mutex; removes locking behaviour and any mutex code when compiled. `disgord_parallelism` activates built-in locking in discord structure methods. Eg. Guild.AddChannel(*Channel) does not do locking by default. But if you find yourself using these discord data structures in parallel environment, you can activate the internal locking to reduce race conditions. Note that activating `disgord_parallelism` and `disgord_removeDiscordMutex` at the same time, will cause you to have no locking as `disgord_removeDiscordMutex` affects the same mutexes. `disgord_legacy` adds wrapper methods with the original discord naming. eg. For REST requests you will notice Disgord uses a consistency between update/create/get/delete/set while discord uses edit/update/modify/close/delete/remove/etc. So if you struggle find a REST method, you can enable this build tag to gain access to mentioned wrappers. `disgordperf` does some low level tweaking that can help boost json unmarshalling and drops json validation from Discord responses/events. Other optimizations might take place as well. `disgord_websocket_gorilla` replaces nhooyr/websocket dependency with gorilla/websocket for gateway communication. In addition to the typical REST endpoints for deleting data, you can also use Client/Session.DeleteFromDiscord(...) for basic deletions. If you need to delete a specific range of messages, or anything complex as that; you can't use .DeleteFromDiscord(...). Not every struct has implemented the interface that allows you to call DeleteFromDiscord. Do not fret, if you try to pass a type that doesn't qualify, you get a compile error.

Package cchat is a set of stabilized interfaces for cchat implementations, joining the backend and frontend together. Almost anything in the backend comes with an ID. For example, a Server must have an ID, or a Session must have a user ID. The backend is required to guarantee that IDs are somehow unique. This should already be the case for most chat services; for example, Discord provides IDs for guilds, channels, members, and more. The only time that the backend should not guarantee ID uniqueness is across Sessions, because it doesn't make sense to do so. In this case, the frontend should guarantee uniqueness instead, either by discarding duplicated items, overriding them, or anything reasonable and explicit. Methods implemented by the backend that have frontend containers as arguments can do IO. Frontends must NOT rely on individual backend states and should always assume that they will block. Methods that do not return an error must NOT do any IO to prevent blocking the main thread. As such, ID() and Name() must never do any IO. Methods that do return an error may do IO, but they should be documented per method. Backend implementations have certain conditions that should be adhered to: Note: IO in most cases usually refer to networking, but they should files and anything that is blocking, such as mutexes or semaphores. Note: As mentioned above, contexts are optional for both the frontend and backend. The frontend may use it for cancellation, and the backend may ignore it. Some interfaces can be extended. Interfaces that are extendable will have methods starting with "As" and returns another interface type. The implementation may or may not return the same struct as the interface, but the caller should not have to type assert it to a struct. They can also return nil, which should indicate the backend that the feature is not implemented. To avoid confusing, when said "A implements B," it is mostly assumed that A has a method named "AsB." It does not mean that A can be type-asserted to B. For future references, these "As" methods will be called asserter methods. Note: Backends must not do IO in the "As" methods. Most of the time, it should only conditionally check the local state and return value or nil. Below is an example of checking for an extended interface. Frontend contains all interfaces that a frontend can or must implement. The backend may call these methods any time from any goroutine. Thus, they should be thread-safe. They should also not block the call by doing so, as backends may call these methods in its own main thread. It is worth pointing out that frontend container interfaces will not have an error handling API, as frontends can do that themselves. Errors returned by backend methods will be errors from the backend itself and never the frontend errors.

Package disgord provides Go bindings for the documented Discord API, and allows for a stateful Client using the Session interface, with the option of a configurable caching system or bypass the built-in caching logic all together. Create a Disgord client to get access to the REST API and gateway functionality. In the following example, we listen for new messages and respond with "hello". Session interface: https://pkg.go.dev/github.com/Vedza/disgord?tab=doc#Session You don't have to use a callback function, channels are supported too! Never close a channel without removing the handler from Disgord, as it will cause a panic. You can control the lifetime of a handler or injected channel by in injecting a controller: disgord.HandlerCtrl. Since you are the owner of the channel, disgord will never close it for you. Disgord handles sharding for you automatically; when starting the bot, when discord demands you to scale up your shards (during runtime), etc. It also gives you control over the shard setup in case you want to run multiple instances of Disgord (in these cases you must handle scaling yourself as Disgord can not). Sharding is done behind the scenes, so you do not need to worry about any settings. Disgord will simply ask Discord for the recommended amount of shards for your bot on startup. However, to set specific amount of shards you can use the `disgord.ShardConfig` to specify a range of valid shard IDs (starts from 0). starting a bot with exactly 5 shards Running multiple instances each with 1 shard (note each instance must use unique shard ids) Handle scaling options yourself You can inject your own cache implementation. By default a read only LFU implementation is used, this should be sufficient for the average user. But you can overwrite certain methods as well! Say you dislike the implementation for MESSAGE_CREATE events, you can embed the default cache and define your own logic: > Note: if you inject your own cache, remember that the cache is also responsible for initiating the objects. > See disgord.CacheNop Whenever you call a REST method from the Session interface; the cache is always checked first. Upon a cache hit, no REST request is executed and you get the data from the cache in return. However, if this is problematic for you or there exist a bug which gives you bad/outdated data, you can bypass it by using Disgord flags. In addition to disgord.IgnoreCache, as shown above, you can pass in other flags such as: disgord.SortByID, disgord.OrderAscending, etc. You can find these flags in the flag.go file. `disgord_diagnosews` will store all the incoming and outgoing JSON data as files in the directory "diagnose-report/packets". The file format is as follows: unix_clientType_direction_shardID_operationCode_sequenceNumber[_eventName].json `disgordperf` does some low level tweaking that can help boost json unmarshalling and drops json validation from Discord responses/events. Other optimizations might take place as well.

discord.go is a wrapper for bwmarrin/discordgo to enable a few "oh that's neat" functions. d.g is heavily context-based and focues on bot development. The goal is that all functionality a bot might need is provided out of the box and can be used without having to think about the discord API. To start a new bot, simply call NewBot with the token for your bot and you're basically good to go. An example bot is provided in example/helloworld

Package discord provides a Discord API client. A simple program that sends "Hello, World!" to a user.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.

Package pgo provides a set of commands that access the Politics And War API for information. All commands take a slice of strings as arguments and returns a string as an output This package is not meant to be used directly, but is instead meant to be used as a command line interface, which is located in pgo/cmd/pgo. A version that can be run as a discord bot is also availible in pgo/cmd/pgo-discord.

Package drpc is a small implementation of the Discord RPC server. The only supported commands are handshake and set activity. The general API structure could be put like so:

Package swgoh and it's subfolders contains implementations to parse and interact with EA's game "Star Wars Galaxy of Heroes". Game developers allow certain data to be otainable from associated API (Application Programming Interface) developed and hosted by third-parties. The two main API providers are https://swgoh.gg/api and https://api.swgoh.help, each with specific goodies and behavior but both allowing public data from each player account to be queried. This package contains client-side Go implementations for both APIs as well as some developer friendly goodies such as built-in cache using etcd BoltDB, helper methods to filer characters and mods, helper methods to "guess" character aliases and "slang" generally used by players, and a few others. The cmd/swgoh program provided with the source code contains also a reference implementation that allows one to query data from the CLI (command-line interface). To learn more about this implementation, please join our Discord server channel at the SWGOH.HELP server:

Package swgoh and it's subfolders contains implementations to parse and interact with EA's game "Star Wars Galaxy of Heroes". Game developers allow certain data to be otainable from associated API (Application Programming Interface) developed and hosted by third-parties. The two main API providers are https://swgoh.gg/api and https://api.swgoh.help, each with specific goodies and behavior but both allowing public data from each player account to be queried. This package contains client-side Go implementations for both APIs as well as some developer friendly goodies such as built-in cache using etcd BoltDB, helper methods to filer characters and mods, helper methods to "guess" character aliases and "slang" generally used by players, and a few others. The cmd/swgoh program provided with the source code contains also a reference implementation that allows one to query data from the CLI (command-line interface). To learn more about this implementation, please join our Discord server channel at the SWGOH.HELP server:

Package discord provides an interface to the Discord API (https://discordapp.com/developers/docs/intro). The first thing you do is to create a Client. For a normal user, you can get one like this: If you want to create a client for a bot, use WithBotToken instead of WithToken, without prefixing the token with "Bot :": You can pass more configuration parameters to NewClient. Review the documentation of NewClient for more information. With this client, you can start interacting with the Discord API, but some methods (such as event handlers) won't be available until you connect to the Gateway: Once connected to the Gateway, you have full access to the Discord API. Discord's HTTP API is organized by resource: Each resource has its own method on the Client to interact with. For example, to send a message to a channel: To receive messages, use the HandleMessageCreate method and give it your handler. It will be called each time a message is sent to a channel your bot is in with the message as a parameter. To register handlers for other types of events, see Client.Handle* methods. When connecting to Discord, a session state is created with initial data sent by Discord's Gateway. As events are received by the client, this state is constantly updated so it always have the newest data available. This session state acts as a cache to avoid making requests over the HTTP API each time. If you need to get information about the current user : Because this state might become memory hungry for bots that are in a very large number of servers, it can be disabled with the WithStateTracking option while creating the Discord client.

Package arikawa contains a set of modular packages that allows you to make a Discord bot or any type of session (OAuth unsupported). Package session is the most simple abstraction, which combines the API package and the Gateway websocket package together into one. This could be used for minimal bots that only use gateway events and such. Package state abstracts on top of session and provides a local cache of API calls and events. Bots that either don't need a command router or already has its own should use this package. Package bot abstracts on top of state and provides a command router based on Go code. This is similar to discord.py's API, only it's Go and there's no optional arguments (yet, although it could be worked around). Most bots are recommended to use this package, as it's the easiest way to make a bot. Package voice provides an abstraction on top of State and adds voice support. This allows bots to join voice channels and talk. The package uses an io.Writer approach rather than a channel, contrary to other Discord libraries.