README
U
AllowedMentionType
U
AllowedMentions
U
AllowedMentionsError
U
App
U
AppBuilder
U
AppConfigError
U
AppCtx
U
AppWarning
U
ApplicationRef
U
Arg
U
Args
U
Bot
U
BotBuilder
U
BotConfigError
U
BotError
U
BotSession
U
CacheLimit
U
CacheLimits
U
CacheResources
U
ChannelRef
U
CheckCtx
U
Client
U
Command
U
CommandCheck
U
CommandPlan
U
CommandReply
U
CommandScope
U
ComponentCtx
U
ComponentDeferredCtx
U
ComponentHandler
U
ComponentImmediateCtx
U
ComponentReply
U
ComponentRoute
U
CooldownBucket
U
CooldownOutage
U
CustomIdCodec
U
CustomIdError
U
DeferredCtx
U
DiscordHttpError
U
ErrorPolicy
U
Event
U
EventMiddleware
U
EventType
U
Events
U
FailureCtx
U
FailureOrigin
U
FileUpload
U
GatewayCapabilities
U
GatewayCompression
U
GatewayCtx
U
GuildInvocation
U
GuildRef
U
HandlerError
U
HandlerIntake
U
ImmediateCtx
U
InMemoryCache
U
InitialResponse
U
Intents
U
InteractionCtx
U
InteractionEndpoint
U
InteractionHandler
U
InteractionHttpBody
U
InteractionHttpRequest
U
InteractionHttpResponse
U
InteractionOutcome
U
InteractionTarget
U
InteractionVerifier
U
InteractionVerifierError
U
InteractionsServer
U
InvocationScope
U
MemberRef
U
MessageRef
U
MessageUpdate
U
Modal
U
ModalDeferredCtx
U
ModalField
U
ModalFields
U
ModalHandle
U
ModalImmediateCtx
U
ModalOrigin
U
ModalReply
U
ModalShowError
U
ModalSubmitHandler
U
PendingEvent
U
ResponseState
U
RestAccess
U
ServerConfigError
U
ShardConfig
U
SlashChild
U
SuggestCtx
U
SyncReport
U
TargetUser
U
UserRef
U
WaitFrom
V
API_VERSION
V
action_row
V
arg_attachment
V
arg_bool
V
arg_channel
V
arg_int
V
arg_int32
V
arg_mentionable
V
arg_number
V
arg_role
V
arg_string
V
arg_user
V
button
V
channel_select
V
component_route
V
container
V
dm_only
V
file_field
V
file_upload
V
guild_only
V
int_choice
V
label
V
link_button
V
media_gallery
V
media_item
V
mentionable_select
V
message_command
V
modal
V
number_choice
V
required_permissions
V
role_select
V
section
V
select_field
V
select_option
V
separator
V
serve_interactions
V
slash
V
slash_group
V
string_choice
V
string_select
V
subcommand
V
subcommand_group
V
text_display
V
text_field
V
text_input
V
thumbnail
V
user_command
V
user_select
V
verify_signature

discord

An experimental Discord library for MoonBit: native/JS/Wasm REST, interactions, and gateway bots. Voice is in gaato/discord_voice.

discord

bot

gateway

api

interactions

Download zip

Author

gaato

Version

0.11.0

License

Apache-2.0

Repository

github.com/gaato/discord.mbt

Last updated

1 hour ago

Downloads

158

Dependencies

#discord.mbt

A Discord application library for MoonBit: typed interaction declarations, API models, a rate-limited REST client, native/JS/moonrun Wasm HTTP interactions and WebSocket gateway shards.

The design follows twilight: loosely coupled packages that model the Discord API, plus an App layer for typed interaction declarations.

Status: experimental. Minor releases may contain breaking changes; see the changelog for migration notes.

Long-form guides live in the repository's guide/; their code blocks compile and run as part of the test suite, so the examples cannot drift from the library. Task-focused recipes are docstring examples on the relevant symbols — look anything up with moon ide doc (see Development).

#Prerequisites

On a clean machine, install git and run moon update before resolving the module dependencies. Moon uses git to clone the package registry.

The ghcr.io/gaato/moonbit toolchain image bundles the pinned toolchain with Node.js 24, gcc, and git; the repository's .devcontainer starts from it, CI runs in it (except the Rust voice shim job), and template/Dockerfile uses it as the builder stage for a distroless bot image.

#Install

moon update
moon add gaato/discord

The interaction App, REST client, data packages, and gateway Bot executor support native, JavaScript, and linear-memory Wasm on moonrun. Voice is native-only. These executors use moonbitlang/async.

#Quickstart

Build the interaction App, then pass it to the gateway Bot executor. This example registers and answers a /echo command. See examples/slash_echo for the runnable version.

///|
struct QuickstartEchoArgs {
  text : String
  times : Int32
}

///|
async fn run_echo_bot(token : String) -> Unit {
  let args : @discord.Args[QuickstartEchoArgs] = @discord.Args::map2(
    @discord.arg_string(name="text", description="What to echo"),
    @discord.arg_int32(
      name="times",
      description="How many times (1-5)",
      min=1,
      max=5,
    ).with_default(1),
    (text, times) => { text, times, },
  )
  let echo = @discord.slash(
    name="echo",
    description="Echo your text back",
    args~,
    handler=Immediate((_ctx, value) => {
      @discord.CommandReply::message(
        content=Array::make(value.times, value.text).join("\n"),
      )
    }),
  )
  let app = @discord.AppBuilder()
  app.command(echo)
  let bot = @discord.BotBuilder(app.build(), token~, sync=Global)
  bot.on(@discord.Events::ready(), (_ctx, ready) => {
    println("ready as \{ready.user.username}")
  })
  bot.build().run()
}

#Packages

Package	What it is	Native	JS	Wasm¹
gaato/discord	Facade: golden-path names a typical application uses directly	Yes	Yes²	Yes²
gaato/discord/model	Pure data: ~24 entity domains, gateway payloads, zero IO	Yes	Yes	Yes
gaato/discord/telemetry	Structured REST, gateway, and dispatch observability values	Yes	Yes	Yes
gaato/discord/http	REST Client, routes, rate limiting, multipart uploads	Yes	Yes	Yes
gaato/discord/gateway	Shard: connection state machine, heartbeat, resume	Yes	Yes	Yes
gaato/discord/interaction	Command/component builders, typed args and autocomplete data	Yes	Yes	Yes
gaato/discord/framework	Interaction routing, response gates, low-level response contexts	Yes	Yes	Yes
gaato/discord/app	Gateway-free typed commands/components/modals, HTTP endpoint, sync and policy	Yes	Yes	Yes
gaato/discord/bot	Gateway executor and typed gateway event descriptors	Yes	Yes	Yes
gaato/discord/endpoint_http	Signed-interactions HTTP server (serve_interactions)	Yes	No	Yes
gaato/discord/cache	Opt-in, gateway-driven in-memory cache	Yes	Yes	Yes
gaato/discord/util	Pure helpers: permissions, mentions, timestamps, CDN URLs	Yes	Yes	Yes
gaato/discord/verify	Pure MoonBit Ed25519 request verification	Yes	Yes	Yes
gaato/discord/ratelimit	In-memory Discord rate limiter for the gaato/sdk-runtime RateLimiter trait	Yes	Yes	Yes
gaato/discord/cooldown	Command cooldown store trait + in-memory fixed windows	Yes	Yes	Yes
gaato/discord/queue	Identify queue trait + in-memory implementation	Yes	Yes	Yes
gaato/discord/coordinator	Experimental TCP coordinator for multi-process Identify, REST limits, and cooldowns	Yes	No	Yes
gaato/discord/testkit	Deterministic interaction and model fixtures	Yes	Yes	Yes

¹ Linear-memory Wasm run by moonrun. The host imports come from moonbitlang/async, so generic WASI runtimes, browsers, and wasm-gc are not targets. See Wasm runtime and permissions.

² The HTTP-server exports exist on native and Wasm. Packages that are empty on a backend do not provide that feature, even if Moon accepts them as dependencies. Voice (gaato/discord_voice) is native-only.

#Wasm runtime and permissions

Use --target wasm with the pinned MoonBit toolchain and its matching moonrun. This backend uses MoonBit host APIs for sockets, TLS, timers, and environment variables; it is not a browser, generic WASI, or wasm-gc application target.

The interactions_http example also builds for Wasm:

moon build --target wasm --release examples/interactions_http
moonrun --policy discord-policy.json _build/wasm/release/build/local/discord_examples/interactions_http/interactions_http.wasm

An example discord-policy.json for that server:

{
  "env": {
    "required_from_host": ["DISCORD_TOKEN", "PUBLIC_KEY"],
    "from_host": ["GUILD_ID"],
    "set": {"PORT": "8080"}
  },
  "net": {
    "connect": ["discord.com:443"],
    "bind": ["0.0.0.0:8080"]
  }
}

Supply credentials through the environment, never in the policy file. This example synchronizes commands at startup; run it only when you intend to update your application's commands. A REST-only program needs the token and outbound connection permission but no bind permission. The coordinator needs bind permission on its server address and connect permission on each client. Add other destinations only for features that actually need them. In policy mode, omitted environment, filesystem, network, and process permissions are denied.

Packages remain usable on their own. Import only what the program needs:

The facade follows the typical bot's golden path. Import the focused http, framework, gateway, coordinator, telemetry, or interaction package for resource refs, pagination, low-level routing and raw contexts, shard transport, coordination, observability events, or raw option declarations.

REST-only tool: http (brings model).
Serverless HTTP interactions (Cloudflare Workers, Deno, Bun, and Node.js Functions, JS): app and verify.
Native HTTP interactions server: endpoint_http.
Gateway bot: bot, or the gaato/discord facade for everything.

#Examples

Runnable programs live in the repository's examples/ workspace module; run them from the repository root, for example moon run --target native examples/slash_echo:

slash_echo: minimal typed Gateway bot.
kitchen_sink: subcommands, autocomplete, context menus, components, and modals.
ping_gateway: low-level Gateway and REST use.
low_level: manual Framework and Shard wiring.
workers_echo: Cloudflare Workers adapter.
deno_echo: Deno adapter for the same MoonBit interaction App.
bun_echo: Bun HTTP server adapter for the same interaction App.
vercel_echo: Vercel Node.js Function adapter for the same interaction App.
fastly_echo: Fastly FetchEvent entry point experiment.
lambda_url_echo: Lambda Function URL payload v2 adapter experiment.
workers_gateway: Cloudflare Durable Object running a gateway bot (no voice).
interactions_http: native signed-interactions HTTP server.
experiments/spin_interactions: WASIp2 Spin component for signed PING and immediate echo; this experiment sits outside examples/.
plugin_demo: a stateful feedback feature installed as a separate package.
gate_probe: live probe for error-policy recovery and user-restricted component waits (needs a Discord client; guild commands only).
voice_player: join a voice channel and play an Ogg/Opus file.
voice_recorder: record a user's voice to an Ogg/Opus file.

#App core and executors

An AppBuilder collects the interaction declaration: commands, components, modals, autocomplete routes, middleware, and the error policy. build() validates it into an immutable App, which has no gateway dependency. Hand the App to an executor:

BotBuilder(app, token~) collects gateway event handlers and services; build() validates it into a Bot, whose run() connects to the gateway and routes InteractionCreate events through the App.
app.serve(group, access=Token(token)) creates an InteractionEndpoint for an HTTP adapter.

Both executors use the same handlers, so an application can move between a persistent gateway process and an HTTP or serverless deployment without rewriting its interaction declarations.

Command[A] pairs one handler with Args[A]; the argument value drives both Discord's registration payload and interaction decoding (build records with Args::map1 through Args::map8). Choose a handler mode against Discord's three-second initial-response deadline: Immediate computes and returns a CommandReply before it, Deferred acknowledges first and continues on a DeferredCtx, and Raw receives the underlying CommandCtx for imperative flows. Subcommands carry their own typed Args, autocomplete attaches directly to the focused argument, and context-menu commands, components, and typed modals route through the same App — see the commands and components and modals guides.

Client, AppBuilder, and BotBuilder each accept onion-style middleware — around one logical REST call, around routed interaction dispatch, and around gateway event fan-out — plus structured telemetry callbacks. See the middleware guide.

#Gateway executor

BotBuilder adds typed gateway event subscriptions and services:

bot.on(@discord.Events::message_create(), (ctx, event) => {
  let message = event.message
  println("\{message.author.username}: \{message.content}")
})

If intents is omitted, Bot derives non-privileged intents from typed subscriptions; pass privileged intents (members, presences, message content) explicitly, and pass the full set when raw event handlers are used. ctx.wait_for(...) makes one-shot typed event observations inside a handler. The events and intents guide covers descriptors, intent derivation, decode-error observers, opt-in zstd-stream and zlib-stream compression, and the gateway-driven in-memory cache.

Several shards can run in one process behind the same dispatch path, so handlers, the cache, collectors, and telemetry observe every shard:

///|
let bot = @discord.BotBuilder(app, token~, shards=Auto)

Identify calls honor the max_concurrency bucket rules from GET /gateway/bot, and multi-process deployments can share Identify and REST limits through the bundled TCP coordinator. See the scaling guide.

#Voice (experimental)

Voice is a separate module, gaato/discord_voice, for native bots built with this one. It joins voice gateway v8 calls, plays 20 ms Opus frames, and receives per-user Opus streams with Discord's DAVE encryption. See the voice guide for installation and runtime limits, and the dave_probe, voice_player, and voice_recorder examples.

#Synchronization and failures

CommandScope selects global, guild, or multi-guild registration. Pass sync=scope to BotBuilder to synchronize once after the first READY; when omitted, the bot makes no command request. HTTP executors never synchronize commands. For those deployments, call app.build().sync_commands(client, application_id,scope~) from a one-shot registration program. It returns an @app.SyncReport whose scopes list each scope's created, updated, deleted, unchanged, and preserved command names, plus whether an overwrite was sent.

Synchronization fetches the remote catalog and only sends a bulk-overwrite PUT when it differs. By default (unowned=Delete), it removes undeclared commands from the selected scope. The Entry Point command is always preserved, including its id and fields unknown to this library. Use unowned=Keep on App::sync_commands or Framework::sync_*, or sync_unowned=Keep on Bot, when another process owns commands in the same scope. Bot emits one warning per scope with deletions through app.on_warn. Use exactly one process for synchronization in a multi-process deployment.

///|
async test "sync preserves entry points and skips an unchanged catalog" {
  let spec = @interaction.CommandSpec::slash("ping", "Ping")
  let (payload, report) = @framework.plan_command_sync(
    [spec],
    [spec.to_json(), { "id": "10", "type": 4, "name": "Launch", "handler": 2 }],
    unowned=Delete,
  )
  assert_true(payload is None)
  assert_false(report.overwritten)
  assert_eq(report.preserved, ["4:Launch"])
}

Install app.error_policy(...) to map failures to logs or interaction responses; handlers raise HandlerError variants such as UserMessage or MissingPermission for expected failures, and commands accept ordered pre-execution checks and fixed-window cooldowns. See the structuring bots guide.

#HTTP interactions (experimental)

App::serve(group, access=Token(token)) starts the HTTP interaction executor and returns an InteractionEndpoint that uses the App's declarations and error policy without opening a gateway. handle accepts decoded interaction JSON and returns callback JSON for Reply; the caller owns the task group, so handlers that defer keep running on it after handle returns:

///|
async fn handle_http_interaction(
  app : @discord.App,
  group : @async.TaskGroup[Unit],
  token : String,
  body : Json,
) -> Json? {
  app.serve(group, access=Token(token)).handle(body)
}

The Cloudflare Worker, Deno, Bun, and Vercel Function HTTP adapters verify the raw request bytes with the reusable pure MoonBit @discord.InteractionVerifier before parsing. The dispatch bridge is App::start_signed_http in the library. The examples/interactions_js example is an exported wrapper plus a small handler.js that maps a Web Request to InteractionHttpRequest and back; the per-host adapters (Workers, Deno, Bun, Vercel, Fastly, Lambda) only wire their entry point and lifetime API. The shared handler is tested on Node.js and Bun, while the Vercel lifecycle adapter is tested with an injected waitUntil collector. These local tests do not establish hosted Vercel deployment behavior. workers_echo is tested inside Cloudflare's local workerd runtime and supports streamed multipart callbacks for in-memory FileUpload values. On native, @discord.serve_interactions(group, app, access=Token(token), addr~, public_key~) is a complete signed-interactions HTTP server. See the HTTP interactions guide and the interactions_http, workers_echo, deno_echo, bun_echo, and vercel_echo examples. The separate Spin experiment uses WASIp2 and Spin's variables import for an immediate handler. It does not yet run the async App on a general Wasm host.

The JavaScript host checks cover different boundaries:

Host	Checked here	Remaining host integration
Cloudflare Workers	Signed requests and deferred REST in local workerd	Production deployment
Deno	Deno.serve adapter and signed requests	Hosted lifecycle
Bun	Shared MoonBit handler and Bun.serve loopback endpoint	Hosted lifecycle
Node.js	Shared MoonBit handler and Web APIs	HTTP hosting and process lifecycle
Vercel Functions	Node.js fetch adapter and waitUntil handoff	Vercel packaging and hosted lifecycle
Fastly Compute	FetchEvent and synchronous lifetime registration with a fake event	Fastly compilation and hosted execution
Lambda Function URL	Payload v2 body and response conversion with local events	AWS invocation and deployment

Other JavaScript function platforms can reuse the handler if they provide Web Request, Response, crypto.subtle, and fetch. Their entry point, background-work API, deployment bundle, and execution limits still need platform-specific checks. The Spin experiment instead tests the WASIp2 component boundary. The host entry point survey records the other host conventions and the remaining API decisions, including multipart responses and background-work lifetime.

The JavaScript REST client supports null-body 204 responses through moonbitlang/async@0.22.1; the workers_echo workerd suite covers a deferred interaction-response deletion end to end. Voice remains native-only; the gateway also runs on JavaScript and moonrun Wasm.

#Cloudflare Workers gateway

The workers_gateway example runs one gateway shard in a Durable Object with an outbound WebSocket. A bot accepts saved BotSession values through resume~; bot.sessions() returns snapshots containing both the Gateway session and its original READY metadata. The example stores them on a 30-second alarm so a restarted bot can process replayed events, including interactions arriving before RESUMED. Call bot.sessions() while bot.run() is active to capture live sessions:

///|
fn restored_bot(
  app : @discord.App,
  token : String,
  saved : Map[Int32, @discord.BotSession],
) -> @discord.BotBuilder {
  @discord.BotBuilder(app, token~, resume=saved)
}

///|
fn current_bot_sessions(bot : @discord.Bot) -> Map[Int32, @discord.BotSession] {
  bot.sessions()
}

An alarm restarts a failed bot, and a five-minute cron reconciles the object's stored enabled state after eviction or deployment. /stop disables those restarts and clears the saved session because a graceful close invalidates it; the public controls require a separate bearer secret. Snapshots are periodic: they do not guarantee exactly-once event handling or restore application state or optional cache contents. Cloudflare can evict an object after an outbound socket has protected it for up to 15 minutes. Received WebSocket messages are limited to 32 MiB, CPU to 30 seconds per event by default, and a connected object incurs duration charges. See the example README for deployment and local test details.

#Typed models

Every entity decodes from real API payloads, and unknown enum values and unknown JSON keys round-trip through Unknown(...) variants, so a new Discord feature does not break your application. IDs are phantom-typed snowflakes — a UserId cannot be passed where a ChannelId is expected — that keep full precision above 2^53:

let id : @model.MessageId = @model.Id::parse("175928847299117063")
println(id.timestamp_ms()) // 1462015105796

Wire models use T? for optional fields and Nullable[T] for nullable fields; PATCH methods expose plain optional arguments with clear_<field>=true flags for clearing. See the models and utilities guide.

#REST without the gateway

http.Client stands alone: typed wrappers over the routes, per-bucket rate limiting with a global window, automatic retry of 429s and of attempts that never reached Discord, multipart file uploads, and a raw client.request(route) escape hatch for anything not wrapped yet. Ordinary channel messages suppress @everyone and @here by default while still parsing user and role mentions.

let client = @dhttp.Client(token)
let message = client.create_message(channel_id, content="hello")
client.create_message(channel_id, content="with reply", reply_to=message.id)
|> ignore

Every endpoint with a resource anchor is also available through client-bound refs, which chain from parent to child resource before applying a verb:

client.guild_ref(guild_id).emoji_ref(emoji_id).edit(name="renamed") |> ignore

Validation failures raise before any I/O, request failures use DiscordHttpError, and list endpoints expose stateful Paginator[T] values. The REST guide covers the full ref surface, allowed mentions, file uploads, pagination, and custom routes.

Also in the box, each with its guide chapter:

an opt-in, gateway-driven in-memory cache — events and intents;
pure helpers for permissions, mentions, timestamps, and CDN URLs — models and utilities;
structured REST, gateway, and dispatch telemetry — middleware;
a feature-installer convention for structuring larger bots — structuring bots;
the interaction router, response gates, and no-network handler testing under App — the framework layer.

#Development

For handler tests without a Discord connection, Client::offline answers REST calls from a function you write, and the native/JS/Wasm gaato/discord/testkit provides deterministic interaction and model fixtures. Import the testkit only in your package's for "test" block.

The repository is a MoonBit workspace: this module is in discord/, next to gaato/discord_voice, gaato/dave, the examples, the guide, and the bot template. Run these from the repository root; they cover every member and build each against the in-tree versions of the others. A native build in the workspace runs every member's prebuild hook, so working in the repository needs Node.js on PATH:

moon check --target native --deny-warn
moon check --target js --deny-warn
moon check --target wasm --deny-warn
moon test --target native --release   # debug native builds need a working tcc setup
moon test --target js --release
moon test --target wasm --release
moon fmt
moon info --target native             # regenerate pkg.generated.mbti (API review signal)
scripts/gen_extends.py                # regenerate extends.mbt after adding or removing a ToJson type

To build this module alone against its published dependencies, as a consumer does, run MOON_WORK=off moon -C discord check --target native.

Look up any package, type, or symbol — including its docstring examples — from the terminal:

moon ide doc "@discord"
moon ide doc "@http.Client::create_message"
moon ide doc "@model.Message"
moon ide doc "@util.channel_permissions"

Each package's pkg.generated.mbti is a concise public-interface snapshot; review its diff when checking API drift.

Every MoonBit code block in this README has a compiled twin in src/readme_native_test.mbt, and code blocks marked mbt check in the guides and in docstrings compile and run as part of the test suite.

#License

Apache-2.0

discord

#discord.mbt

#Prerequisites

#Install

#Quickstart

#Packages

#Wasm runtime and permissions

#Examples

#App core and executors

#Gateway executor

#Voice (experimental)

#Synchronization and failures

#HTTP interactions (experimental)

#Cloudflare Workers gateway

#Typed models

#REST without the gateway

#Development

#License

#AllowedMentionType

#AllowedMentions

#AllowedMentionsError

#App

#AppBuilder

#AppConfigError

#AppCtx

#AppWarning

#ApplicationRef

#Arg

#Args

#Bot

#BotBuilder

#BotConfigError

#BotError

#BotSession

#CacheLimit

#CacheLimits

#CacheResources

#ChannelRef

#CheckCtx

#Client

#Command

#CommandCheck

#CommandPlan

#CommandReply

#CommandScope

#ComponentCtx

#ComponentDeferredCtx

#ComponentHandler

#ComponentImmediateCtx

#ComponentReply

#ComponentRoute

#CooldownBucket

#CooldownOutage

#CustomIdCodec

#CustomIdError

#DeferredCtx

#DiscordHttpError

#ErrorPolicy

#Event

#EventMiddleware

#EventType

#Events

#FailureCtx

#FailureOrigin

#FileUpload

#GatewayCapabilities

#GatewayCompression

#GatewayCtx

#GuildInvocation

#GuildRef

#HandlerError

#HandlerIntake

#ImmediateCtx

#InMemoryCache

#InitialResponse

#Intents

#InteractionCtx

#InteractionEndpoint

#InteractionHandler

#InteractionHttpBody

AllowedMentionType

AllowedMentions

AllowedMentionsError

App

AppBuilder

AppConfigError

AppCtx

AppWarning

ApplicationRef

Arg

Args

Bot

BotBuilder

BotConfigError

BotError

BotSession

CacheLimit

CacheLimits

CacheResources

ChannelRef

CheckCtx

Client

Command

CommandCheck

CommandPlan

CommandReply

CommandScope

ComponentCtx

ComponentDeferredCtx

ComponentHandler

ComponentImmediateCtx

ComponentReply

ComponentRoute

CooldownBucket

CooldownOutage

CustomIdCodec

CustomIdError

DeferredCtx

DiscordHttpError

ErrorPolicy

Event

EventMiddleware

EventType

Events

FailureCtx

FailureOrigin

FileUpload

GatewayCapabilities

GatewayCompression

GatewayCtx

GuildInvocation

GuildRef

HandlerError

HandlerIntake

ImmediateCtx

InMemoryCache

InitialResponse

Intents

InteractionCtx

InteractionEndpoint

InteractionHandler

InteractionHttpBody

InteractionHttpRequest

InteractionHttpResponse

InteractionOutcome

InteractionTarget

InteractionVerifier

InteractionVerifierError

InteractionsServer

InvocationScope

MemberRef

MessageRef

MessageUpdate

Modal

ModalDeferredCtx

ModalField

ModalFields

ModalHandle

ModalImmediateCtx

ModalOrigin