この文章はDeeplを使用して翻訳したものを修正したものです。
Tl;drを探している場合は、FAQをチェック.
こんにちは。もし私を知らないなら、ダニーです。私はdiscord.pyライブラリの中心的な（そして唯一の）メンテナです。一般に知られていることとは異なり、私はDiscordの社員ではありません。それどころか、プロのプログラマーですらありません。実際には、私は地元の病院で働く医療専門家です。にもかかわらず、私は趣味でプログラミングを楽しんでいて、自分の自由時間にdiscord.pyに取り組んできました。
discord.pyに取り組んで約6年になります。私の人生のかなりの部分が、このソフトウェアライブラリを完全に無料で維持することに費やされています。私は一度も寄付を受けたことがありません。また、寄付を求めたこともありません。このライブラリは私の情熱的なプロジェクトで、Pythonで書かれたDiscordのボットをもっと見たいという思いから生まれました。長年にわたり、私のライブラリの多くのユーザーは、discord.pyが彼らの人生を変えたと私に言ってくれました。discord.pyは、自分自身に挑戦し、楽しいものを作り、新しい機会を見つける力を与えてくれました。教育的でオープンソースのプロジェクトを大切にしてきた私にとって、discord.pyが人々の生活にポジティブな影響を与えていることを知るのはとても意味のあることです。
残念ながら、今日で私のプロジェクトへの参加は終了します。そのため、即日、私はプロジェクトのメンテナを辞任します。私が信頼している貢献者たちに、プロジェクトを引き継ぎたいかどうか尋ねましたが、誰も引き受けてくれませんでした。基本的に、これは全会一致の決定であり、discord.pyプロジェクトは終了します。コードはオープンなままなので、もし誰かがフォークして作業をしたいのであれば、そうするのは自由です。しかし、メインラインの開発は今日で終了します。
これは決して軽い気持ちで決めたことではないことをお約束したいと思います。この文書が、私の考えと決定に至るまでの過程を説明するものであることを願っています。また、FAQも用意していますので、そちらもご覧ください。
私は2015年8月10日にDiscordに参加しました。友人にDiscordを勧められたのと、大会運営をIRC/Skypeから新しいプラットフォームに移行したいと考えていたため、それらのプラットフォームに過度な不満があったからです。初めてDiscordを使ったときには、かなり感動しました。しかし、Discordに移行するためには、私のボットが機能するためのAPIが必要でした。残念ながら、当時は「公式」のAPIはありませんでした。幸運なことに、私はnode-discordという名前のAPIラッパーを見つけ、それを使いました。このAPIラッパーは非常にミニマムなもので、ゲートウェイのメッセージ（当時はv2）をダンプするdebugイベントと、メッセージだけの特別なmessageイベントを含んでいるだけでした。この経験から、私はAPIがどのように動作するのかを理解することにとても興味を持ちました。翌日（8月11日）、私は自分のボットであるR. Dannyを作り、r/Splatoonサーバーに招待しました。
node-discordパッケージやEcmaScript 5の使用には完全には満足していなかったので、Pythonを使って自分でAPIをリバースエンジニアリングすることにしました。この時点で、ボットとAPIのエコシステムの初期のメンバーは、Discord Developersというサーバーに集まっていましたが、現在の同名のサーバーとは別のサーバーでした。このサーバーには、現在の新しいDiscord Developersサーバーのように、Discord愛好家やDiscordの従業員が多くいました。その中には、izy521さん（前述のnode-discordの生みの親）やVoltanaさんのような方もいました。私たちはDiscord APIについて話し合ったり、リバースエンジニアリングを行ったりしていましたが、最終的には志を同じくする人たち全員で、Voltanaが所有するDiscord APIという自分たちのサーバーを作りました。これは、私が登録した直後の8月13日に起こりました。
私は、discord.pyと名付けられた自分のAPIラッパーを、Discord.NET、discord.rb、discord.js、discord4Jなどの独自のライブラリを作った他の人たちと一緒に作り続けました。私たちは一緒になって、何のドキュメントもない中、数ヶ月かけてAPIをリバースエンジニアリングしていきました。私たちの小さなエコシステムは繁栄し、たくさんのボットが作られました。最終的には、Discord自身がブログ記事を書き、より多くの人に私たちのライブラリを使ってもらうために、私たちの冒険を詳しく説明しました。Discordのボットの将来には多くの希望と興奮がありました。私たちは多くのことを約束されていました。スラッシュコマンド、Webhook、"channel observers"、適切な音声サポートなどです。
時が経つにつれ、Discordは、招待をクロールしてボットを招待するという従来の方法に問題があることに気づきました。この問題に対処するため、DiscordはAPIへの関心を高め、従来の招待スクレイピングメカニズムではなく、OAuth2経由でのみ招待できる公式ボットアカウントを作成しました。これは、プライバシー保護のための良い変化と考えられ、DiscordがAPIに投資する希望に満ちた始まりとなりました。ボットには多くの専用機能が約束されていましたが、ローンチ時の最初で唯一の機能は、多くのサーバーでボイスチャンネルに参加できることでした。公式のボットAPIは2016年4月8日にリリースされました。
2016年にDiscordが公式APIを発表したとき、実装される機能について多くの約束がなされました。残念ながら、約束されていたもののほとんどは実現されませんでした。Discordの従業員にAPIの状況について尋ねると、彼らはいつも、APIに取り組むために必要な開発リソースが不足しており、APIプラットフォームに優先順位をつけたり取り組んだりすることはビジネス上意味がないと述べていた。当時のDiscordは小さな会社であり、多くの課題を抱えていたため、これは十分に理解できる。しかし、この優先順位の低さは、その後の3年間、APIが停滞することを意味していた。Discord botのコミュニティでは、我々の意見に耳を傾けてもらえないという不満が高まっていました。
私たちのDiscord APIサーバーは、もともとDiscordの社員とライブラリ開発者がお互いに変更点を話し合うための場所でした。私たちのサーバーにはドラマがなかったわけではなく、完璧でもありませんでした。このドラマのために辞めていったDiscord社員もいれば、もともとあまり話さなかった社員もいました。そんな中でも、Discord APIサーバーは、Discord社員とライブラリ開発者のコミュニケーションの中心となっていました。ライブラリ開発者が今後の変更点を把握したり、フィードバックを提供するための主な場所だったのです。時が経つにつれ、私たちライブラリ開発者と関わってくれるDiscord社員の数は2人に減っていきました。Jakeとb1nzyです。彼らは、私たちのフィードバックに耳を傾け、それに基づいて行動することに純粋な関心を示した唯一のDiscord社員だったので、私たちはしばしば彼ら2人が私たちの最後の希望だと冗談を言っていました。残念ながら、b1nzyはDiscordを去り、Jakeはアプリの他の分野でますます忙しくなったため、社内のDiscordチームとの断絶はますます大きくなりました。
Discordがボット開発プラットフォームにリソースを集中させ始めたのは、2019年11月頃のことでした。
私たちのコミュニケーションが苦しい一方で、別の、よりプライベートなサーバーが注目されていました。このサーバーは俗に "dinfra"と呼ばれ、"Discord Infrastructure"の略です。もともとこのサーバーの目的は、インフラの状況を大規模なボットの開発者と共有し、物事が混乱する可能性があるときに彼らに注意を促すことでした。しかし、このサーバーの目的は、大規模なボットの開発者とDiscordの従業員が、プラットフォームの将来についてコミュニケーションを取るための半公式な手段へと変化しました。
このサーバーにはライブラリ開発者があまりいなかったので、私たちはそのサーバーで何が行われているのかほとんど知らされていなかったことを覚えておいてください。2人のライブラリ開発者だけが招待されましたが、それは彼らがビッグボットの開発にも協力していたからです。彼らはライブラリ開発者としての役割を果たすために参加したわけではありません。Discordの社員は、APIの変更について、Discord APIサーバーではなく、Discord Infrastructureサーバーで議論するようになりました。Discordは、私たちライブラリ開発者に、提案されたAPI変更の最新情報を提供したり、フィードバックを提供する機会をあまり与えなくなりました。幸いなことに、Discordのインフラストラクチャーサーバーには、私たちと情報を交換してくれる "モル "が数人いたので、私たちが対応しなければならない今後の変更についての情報を得ることができました。
これは、PRESENCE_UPDATEとTYPING_STARTのイベントを除外することで、大規模なボットの帯域幅を削減する方法でした。これらのイベントは通常、ボットの帯域幅とCPU使用率の約95%を占めており、これらのイベントをゲートウェイのイベントストリームに表示されないようにすることは、一般的な機能要求でした。残念ながら、このブーリアン値のトグルには、メンバー関連のイベントもオフにするという注意点があり、多くのボットにとっては好ましくありませんでした。もっと良いシステムを作る必要がありました。このシステムはインテントと呼ばれています。
2019年12月頃、Discord Infrastructureサーバでintentsという新機能についての議論がありました。このシステムの目的は、多くのボット開発者が望んでいたイベントの無効化において、より詳細なアプローチを行うことでした。この変更は、おそらく当時のやり方との後方互換性があると思われます。残念ながら、同じ時期に、"dis.cool"と呼ばれるウェブサイトやスクレーパーを作成し、ユーザー情報を搾取するユーザー・ボット・リングの懸念が高まりました。
Discordは、このようなユーザー・ボット・リングの増加を責任ある脅威と考え、"Privileged Intents"という概念を導入し、その計画をDiscord Infrastructureサーバーに相談しましたが、これもまた、ライブラリ開発者に相談することなく行われました。Discord Infrastructureサーバにいる私のスパイが、特権的意図のオリジナルプランのgistを教えてくれました。これは私たちが何年も前から要求していた機能ではなく、ユーザーボットと本物のボットの間に誤った同等性があるために作られた追加の制限であることが明らかになりました。
この時点で、私はDiscordの従業員に「意図」とは何かを尋ねたところ、彼らは「そんな機能があることをどこかで聞いたことがあるか」と言い返し、秘密にしていることを示唆しました。私は、自分の情報源がバレないように、情報源についてはあまり触れませんでした。しかし、最終的にはDiscordの社員が口を割り、コンセプトの基本を簡単に説明してくれました。次の日も同じように要点を教えてくれて、話をしてくれました。
当初のインテントの仕様では、特権的なインテントとしてPRESENCE_UPDATEしかありませんでした。100サーバーを超える「大規模ボット」の場合、これでは、Discordに明示的に承認を求めるか、インテントをオフにしない限り、より多くのサーバーに参加することができなくなってしまいます。当時のホワイトリストのプロセスは、チェックボックスとテキストボックスに記入して、なぜその機能が必要なのかという理由をDiscordに伝え、オプションでボットがその機能を使用している様子を示すビデオを添付するというものでした。
ライブラリの開発者や貢献者の多くは、この変更に満足していませんでした。なぜなら、Discordで歴史的に行われてきた官僚主義的な処理方法では、Discordからの応答を待っている間にボットが静かに壊れてしまうからです。当時、25万以上のサーバーのボットが申請しなければならない大規模なボットシャーディングシステムがすでに遅れていたため、官僚主義がボットに与える影響について懸念が高まっていました。システムは大丈夫、官僚主義が悪影響を及ぼすことはないと約束されていました。
特権的意図のシステムが何かを達成したかどうかについては、双方から大きな議論がありました。ほとんどのライブラリ開発者は、この変更は方向性が間違っており、間違ったタイプのボットをターゲットにしていると感じていました。脅威モデルは、ユーザーボットが悪質な行為者であり、通常のボットではないことに基づいていましたが、今回の変更は通常のボットをターゲットにしていました。また、現在ユーザーボットで行われているのと同様に、ボットリングを持っているだけで制限を回避するのは簡単だと感じていました。
Discordは、100サーバーという基準値は影響が少ないと繰り返し述べており、ほとんどのボットはその基準値を超えていませんでした。私たちにとって大規模なボットとは、100サーバーをはるかに超え、100k以上の領域にあるボットのことです。当時、PRESENCE_UPDATEイベントは、プレゼンスやステータスだけでなく、ユーザーレベルのアップデート（名前、アバター、識別情報など）も提供しており、大きな負荷がかかっていました。この変更が実行される前に、分割すると言われていましたが、10ヶ月後のAPI v8では実際に分割されました。
Discordの従業員と何度も話し合い、彼らは我々のフィードバックに耳を傾けていることを伝えた後、彼らはGUILD_MEMBERSインテントも特権的なものにすることを決めました。GUILD_MEMBERS インテントは、ゲートウェイ経由でメンバー情報を取得するかどうかを制御するインテントで、メンバーレベルのイベントがライブラリ経由でどのようにディスパッチされるかの要となるものです。このインテントは、メンバーをローカルにキャッシュする場合にも必要です。当時、メンバー情報を提供するイベントが十分ではなかったため、すべてのライブラリの使い勝手が悪くなってしまいました。Discordの社員は、この変更は純然たる利益をもたらすものであり、官僚的な側面は誰でも記入できる2つのテキストボックスとチェックボックスだけで済むという意見を維持していました。
この追加については、Discord APIサーバー内だけでなく、GitHubでも多くの反響がありました。今日に至るまで、このGitHubのプルリクエストは、このリポジトリのすべてのイシューとプルリクエストの中で、最も多くの議論がなされています。これは、当時、メンバーデータが、パーミッションのチェックやモデレートなど、API内の多くの機能に必要だったからです。同様に、Discordの社員は、官僚組織への反発は最小限に抑えられ、すべてのボットは1日以内に検証されると主張していました。また、将来的にはメンバーデータは不要になるはずだと主張しています。この変更に適合するための期限は、2020年10月27日でした。また、この意向の導入日は2020年2月3日でした。
彼らは私たちのフィードバックに耳を傾けていると断言しました。
特権的意図を含む大量の議論が約3ヶ月間にわたって行われた後、ライブラリの開発者、貢献者、Discordの従業員のほとんどが会話から抜け出していました。その結果、この後、私たちとのコミュニケーションは基本的に沈黙してしまいました。最初の反響があった少し後の2月初めに allowed_mentions の機能を覗き見した以外は、Discordの社員とは何も話していませんでした。
2020年4月7日にDiscordがブログポストで将来の計画を発表するまで、Discordが何を計画しているのかわかりませんでした。このブログポストでは、ボット＆APIチームが、エコシステムの中にボットをどのように統合させたいかについてFigmaの例を示しながら、プラットフォームの将来のビジョンを発表しました。コンテキストメニュー、ボタン、エフェメラルメッセージなど、さまざまなコンセプトが示されました。私たちの多くは、いよいよ来るべき変化に期待していました。
しかし、残念なことに、プラットフォームの将来性に関するニュースと同時に、プラットフォームの追加的な制限に関する注意事項が発表されました。通常のテキストとチェックボックスの2つのフォームだけではなく、アンケート全体を記入しなければならなくなったのです。さらに、政府発行の身分証明書を提示してボットを認証し、認証チェックマークとプロフィールバッジ（これは後に廃止された）を取得する必要があった。プライバシーを侵害する検証システムを経由せずに、特権的な意図でホワイトリストに登録されることは、もはや不可能になりました。この検証システムを通さずに、100以上のサーバーにボットを参加させることは全くできなくなりました。
Discordは、悪意のあるボットが成長して機密データを取得するのを防ぐことで、セキュリティとプライバシーに役立つと主張しました。ライブラリの開発者は、悪意のあるボットは招待されなければならず、悪意のあるボットの核心は昔も今もユーザーボットであるため、助けにはならないと回答しました。言うまでもなく、以前の提案では、いわゆる悪意のある特権的な意図を無効にしても、ボットが100台のサーバーを超えて成長することは可能でした。ブログで公開された最終案では、特権的インテントを無効にしていてもいなくても、100台を超えるサーバーに参加するには公式が発行するIDによる認証が必要になりました。
この話題には反発が多かったので、当時のデベロッパーエコシステムの意見を聞くためにフォームを作成したところ、約1600件の回答がありました。私はこのフォームをDiscordと共有して、彼らの考え方を変えたり、開発者の気持ちを理解してもらおうと考えていましたが、彼らは私のサンプル数が少なすぎると言ってきました。統計学の知識が少しでもある人なら、1600人というサンプルサイズが取るに足らないものではないことを知っているだろう。とはいえ、アンケートに答えたほとんどの人は、自分のボットを確認するために公式が発行するIDを共有することを快く思っていなかった。
ボット開発者がこの変更についてどう感じているかについてのデータはたくさんありましたが、最終的には彼らが望んでいなかったため、Discordの従業員に提示することができませんでした。この頃、私のモチベーションの大半は低下していました。私は、認証システムは侵略的で不要だと考えていたので、根底から反対していました。ボット＆APIチームのプロジェクトマネージャーであるメイソンに、私のボットが認証を受けずにゲートウェイに接続できるかどうかについて無邪気な質問をしたところ、彼は無礼な反応を示し、必要以上に脅迫的な口調で私を「殉教者」と呼んだのです。
エコシステム内のボットを検証するという意図のもと、サポートスタッフは即座にリクエストに圧倒され、それまで約束していた5日間のSLAが完全に崩れてしまいました。ボット＆APIチームは、ボットを検証する人々の要求に応えられるよう、全員で協力しなければなりませんでした。しかし、彼らの最善の努力にもかかわらず、2020年の1年間を通して何週間も、あるいは何ヶ月も一貫して遅れており、これは2021年の今日まで続いています。
Discordはもともと、「検証済みボット開発者」バッジを、エコシステム内での自分の努力を「認めてもらう」ためのインセンティブとして使用していました。Discordによると、このバッジのためだけに検証を申請する人が急増したとのことです。最終的には、このバッジを完全に取り消し、バッジ名を「Early Verified Bot Developer」に変更しました。バッジを取り外さなかったことで、結果的にアカウントのブラックマーケットを助長することになってしまいました。恣意的なカットオフの後にバッジを得られなかったボット開発者の怒りは大きく、Discordの従業員は歴史を書き換えて、バッジを求めていただけの人々にミュートを配りました。彼らはこの行為を「bdgeposting」と呼びました。
Discordは2020年の間、5日間のSLAを達成することを一貫して約束していました。Discordはバッジが検証キューを混雑させていると非難していましたが、問題は解決されませんでした。私は個人的に、この一貫した5日間のSLAが起こる未来を見ていません。キューを処理するためにサポートスタッフを増員したにもかかわらず、キューはまだ1ヶ月遅れており、締め切りまでの数ヶ月間、より多くの人がインテントリクエストを再申請する必要があるため、さらに悪化することが予想されます。
2020年7月から8月頃、Discord社員がDiscord Infrastructureサーバーの人たちに、「Slash Commands」がついにDiscordに登場するかもしれないと話し始めました。この機能は、Discordの歴史が始まった当初から話題になっていたものだったので、一部の人たちはついに来るのではないかと期待していました。しかし残念なことに、ほぼ同時期に、Discordの社員がメッセージコンテンツの削除や制限をほのめかしていました。
私のモグラがこの画像を共有した後、私はプライベートサーバーに残っているライブラリ開発者にもこの画像を共有することにしました。私たちは、スラッシュコマンドの導入が自分たちの古い作品を破壊する手段であると考え始めました。この時点では、「スラッシュコマンド」は実際にはリリースされていませんでした。主に開発段階にありました。しかし、私たちは、「スラッシュコマンド」が公開されたら、メッセージコンテンツも一緒に削除されるだろうと考えていました。
その後すぐに、Discord Infrastructureサーバーの人たちは、スラッシュコマンドの実装のためのアーリーアクセスベータ版を手に入れました。私のモグラも、このシステムがどのように機能するのかを説明する要点（公開されていない）を教えてくれました。Discordの社員は、この要点や情報を後になるまで私たちと共有しませんでした。ようやく要点を教えてくれた後、彼らはこのシステムがどのように機能するかについて私たちとミーティングを行うことを計画しました。私は仕事中だったので参加しませんでした。参加したライブラリ開発者たちは、「Slash Commands」をどのように動作させたいのか、多くのフィードバックを共有したという。しかし、そのフィードバックのほとんどは破棄されてしまいました。
Slash Commandsのベータ版が一般公開されたとき、ライブラリ開発者やビッグボット開発者がBot & APIチームに伝えた批判やフィードバックを、多くの一般ユーザーが同じように繰り返していました。コミュニティからの圧力を受けて、最終的にはいくつかの変更が実装されましたが、パーミッションは依然として大きな問題でした。基本的に、スラッシュコマンドには致命的な欠陥がありました。それは、ユーザーに縛られていないことです。つまり、従来のパーミッションはスラッシュコマンドでは機能しませんでした。従来のボットの場合、サーバーの管理者はRead Messagesパーミッションをブロックすることで、チャンネルごとに特定のボットをブロックすることができました。しかし、スラッシュコマンドのボットでは、スラッシュコマンドがすべてのパーミッションをバイパスするため、このようなことはできません。
パーミッションのシステムは時間とともに改善されると言われていましたが、結局実現しませんでした。スラッシュコマンド(インタラクション)が@everyoneパーミッションをバイパスする機能は、2021年5月まで修正されませんでした。
2021年6月初旬、人気のあるライブラリの開発者上位8名に、エコシステムの全員にとって重要なトピックに関する特別会議の開催について連絡がありました。メッセージの意図を知っていた私たちは、エコシステムを破壊から守り、うまくいけばエコシステム全体に対する考えを変えてもらうためには、これが最後のチャンスになると考えました。このミーティングにはNDAが適用されていたため、私たちはNDAに署名することに抵抗を感じていましたが、この変更のための席を得る最後のチャンスだと信じていましたし、そう言われていたので、この方向性が良くないということを開発者に納得させるという唯一の目的のために、全員が同意しました。
残念ながら、このNDAに法的に拘束されているため、あまり詳細をお話しすることはできません。しかし、ライブラリ開発者全員の士気が急速に低下したことだけはお伝えしておきます。
私たちライブラリ開発者は、メッセージコンテンツが特権的な意図を持つようになることに反対していました。これは、通常の特権的インテントと同じ官僚的な問題に該当しますが、より壊滅的な結果をもたらします。エコシステムにある多くの現在のボットは、私が不必要だと考える変更に対応するために書き換えられるか、死ぬかの選択を迫られています。Discordは、この変更が良い方向に向かうと信じているようですが、代替の道は検討されず、提起もされませんでした。その代わりに、彼らは核のオプションを展開することを選択し、その方法で問題を解決しようとしています。また、Discordは、ほとんどのボットが指定された時間内に完全に移行すると考えています。私はそのようには思わない。
Discordは将来的にユーザーの移行を容易にするために、様々なことを計画しています。今から期限までの間に、これらの計画されたすべての改善を実際に完了するかどうかはわかりません。これまでの例では、期限が来る1ヶ月前にしかこれらの変更を終えることができませんでした。彼らは、システムを改善してからユーザーに押し付けるのではなく、まず変更を発表し、その後、スムーズな移行のために必要な機能を実装することを誠実に約束することにしました。これでは、ボット開発者は、移行に必要な機能がまだ存在しない場合に備えて、実際にボットを変更に対応させる時間がありません。
Discordはすでに、ずさんで性急な方法で機能を急ぎ始めています。新しい機能の一つであるコンテキストメニューは、多くのライブラリ開発者やボット開発者から、ライブラリの破損を防ぎ、APIをより直感的に理解するために、タイプをオーバーホールして分割するように求めるフィードバックが多く寄せられています。この狭い範囲のフィードバックは、この機能のプライベートベータに参加したほとんどのユーザーから提供されていたにもかかわらず、Discordの従業員は彼らはただ早く何かを出したかっただけだと主張し、明確に無視されています。
私は、何かが良くなるという約束を待っていても、歴史的にその約束が空虚であることを信じていません。2022年4月までに状況が劇的に改善するとは思えませんし、この変更が生態系に与える永遠の影響に値するとは思えません。残念ながら、この決定は最終的なものであり、今の段階で私にできることは、遠くから見守ることだけです。もう信じられないようなエコシステムについていくモチベーションはありません。私は、豊かなボットのエコシステムが繁栄し、ボットがその可能性を最大限に発揮することを望んでいましたが、Discordは、制限がより良いルートであると繰り返し判断しています。これが、私がこのプロジェクトのメンテナを降りることを決めた理由です。私のdiscord.pyとAPIへの関わりは、常に情熱と希望に満ちていました。最近の変更は、私からその両方を完全に奪ってしまいました。
細かいことを知りたい人からの質問が多くなると思います。
検証システムが導入されてからのこの1年で、Discordで作業するモチベーションが低下してきました。持続的な音痴、締め切り、嘘、ガスライティング、Discord社員による適切な相談なしの急激な変更など、頻繁な変更と私に課せられる制限の中で仕事をするのに必要なモチベーションを持つことが難しくなっています。
私にとって、メッセージの内容の特権的な意図は、私たちライブラリ開発者が信じていた創造的な自由と草の根のハッキングの終わりを告げるものです。コントロールが逆転し、Discordの制限の中で物事が作られるようになりました。もはやボットは、あなたの想像力によってのみ制限されたサンドボックスで繁栄するのではなく、Discordが承認されたユースケースの唯一のゲートキーパーとなっています。Discordのボットの将来は、インタラクションシステムにのみ依存しています。創造的な解決策は置いておいて、Discordの従業員によって明確に書かれ、サポートされなければなりません。将来的には、ゲートウェイAPI全体が制限され、非推奨となり、ボットを作成するための唯一の推奨方法は、完全にインタラクションまたはHTTPベースのものとなっても不思議ではありません。私はDiscordのボットの将来には全く期待していません。
しかし、Discordが構築しているものがクールではないという印象を与えたくはありません。確かに、とてもクールです。ボタンやUI拡張のようなものは、2016年から望んでいた機能であり、それらがプラットフォームに搭載されるのは素晴らしいことです。ただ、それがエコシステム全体にダメージを与える厳しい代償と結びついているのです。私には到底払えない代償です。
開発は中止され、リポジトリは読み取り専用モードになります。
残念ながら、あなたがこの列車を止めるためにできることは、Discordに変更に対するあなたの意見を伝えること以外にはあまりありません。エコシステムが壊れるという考えは、私に大きなストレスと精神的苦痛を与えました。この2ヶ月の間、私は様々なDiscordの従業員に私が感じている苦痛を伝えようとしてきましたが、効果はありませんでした。Discordは、9ヶ月後にはすべてがうまくいくと信じているようですが、私はそのような考えには賛成できません。
この変更は、たとえ私が方程式から除外されたとしても、急進的です。Discordは2022年4月までにすべてのボットをスラッシュコマンドに移行させることを期待していますが、私が何か手伝うかどうかは別として。私が提案したスラッシュコマンド用のAPIは、2つのシステムのパラダイムが根本的に異なるため、コマンド拡張の現在のコードとは互換性がありません。つまり、私がどのような道を選んだとしても、大多数のライブラリユーザーはいずれにしてもコードを書き換える必要があったということです。
なお、Discordは75ギルド以上のボットを当面の間、スラッシュコマンドに移行させたいと考えているようです。メッセージ内容のインテントを申請したい場合、コマンド処理の目的で使用することはできません。彼らは明確にインテントを拒否します。そのため、事実上、全員がスラッシュコマンドに移行しなければ、ボットは機能しません。
8月4日に行われた開発者向けQ&Aセッションでは、Bot & APIチームのプロジェクトマネージャーであるメイソンが、「簡単」で「ドープ」なので、自分のBotを書き換えることを勧めました。
えーと、人気のあるライブラリです。だから、私たちはサードパーティのライブラリをコントロールできないのは明らかです。彼らはサードパーティです。私たちはサードパーティと密接に協力して、変更点を知らせたり、実装やAPI、一貫性、「このAPIはクソかどうか」などの質問に答えたりしています。スラッシュコマンドは、昨年12月から開発者向けのオープンベータ版を提供しています。変更が行われるのは今からさらに9ヶ月後です。ということは、スラッシュコマンドが初めてリリースされてから1年4ヶ月、正確に計算すると16ヶ月ということになりますね。さて、多くのライブラリがサポートされています。非公式なフォークもあります。また、勇敢な開発者にとっては、ライブラリがなくても十分に使えると思いますが、それはとても大変なことだと思っています。しかし、もしあなたがHTTP上のスラッシュコマンドとWebhookを使ってみたことがないのであれば、それはとても素晴らしく、また簡単に拡張できるものです。
そのため、ボットの動作を継続させたい場合には、いくつかの選択肢があります。
- 自分でスラッシュコマンドシステムを実装する。ライブラリ(v2)は、
on_interactionを提供しており、すべてのエンドポイントは技術的にはbot.httpにあります。 - 生のAPIを使ってスラッシュコマンドシステムを実装する。
- 競合するdiscord.pyフォークが到着するのを待つ。
- 新しいライブラリや別のプログラミング言語を使って、ボットを書き換える。
Discordは、2022年4月には物事がうまくいくと信じていると繰り返し述べています。
しかし、現実には、かなりの数のライブラリがスラッシュコマンドを実装していません。以下に対応状況の表を示します。
| Library | Implementation State | Notes |
|---|---|---|
| discord.py | Not Implemented | |
| Discord.NET | Not Implemented | |
| Sleepy Discord C++ | Not Implemented | |
| discordgo | Not Implemented | |
| disgord | Not Implemented | |
| discordjl | Not Implemented | |
| Dimscord | Not Implemented | |
| DSharpPlus | Not Implemented | |
| Discordia | Partially Implemented | Unstable/Unreleased |
| Eris | Partially Implemented | Unstable/Unreleased |
| discord.rb | Partially Implemented | Unstable/Unreleased |
| nyxx | Partially Implemented | Unreleased |
| Ackcord | Partially Implemented | Unreleased |
| discord.js | Implemented | |
| JDA | Implemented | |
| Discord4J | Implemented | |
| Javacord | Implemented | |
| Serenity | Implemented | |
| Twilight | Implemented | |
| nostrum | Implemented | |
| Kord | Implemented | |
| DiscordPHP | Implemented |
これらは、マスターブランチでも他のブランチでも、どんな能力でも実装するライブラリです。Discordは、残りのライブラリがスラッシュコマンドの機能をすべて実装することだけでなく、すべてのユーザーが期限までに移行することも期待しています。人々はDiscordのエコシステムを中心としたものではない他の責任を持っているので、これらのユーザー全員に要求するのは不合理です。
残念ながら、そうではありません。これは非常に大きな傷を覆う小さな絆創膏のようなものです。実際には、前述したように、メッセージの意図に関するすべての悪い点は、ボットが言及されているメッセージを受信しても適用されます。ボット開発者がメッセージ内容のコマンドを維持するというユートピアがあったとしても、このことは、ユーザがボットの接頭辞を覚え直さなければならないことを意味し、ユーザビリティの観点からは好ましくありません。
残念ながら、私は信頼できない人にメンテナの地位を与えるつもりはありません。ここには、未知の第三者が多くのDiscordユーザーをターゲットにしたマルウェアをアップロードするという、私にとっては安心できないセキュリティ上の問題があります。なお、私はこのライブラリを誰に渡してもいいかを全員に尋ねましたが、全員が辞退し、私の決定を尊重し、Discordの方向性が気に入らないという点で私に同意してくれました。
しかし、あなた自身がこのプロジェクトをフォークして、あなたが求める改善点を実装することは自由です。
簡単に言うと、面白くないからです。私にとってスラッシュコマンドを実装することは特に難しいことではなく、2021年5月にはすでにローカルでほとんど動く、しかしひどく不完全なコピーを作っていました。しかし、それを続けるモチベーションは、今のところほとんどありません。スラッシュコマンドは、私が根本的に同意できないDiscordの方向性の変化を表しています。この機能が、プラットフォームにさらなる制限を加えるために急遽廃止されたのは残念なことです。
私のスラッシュコマンドの実装は、discord.ext.commandsの実装とは完全に異なることに注意してください。なぜなら、この2つのモデルは厳密には互換性がないからです。そのため、私が実装を公開したとしても、ほとんどのユーザーはそれをサポートするためにボットを完全に書き換えなければならなかったでしょう。
理想的には何もありません。私はサーバに何かをするつもりはないので、そのままで構いません。ライブラリはまだ機能していますし、discord.pyで書かれたコードはまだたくさんあります。さらに重要なのは、このサーバーは私の心の中に特別な場所を持っていて、私が誇りに思っているコミュニティがあり、それを灰にする理由がないことです。
同じことです。何も起こらないでしょう。
メッセージ内容の意図が将来的に起こるため、私のボットは司会ができなくなり、おそらく死ぬでしょう。私にとってのbotの意味を知りたい方は、Discordスタッフとこの件について話し合った際に、このトピックについて別の書き込みを書いていますので、そちらをご覧ください。
確信はありません。この決定は、Discordの従業員からの複数年に渡る不満から来ており、この文書で詳細を述べるにはあまりにも多すぎます。私は、それらが修正されたり、将来的に少しでも良くなるとは思いませんが、時間が解決してくれるでしょう。
もしDiscordの方向性が決まっていなかったら、discord.pyの作業を続けたかったです。実際、このライブラリでの作業はとても楽しかったですし、時間が許せば探求してみたいことがたくさんありました。しかし、このライブラリのすべての根底には、私が長年にわたって蓄積してきた不満を繰り返し引き起こしてきた企業体があります。この2つを切り離すことはできません。
私のミスです。発表中にまた質問が出てきたら、ここに追加します。あるいは、discord.pyサーバーで直接聞いてくれれば、答えられるようにします。
すみません。
以下の方々には、アルファベット順にお礼を申し上げたいと思います。
- ajさん 今まで接したDiscordのスタッフの中で一番対応が良かったことに感謝します。私たちと一緒に仕事をするときのあなたの意欲と積極性は他に類を見ないもので、とても感謝しています。
- Bryan Forbes 時間と労力をかけてライブラリのヒントを最初に入力してくれてありがとう。とても助かりました。
- Gary discord.pyサーバーでサポーターになってくれて、サーバーのみんなや私に親切にしてくれてありがとう。大変感謝しています。
- Hornwitserさん。discord.pyの初期の設計フィードバックを提供し、初期のディスパッチコードのスパゲッティを解きほぐしてくれてありがとう。
- Ian Mitchellさん。私の支離滅裂な暴言や不満に耳を傾け、物事をより良くしようとしてくれたことに感謝します。
- Ian Webster です。事態が悪化したときに、実際に親切に連絡を取ってくれてありがとう。
- Imayhaveborkedit。何年にもわたって、私が面倒を見られないときに、頼りになるボイスラングラーになってくれてありがとう。
- Jake。実際に私たちの柱となって、Discord APIサーバーの正気を保ってくれてありがとう。あなたがいなければ、私たちは虚栄心を失い、もっと多くのことが悪化していたでしょう。あなたの存在がなければ、私たちのサーバーは存在しなくなっていただろうとよく言います。
- LeoVさん 初期の頃にいてくれて、ドキュメントのロゴのデザインを手伝ってくれてありがとう。
- "Mole"、あなたは誰だか知っていますよね。私たちライブラリ開発者が直面していた不平等に光を当ててくれてありがとう。
- NCPlayzさん。このライブラリに継続的に貢献している唯一の人物の一人として感謝しています。あなたがいなければ、いくつかの機能を実装することは、一人で行うには負担が大きすぎました。
- spoopyさん 初期の段階でコードを保守し、貴重なフィードバックを提供してくれてありがとう。
- Stanislav. API開発の初期段階で、私たちの頼れる相談相手になってくれてありがとう。楽しかったです。
- discord.pyコミュニティ。あなたでいてくれてありがとう。
- 他のライブラリ開発者の皆さん。くだらないことでも一緒にいてくれてありがとう。私たちの団結力がなければ、私はずっと前に辞めていたと思います。
- Red-DiscordBotのコミュニティ。私に親切で敬意を払ってくれてありがとう。コマンドフレームワークで作業しているときにあなたたちが与えてくれたフィードバックは私にとって非常に貴重なものでした。
- discord.pyの様々な貢献者の方々。ライブラリ全体で様々なことを改善してくれてありがとう。最も小さな貢献でも大きな影響を与えます。
- discord.pyサーバーの様々なヘルパーさんたち。通常は感謝されないような大変な作業の大部分を引き受けてくれてありがとう。
そしてもちろん、この記事を読んでくださったあなたにも感謝します。
それでは、また次回。