Discord recently introduced Stage Channels!

These add a new type, a new property on VoiceState, a new permission (REQUEST_TO_SPEAK)
and 2 new endpoints to manage self/user's voice states.

Link to DAPI docs: discord/discord-api-docs#2751
The docs are still "in progress", they may change some things (the permission) but the rest should be good to implement.

If a PR is made, it should be made into a draft until the dapi docs are merged, and then we can merge it once we know nothing else will change randomly.

Summary

When sending a temporary message with send_temporary_message the parameter , message_reference seems missing.

Environment

Ruby version:

ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-darwin20]

Discordrb version:

discordrb (3.4.0)
discordrb-webhooks (3.3.0)

i think discordrb should start migrating to discord api v9 (and releasing discordrb on it), since it is the most recent one

https://discord.com/developers/docs/reference#api-versioning-api-versions

Summary

The error I am receiving is:
/usr/share/gems/gems/discordrb-3.4.0/lib/discordrb/voice/sodium.rb:6:in `module:Sodium': uninitialized constant Discordrb::Voice::Sodium::FFI (NameError)

I get this having installed Ruby 2.6. I have reinstalled all ruby components, cleared and rebundled, every possible step (other than rebuilding the code running box) and cannot get this to operate. Any advice as to what I must be doing wrong would be greatly appreciated, or, potentially what to fix if this is indeed a bug.

Environment

Ruby version:

ruby 2.6.7p197 (2021-04-05 revision 67941) [x86_64-linux]

Discordrb version:

*** LOCAL GEMS ***

discordrb (3.4.0)
discordrb-webhooks (3.3.0)

Create an internal mapping of type names to their integer value and expose methods to determine the type for Message objects.

Summary

The Interaction#button method attempts to return the button that triggered the interaction based on the value of @type. However, this value will always be type 3: component, because it is the interaction type, not the component type. As a result, the method will always return nil.

# @return [Hash, nil] Returns the button that triggered this interaction if applicable, otherwise nil
def button
  return unless @type == TYPES[:button]

  Components::Button.new(@data, @bot)
end

Additionally, various information about the button is unavailable because the button is being constructed from the top level data of the Interaction response. Values such as label and style are only accessible via the message.components, as shown here.

I believe both issues can be resolved by restoring the Interaction#button method from my original pull request to add button support.

Discordrb version:

3.4.2 87ae658

Summary

Subcommand events are not handled by an application_command handler for the top-level command. For example:

bot.register_application_command(:foo, 'foo') do |cmd|
  cmd.subcommand(:bar, 'bar')
  cmd.subcommand(:baz, 'baz')
end

bot.application_command(:foo) do |evt|
  evt.respond(content: evt.subcommand)
end

If you do /foo bar, you should see bar. The bot will receive the interaction, but this handler will never fire, and the message will not be sent. You can avoid this by rewriting the handler like this.

bot.application_command(:foo).subcommand(:bar) do |evt|
  evt.respond(content: 'bar')
end
bot.application_command(:foo).subcommand(:baz) do |evt|
  evt.respond(content: 'baz')
end

Environment

Ruby version:

ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-linux-gnu]

Discordrb version:

  * discordrb (3.4.2 fc98743)
        Summary: Discord API for Ruby
        Homepage: https://github.com/shardlab/discordrb
        Changelog: https://github.com/shardlab/discordrb/blob/master/CHANGELOG.md
        Path: /home/ajc/Code/scorebot/vendor/bundle/ruby/3.1.0/bundler/gems/discordrb-fc9874319798

Summary

If I call modify_roles once, adding some roles, and then I call it again, adding different roles, the roles I added the first time will be removed. This only begins as of a1083b0. If I roll back and use the previous commit, I'm fine.

Environment

Heroku, Ruby 3.0.2. Repros on Heroku and my own machine.

Discordrb version:

Gems included by the bundle:

• addressable (2.8.0)
• ballchasing (1.0)
• concurrent-ruby (1.1.9)
• core (1.17)
• csv (3.2.2)
• datacache (1.2)
• date (3.2.2)
• discordrb (3.4.2 f9a94c9)
• discordrb-webhooks (3.4.2 f9a94c9)
• domain_name (0.5.20190701)
• duration (1.6)
• event_emitter (0.2.6)
• ffi (1.15.5)
• ffi-compiler (1.0.1)
• http (5.0.4)
• http-accept (1.7.0)
• http-cookie (1.0.4)
• http-form_data (2.3.0)
• json (2.6.1)
• jubibot (1.4)
• linguistics (2.1.0)
• llhttp-ffi (0.4.0)
• loggability (0.18.2)
• mime-types (3.4.1)
• mime-types-data (3.2022.0105)
• netrc (0.11.0)
• opus-ruby (1.0.1)
• pg (1.2.3)
• public_suffix (4.0.6)
• rake (13.0.6)
• rest-client (2.1.0)
• rlranks (1.0)
• rstruct (1.5)
• single-instance (0.2)
• steam (1.4)
• unf (0.1.4)
• unf_ext (0.0.8)
• websocket (1.2.9)
• websocket-client-simple (0.5.1)
• yaml (0.2.0)

Add support for detecting the guild feature, CRUD operations, and gateway events associated with it.

https://github.com/shardlab/discordrb/blob/main/lib/discordrb/api/channel.rb#L334-L400

These API methods were added by myself and at least one of them will only work with a user token.

They should be revisited and tested to comply with the up to date API

A common flow could be to get all users who reacted on a message.

message = ... # Could be event.message or message.channel(c_id).load_message(m_id)
all_reactions = message.reactions.each_with_object({}) { |r, h| h[r.to_s] = message.reacted_with(r) }

Currently, this gives

Traceback (most recent call last):
        5: from /.../discordrb/data/message.rb:284:in `reacted_with'
        4: from /.../discordrb/data/message.rb:284:in `to_a'
        3: from /.../discordrb/paginator.rb:28:in `each'
        2: from /.../discordrb/data/message.rb:281:in `block in reacted_with'
        1: from /.../discordrb/api/channel.rb:203:in `get_reactions'
NoMethodError (undefined method `ascii_only?' for #<Discordrb::Reaction:0x0000000002a50fa8>)

and can be solved by doing message.reacted_with(r.to_s) but we already support Emoji, so why not Reaction for consistency?

Further, we could provide this flow as a method such as Message#all_reaction_users. I'd put a warning on it that it needs to paginate for every 100 reactions though.

Not specifying a machine image defaults to using a Trusty image, which is deprecated and will soon fail. Two options to fix: specify the latest machine image or use a Docker image instead.

I wrote yet another VoiceBot::play_internal that plays music smoothly.
It works fine in my environment.

https://gist.github.com/seki/925d73ba7aab871ad71597d579864f44

Title

Soon will be supported by the Discord API.

Preliminary docs here: https://discord.com/developers/docs/topics/threads

When attempting to connect a bot to a voice channel, execution seems to be hanging up on the line where it sleeps until the @voices array is updated via a webhook. Potentially not receiving/handling the webhook asynchronously? Have only tested locally.

Summary

The issue I'm facing is that message.reactions or message::reactions returns an empty array, even though there are reactions to the message. I can confirm the message is correct because message::channels and such return expected results. Please let me know if I'm doing something wrong!

Environment

• uname -sr: Linux 5.11.7-arch1-1
• CPU: R7 3800X

Ruby version:

ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]

Discordrb version:

*** LOCAL GEMS ***

discordrb (3.4.0)
discordrb-webhooks (3.3.0)

Object#send is used by RubyMine debugger, and we shouldn't be overwriting any Object methods.

Also, turns out I'm to blame

Much like CommandContainer and EventContainer, it seems there'd be benefit to adding an ApplicationCommandContainer or something similar, to modularize adding slash commands.

Summary

Channel#edit passes a 7th argument to API::Channel.edit_message for components, but edit_message can only support 6.

Environment

Ruby version:

Ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]

Discordrb version:

Latest main: discordrb (3.4.2 2e4ecc9)

Summary

Discordrb throws an error every time I use require "bundler/setup to load the gems when I'm building my own gem.
It is possible to run it locally without require "bundler/setup but as soon as I want to deploy the gem or use bundle install --deployment the script doesn't find the required gems in /vendor/bundle.

1. Create new gem
   bundle gem tmpGem && cd tmpGem
2. Add discordrb to Gemfile
   gem "discordrb", github: "shardlab/discordrb", branch: "main"
3. Make gemspec valid and install gems
   bundle install
4. Create class and uses the ping.rb example from discordrb

# frozen_string_literal: true

require 'discordrb'
require_relative "tmpGem/version"

module TmpGem
  class Bot
    def initialize(token)
      @bot = Discordrb::Bot.new token: token
  
      puts "This bot's invite URL is #{bot.invite_url}."
      puts 'Click on it to invite it to your server.'

      @bot.message(content: 'Ping!') do |event|
       event.respond 'Pong!'
      end
    end

    def run
      @bot.run
    end

  end
end

5. Open console and run the bot

$ ./bin/console
irb(main):001:0> TmpGem::Bot.new("TOKEN").run

6. Run into problem and panic:

This bot's invite URL is https://discord.com/oauth2/authorize?&client_id=<DELETED>&scope=bot.
Click on it to invite it to your server.
[ERROR : websocket @ 2022-03-19 17:32:01.574] The websocket connection has closed: (no information)
[ERROR : websocket @ 2022-03-19 17:32:01.574] Websocket close frame received!
[ERROR : websocket @ 2022-03-19 17:32:01.574] Code: 4014
[ERROR : websocket @ 2022-03-19 17:32:01.574] Message: Disallowed intent(s).
[ERROR : websocket @ 2022-03-19 17:32:01.574] You attempted to identify with privileged intents that your bot is not authorized to use
Please enable the privileged intents on the bot page of your application on the discord developer page.
Read more here https://discord.com/developers/docs/topics/gateway#privileged-intents

7. Run not into the problem:
   Remove require "bundler/setup" in ./bin/console
   Change require "tmpGem" to require_relative "../lib/tmpGem" in ./bin/console
   run step 5. again

This bot's invite URL is https://discord.com/oauth2/authorize?&client_id=<DELETED>&scope=bot.
Click on it to invite it to your server.
[INFO : websocket @ 2022-03-19 17:45:21.662] Discord using gateway protocol version: 6, requested: 6

Environment

**Ruby version: **

ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [x86_64-linux]

Discordrb version:
fc98743

bot.channel(c_id).load_message(m_id).reacted_with(emoji, limit: nil)

Traceback (most recent call last):
       16: from /.../discordrb/data/message.rb:284:in `reacted_with'
       15: from /.../discordrb/data/message.rb:284:in `to_a'
       14: from /.../discordrb/paginator.rb:28:in `each'
       13: from /.../discordrb/data/message.rb:281:in `block in reacted_with'
       12: from /.../discordrb/api/channel.rb:205:in `get_reactions'
       11: from /.../discordrb/api.rb:115:in `request'
       10: from /.../discordrb/api.rb:81:in `raw_request'
        9: from /.../restclient.rb:66:in `get'
        8: from /.../restclient/request.rb:63:in `execute'
        7: from /.../restclient/request.rb:163:in `execute'
        6: from /.../restclient/request.rb:727:in `transmit'
        5: from /.../ruby/2.7.0/net/http.rb:933:in `start'
        4: from /.../restclient/request.rb:743:in `block in transmit'
        3: from /.../restclient/request.rb:836:in `process_result'
        2: from /.../restclient/abstract_response.rb:129:in `return!'
        1: from /.../restclient/abstract_response.rb:249:in `exception_with_response'
RestClient::BadRequest (400 Bad Request)

Unsure if this is a problem with the Paginator or something else

Summary

Bot command returns undefined method for register_application_command and application_command

I'm running through the example for slash commands an ultimately getting errors...

require 'discordrb'

bot = Discordrb::Bot.new(token: 'TOKEN')

bot.register_application_command(:spongecase, 'Are you mocking me?', server_id: 'SERVER_ID') do |cmd|
  cmd.string('message', 'Message to spongecase')
  cmd.boolean('with_picture', 'Show the mocking sponge?')
end

The bot.register_application_command line is outputting this error:

undefined method `register_application_command' for #<Discordrb::Bot:0x000000011c04c140 @should_parse_self=false, @client_id=nil, @type=:bot, @name="", @shard_key=nil, @prevent_ready=false, @compress_mode=:large, @token="Bot TOKEN", @gateway=#<Discordrb::Gateway:0x000000011c047f00 @token="Bot TOKEN", @bot=#<Discordrb::Bot:0x000000011c04c140 ...>, @shard_key=nil, @ws_success=false, @check_heartbeat_acks=true, @compress_mode=:large, @intents=nil>, @users={}, @voice_regions={}, @servers={}, @channels={}, @pm_channels={}, @restricted_channels=[], @voices={}, @should_connect_to_voice={}, @ignored_ids=#<Set: {}>, @ignore_bots=false, @event_threads=[], @current_thread=0, @status=:online> (NoMethodError)

There's a similar output for bot.application_command

Environment

Ruby version:

ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [arm64-darwin21]

Discordrb version:

discordrb (3.4.0)
discordrb-webhooks (3.3.0)

If you're in pry and stop your bot it'll endlessly tell you that the ws wasn't connected when trying to heartbeat lol
-Swarley 2021

Summary

Using allowed_mentions with Discordrb::Webhooks::Client.execute fails with Bad Request.

require "discordrb"
require "discordrb/webhooks"

client = Discordrb::Webhooks::Client.new(url: ENV["DISCORD_WEBHOOK_EN"])

begin
  client.execute do |builder|
    builder.content = "test"
    builder.allowed_mentions = Discordrb::AllowedMentions.new(parse: [])
  end
rescue RestClient::BadRequest => e
  puts e.response.body
end

Result:

{"allowed_mentions": ["Only dictionaries may be used in a ModelType"]}

Environment

Ruby version:
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]

Discordrb version:

• discordrb (3.4.2 87ae658)
• discordrb-webhooks (3.4.2 87ae658)

First of all, I would like to thank every contributor of this project, because it's been tremendously easy and very straight-forward to create a bot for Discord with your help.

The main goal of my bot is to list files and directories inside Google Drive, as well as downloading them. For that, I'm using the Google Drive V3 API.

I've already managed to do all that.

My problem is: I'm using event.respond to list files individually. Because of that, after 5 messages posted by the bot, it waits 4 seconds and then resumes. (This is what causes "RL bucket depletion detected! Locking RL mutex for 3.859 seconds pre-emptively")

If the limit of files displayed that I imposed is equal to 1000 files, and the 3 first lines of the message correspond to the header (composed by a greeting, the name of the bot, and the name of the current directory), as well as a line that marks the end of the directory:

1000 + 3 + 1 = 1004 lines total
 
 

So if it stops after 5 messages continously until the end of the directory,
According to my calculations

1004 / 5 = 200.8 times that the directory listing would halt

200.8 * 4 = 803.2 seconds waiting = 13.38 minutes waiting
 
 

How can I overcome this?
How can I stop this from happening?

Thank you for your time.
And again, you have been making such an amazing work! Carry on!

With the current webhook through settings, discord gets a bit spammy. We can have finer control over the webhooks through Actions. For now, we disabled check suite, but it'd be nice to re-enable that with less spam.

https://docs.github.com/en/actions/reference/events-that-trigger-workflows#webhook-events

Server methods involving channels rely on a populated channel list which only occurs with a persistent WebSocket connection.

We need to fetch the guild channels if the WebSocket is not active.

Additionally, channels fetched outside the WebSocket aren't added to the channel cache when they should be.

As an extension, there may be other information on a server that isn't cached or fetched without a WebSocket connection, so these should be checked too

I'll look into this tomorrow

Relevant Docs: https://discord.com/developers/docs/resources/audit-log#audit-log-entry-object-optional-audit-entry-info

Relevant File: lib/discordrb/data/audit_logs.rb

We currently support count, channel, delete_member_days, members_removed.

We should support id, type, message_id, role_name.

With 3.5 approaching and 4.0 being the target afterwards, one important task that the community can help with gets stronger in my mind.

We'd love to have 100% documentation to library mapping of objects, properties, and API calls.
Some things fall through the cracks and we can't have an eagle eye on every single documentation change (and the changelog isn't perfect).

What I'd like to propose is an audit of all the Objects/Properties/API calls that Discordrb exposes, and to find all the ones we're missing. There are some properties that are simply not useful to keep track of, but we can make that decision after the differences have been found. We'd then also have a reference of which ones we don't have and why.

I also have plans to track all documentation commits to assess whether anything needs to be changed and create tracking issues for them where relevant. This will come after the audit has happened to save on work.

If you'd like to work on this, please let it be known on the issue, so others don't duplicate your work. Please include which objects you're looking at, and update your post as you move onto others.

I will be starting on this task in the coming weeks, but feel free to get a headstart on this.

Summary

While working on slash command routes, I've noticed that there are more than a few API methods with some common mistakes.

1. The final argument is not a hash, for example:

  def token_webhook(webhook_token, webhook_id)
    Discordrb::API.request(
      :webhooks_wid,
      nil,
      :get,
      "#{Discordrb::API.api_base}/webhooks/#{webhook_id}/#{webhook_token}"
    )
  end

Where the correct fix would be to add an additional {} as the final argument

2. Some POST/PATCH methods do not include a content_type: :json header entry.

3. Some methods are missing their links to the Discord documentation, particularly in lib/discordrb/api.rb

If anyone wants to review the methods we have and open a PR with any changes, that would be great.

Description

When calling Channel#history with a limit larger than the amount of messages that exist in the channel, it would seem like the method is attempting to get author details for nil messages, and the result is this error appearing multiple times:

[ERROR : main @ 2022-01-10 11:00:39.235] Unknown Member
[ERROR : main @ 2022-01-10 11:00:39.511] Unknown Member
[ERROR : main @ 2022-01-10 11:00:39.803] Unknown Member
# ... Ctrl+C is required to abort
# and each line takes some 200ms to complete, hinting a web request is in progress.

Reproduction

Run the below code on a channel that has less than 100 messages.

require 'discordrb'
channel_id = 123 # replace me with a channel ID
bot = Discordrb::Bot.new token: ENV['BOT_TOKEN']
channel = bot.channel channel_id
pp channel.history 100

Environment

Ruby version:

ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-linux]

Discordrb version:

  * discordrb (3.4.2 a1083b0)
  * discordrb-webhooks (3.4.2 a1083b0)

Describe your feature request in as much detail as you can here.

• It is a feature supported by Discord's API, but missing from the library

https://discord.com/developers/docs/interactions/slash-commands

The python example is

url = "https://discord.com/api/v8/applications/<my_application_id>/commands"

json = {
    "name": "blep",
    "description": "Send a random adorable animal photo",
    "options": [
        {
            "name": "animal",
            "description": "The type of animal",
            "type": 3,
            "required": True,
            "choices": [
                {
                    "name": "Dog",
                    "value": "animal_dog"
                },
                {
                    "name": "Cat",
                    "value": "animal_dog"
                },
                {
                    "name": "Penguin",
                    "value": "animal_penguin"
                }
            ]
        },
        {
            "name": "only_smol",
            "description": "Whether to show only baby animals",
            "type": 5,
            "required": False
        }
    ]
}

# For authorization, you can use either your bot token 
headers = {
    "Authorization": "Bot 123456"
}

# or a client credentials token for your app with the applications.commmands.update scope
headers = {
    "Authorization": "Bearer abcdefg"
}

r = requests.post(url, headers=headers, json=json)

https://gist.github.com/swarley/e7fcc68672f37083c00ecba28c47f6cc

this code will fail to clear CommandContainer since Discordrb::Commands::CommandContainer does not implement clear!

If we extended our CommandContainer with Discordrb::EventContainer, this code would run, but it would not clear the commands since they are implemented on @commands and clear! acts on @event_handler.

I'm unsure if module extending works with super, especially if it isn't already defined, but this would be a way around it.

This isn't a crucial feature, so could be delayed until the CommandBot rework.

E: I didn't check, but this should also apply to any other EventContainer methods for consistency

Summary

Running a bot without the SERVER_MEMBERS intent will cause Server#members to hang.

Debug output looks like this:

[3] pry(main)> bot.servers[TEST_SERVER_ID].members
[DEBUG : main @ 2021-05-15 17:34:18.890] Members for server <TEST_SERVER_ID> not chunked yet - initiating
[OUT : main @ 2021-05-15 17:34:18.890] {"op":8,"d":{"guild_id":<TEST_SERVER_ID>,"query":"","limit":0}}

Environment

Ruby version:
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin18]

Discordrb version:
/Users/me/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/bundler/gems/discordrb-359326e8743c

Message objects can have an array of stickers associated with them.

This will require a new class (Sticker) and an additional field (#stickers) on Message.

To add Message#add_reaction_await and Message#add_reaction_await!

I feel like adding an await for a reaction is common enough to warrant a handy abstraction for it.

Currently, Messsage#add_await adds a MessageEvent await, and I thought we could extend this to have it parse a symbol (like :message or :reaction_add) for the type of event (and default to message), then allow for optional arguments like emoji.

Not sure if this is supported in the current await system, but it would be nice to support multiple emoji for the reaction awaits.

Support for the new actitivty type should include adding an identification method, competing?, to Activity. And a method to set a competing status, Bot#competing=.

Relevent docs here.

To support User#avatar_url (and by extension API::User.avatar_url) size passing.

There will be other similar methods that return an image URL that should also support sizes.

Buttons are hitting the API soon, and will offer new methods of interacting with messages.

We will need to support the initial components; ActionRow and Button (Potentially the dropdown menu as well depending on how quickly I get this done 😅 ).

Each will require a data class for receiving interactions, and a builder for sending them with messages.

Ideally we will also have some form of resuable "component collection", but this is still up in the air and an initial implementation can be shipped without it.

Summary

When ffmpeg is not installed, and the example voice_send.rb is ran, the mp3 will give Exception: #<IOError: File or stream not found!> when it should output a more relevant error regarding ffmpeg.

This comes from a report in the discordrb channel in dAPI. It is currently unconfirmed in main.

Environment

Ruby version: ruby 3.1.0p0

Discordrb version: discordrb (3.4.0)

With Nitro, you can now set your icon as well as other things.

The bot should support fetching this on a per-server basis, it currently only supports global

• #145
• Banners

The following events need to be implemented.

• INTERACTION_CREATE
• APPLICATION_COMMAND_CREATE
• APPLICATION_COMMAND_UPDATE
• APPLICATION_COMMAND_DELETE

Summary

We fixed the Pagination without supplying a limit in #39, but discord has recently broke this.

discord/discord-api-docs#3053

An untested fix in the meantime could be to supply a known limit, but it'll still make additional requests and you'd have to call .uniq on the Array.

You could also supply custom pagination code.

This is a tracking issue for v10

See discord/discord-api-docs#4510

Since latest gem (3.4) is on v6 and soon to be decommissioned, more work will be dedicated into pushing out a stable 3.5.

Main branch already includes v8, and the threads branch that is being worked on is running on v9.

We'll be targeting v9 for the 3.5 release, and probably v10 for 4.0.

Most of the work needed for these separate releases are nothing to do with the versioning changes, so no PR is needed and can be done when it is needed.

Please do stop by the discord channel in the dAPI server, or the ShardLab discord server for the most up to date information regarding discordrb development, though we will be trying our best to keep Github up to date with anything major.

In the documentation, we have optional and nullable fields. In the past, we have either provided optional fields with default values or not provided them as options at all.

To support them with our current implementation, we could build the hash separately to only include values when they are not nil. Unfortunately, this begs the question on what to do if the field is both optional and nullable. If we want to explicitly set it as nil, and not ignore nil values in the hash, how would we implement this?

Perhaps a symbol or constant on the API scope API::Nil for explicitly setting a field as nil, or the other way API::Empty to make it not included when the field is optional.
For the first, the methods would parse out the nils out of the hash, and then transpose API::Nil to nil (or maybe to_json will do this automatically)
For the second, we only remove fields that have the `API::Empty as the value.

In terms of user experience, I prefer the first, but I'd love to hear additional thoughts on the matter.

Also, with the rework of the API methods planned for 4.0, I would like to see a way to pass data, either JSON or Hash, to the method manually to give the user more control, and include support for any extra parameters without updating. This would be in addition to what we have right now.

I've tried using both the main and slash_commands branches, but whenever I try to respond to an application command event, I see:

[ERROR : websocket @ 2021-09-15 13:29:02.026] Invalid Form Body
    - data.components[0]: Only dictionaries may be used in a ModelType

If it's helpful, when I debug the request parameters (attributes variable in the api.rb's #request method) just before it's sent in discordrb, it looks like:

["https://discord.com/api/v8/interactions/REDACTED/REDACTED/callback", "{\"type\":4,\"data\":{\"content\":\"\",\"embeds\":[],\"flags\":0,\"components\":{\"rows\":[]}}}", {:content_type=>:json, :user_agent=>"DiscordBot (https://github.com/shardlab/discordrb, v3.4.2) rest-client/2.1.0 ruby/3.0.2p107 discordrb/3.4.2 "}]

This is fixed if I set the components keyword on the #respond method to a blank array, like so:

bot.application_command(:play) do |event|
  event.respond(content: "done", components: []) # without `components: []`, the error is thrown.
end

We have Server#ban and Server#kick.

It seems natural to "ban" a "member". How do you verb an object? You call Object#verb

Summary

I feel like I must be doing something wrong, but it seems like any version of discordrb 3.4.0+ fails to run for me, even in the very basic hello world use case:

bot = Discordrb::Bot.new(token: 'xxx')
bot.run

Results in:

[ERROR : websocket @ 2021-05-23 19:37:06.054] Gateway message error!
[ERROR : websocket @ 2021-05-23 19:37:06.054] Exception: #<ArgumentError: wrong number of arguments (given 2, expected 3)>
[ERROR : websocket @ 2021-05-23 19:37:06.054] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/data/member.rb:59:in `initialize'
[ERROR : websocket @ 2021-05-23 19:37:06.054] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/data/message.rb:107:in `new'
[ERROR : websocket @ 2021-05-23 19:37:06.054] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/data/message.rb:107:in `initialize'
[ERROR : websocket @ 2021-05-23 19:37:06.055] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/bot.rb:1112:in `new'
[ERROR : websocket @ 2021-05-23 19:37:06.055] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/bot.rb:1112:in `handle_dispatch'
[ERROR : websocket @ 2021-05-23 19:37:06.055] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/bot.rb:709:in `dispatch'
[ERROR : websocket @ 2021-05-23 19:37:06.055] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:727:in `handle_dispatch'
[ERROR : websocket @ 2021-05-23 19:37:06.055] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:691:in `handle_message'
[ERROR : websocket @ 2021-05-23 19:37:06.055] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:628:in `websocket_loop'
[ERROR : websocket @ 2021-05-23 19:37:06.055] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:576:in `connect'
[ERROR : websocket @ 2021-05-23 19:37:06.056] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:470:in `block in connect_loop'
[ERROR : websocket @ 2021-05-23 19:37:06.056] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:469:in `loop'
[ERROR : websocket @ 2021-05-23 19:37:06.056] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:469:in `connect_loop'
[ERROR : websocket @ 2021-05-23 19:37:06.056] /Users/jjordan/.rvm/gems/ruby-2.6.2/bundler/gems/discordrb-c5f5ea8c03e8/lib/discordrb/gateway.rb:165:in `block in run_async'

This appears to be due to this commit: 751261c which calls Member.new with 2 arguments, but the Member#initialize method has taken 3 arguments for the past 3 years. Surely I'm not the only person who has run this server for the past few months, but I don't see another issue for this. So, I wonder what's unique about my usage -- it seems that this code path would always cause this error.

Environment

Mac OS, Ruby 2.6.2, discordrb 3.40 or 3.4.1 or 3.4.2