本文翻譯自discord.py的核心開發人員的長文。

discord.py的未來

懶人包

你好。如果你不認識我，我就是 Danny。我是 discord.py 程式庫的核心（也是唯一的）維護者。與普遍看法相反，我其實並不是 Discord 員工。事實上，我甚至不是一個專業的程序員。實際上，我是一名在當地醫院工作的醫學專家。儘管如此，我確實將寫程式當作一種愛好，並在自己的空閒時間研究 discord.py。

我已經在 discord.py 上工作了大約 6 年——用我生命中相當重要的一部分來完全免費地維護這個程式庫。我從來沒有接受過捐款。我從來沒有要求過捐款。這個程式庫一直是我的熱情項目，完全出於希望在 Discord 上看到更多用 Python 編寫的 BOT 的願望。多年來，我程式庫的許多用戶告訴我，discord.py 改變了他們的生活。它使他們能夠挑戰自我、創造有趣的事物並尋找新的機會。作為一直重視教育性開源項目的人，知道 discord.py 對人們的生活產生了積極影響對我來說意義重大。

不幸的是，今天標誌著我參與該項目的結束。因此，我將辭去項目維護者的職務，立即生效。我問我信任的貢獻者是否想接管這個項目，但沒有人接受。從本質上講，這是一個一致的決定，discord.py 項目將迎來結束。程式碼會保持開放狀態，所以如果有人想，可以自由建立分支（fork）並使用它。但是，從今天起，主線開發將會停止。

我想向你保證，這不是一個輕率的決定。我希望這份文件能解釋我的想法和作出決定的過程。如果您只是想快速了解一下，我還寫了 FAQ。

草根運動

我於 2015 年 8 月 10 日加入 Discord。我有朋友向我推薦了 Discord，由於對 IRC/Skype 的過度不滿，我們希望轉移到新平台。我第一次使用 Discord 給我留下了深刻的印象。然而，為了讓我繼續前進，我們需要一個 API 來讓我的 BOT 運行。不幸的是，當時還沒有「官方」API。幸運的是，我找到了一個名為「node-discord」的 API 包裝器並使用了它。這個 API 包裝器非常小，只包含一個轉存 gateway 訊息的 debug 事件（當時是 v2）和一個專門用於訊息的 message 事件。這次經歷讓我對弄清楚 API 的工作方式非常感興趣。我製作了我的 BOT，R. Danny，第二天（8月11日）邀請它加入 r/Splatoon 伺服器。

我對 node-discord 包和 EcmaScript 5 的使用並不完全滿意，所以我自己開始使用 Python 自己對 API 進行逆向工程。此時，BOT和 API 生態系統的所有早期成員都駐留在名為 Discord Developers 的伺服器中，但與今天同名的伺服器不同。在這個伺服器中，我們有很多 Discord 愛好者和 Discord 員工，就像現在比較新的 Discord Developers 伺服器。在這些人中，有像izy521（前面提到的node-discord的創造者）和Voltana這樣的人。我們一直在討論 Discord API 並對其進行逆向工程，直到最終我們所有志同道合的人都製作了我們自己的伺服器，名為 Discord API，由 Voltana 擁有。這發生在 8 月 13 日，也就是我自己註冊後不久。

我繼續研究我的 API 包裝器，恰當地命名為「discord.py」，和其他自製的程式庫一樣，如「Discord.NET」、「discord.rb」、「discord.js」、「discord4J」……等等。在接下來的幾個月裡，我們一起對 API 進行了逆向工程，沒有任何說明文檔可以幫助我們。我們的小生態系統蓬勃發展，並製造了許多 BOT。最終，Discord 自己寫了一篇blog，詳細介紹了我們為讓更多人使用我們的程式庫而進行的冒險。人們對 Discord BOT 的未來充滿希望和興奮。我們被承諾了很多事情！未來將是光明的；我們將獲得斜線命令、webhook、「頻道觀察者」、適當的語音支持等。

隨著時間的推移，Discord 意識到傳統的邀請 BOT 的方式是有問題的。為了對抗這種濫用，Discord 決定提高他們對 API 的興趣，並創建了只能透過 OAuth2 而非傳統邀請機制來邀請的官方 Bot 帳戶。這被認為是很好的隱私權改動，並開啟了 Discord 對其 API 進行投資的充滿希望的開始。官方向我們承諾會為 BOT 提供許多獨家功能，儘管在發佈時我們收到的第一個也是唯一的功能是能夠在許多伺服器上加入語音頻道。官方 BOT API 於 2016 年 4 月 8 日發布。

疏忽

當 Discord 在 2016 年公佈他們的官方 API 時，對將要實現的功能做出了許多承諾。不幸的是，承諾的大部分事情最終都沒有實現。當我們向 Discord 員工詢問 API 的狀態時，他們總是說他們缺乏開發 API 所需的開發資源，並且優先考慮或處理 API 並沒有商業意義。這是完全可以理解的，因為 Discord 當時是一家小公司，有很多事情要做。然而，缺乏優先級代表 API 在接下來的 3 年裡停滯不前。Discord BOT 社群因為意見沒有被傾聽而越來越沮喪。

我們的 Discord API 伺服器最初是 Discord 員工和程式庫開發人員可以相互討論更改的地方。我們的伺服器並非沒有 drama，也不是完美的。一些 Discord 員工因為 drama 而離開了，而有些人一開始就沒有說過太多話。儘管如此，我們的 Discord API 伺服器還是 Discord 員工和程式庫開發人員之間的中央通訊樞紐。這是程式庫開發人員可以深入了解即將發生的變化並提供意見的主要場所。隨著時間的推移，願意與我們程式庫開發人員合作的 Discord 員工數量只剩下兩位：Jake 和 b1nzy。我們經常開玩笑說他們兩個是我們最後的希望，因為他們是唯一真的有興趣傾聽我們的意見的 Discord 員工。不幸的是，b1nzy 離開了 Discord，而 Jake 越來越忙於其他應用程式領域，所以我們與內部 Discord 團隊的脫節只會愈演愈烈。

直到 2019 年 11 月左右，Discord 才開始將更多資源集中在他們的 BOT 開發平台上。

Discord 基礎設施伺服器

當我們的溝通受到影響時，一個不同的、更私人的伺服器得到了更多的關注。該伺服器通俗地稱為「dinfra」，是「Discord Infrastructure」的縮寫。最初，此伺服器的目的是與大型 BOT 開發人員共享基礎設施狀態，讓他們提前了解何時可能出現動盪。但是，該伺服器的目標變成了大型 BOT 開發人員和 Discord 員工就平台未來進行交流的半官方方式。

應該注意的是，該伺服器中沒有多少程式庫開發人員，因此我們對該伺服器中發生的事情幾乎一無所知。伺服器只邀請了兩個程式庫開發人員，只是因為他們還幫助開發了大型 BOT。他們不是因為他們作為程式庫開發人員的角色而存在的。 Discord 員工逐漸開始在 Discord 基礎架構伺服器而不是我們的 Discord API 伺服器中討論 API 更改。 Discord 不再讓我們的程式庫開發人員了解提議的 API 更改，也不再給我們提供提供意見的機會。對我們程式庫開發人員來說幸運的是，我們在 Discord 基礎設施伺服器中有一些「內線」，他們願意與我們交換資訊，以便我們可以獲得有關我們需要適應的即將發生的變化的資訊。

其中一個變化是引入了名為「guild_subscriptions」的功能，這是一種透過選擇退出「PRESENCE_UPDATE」和「TYPING_START」事件來減少大型 BOT 頻寬的方法。這些事件通常佔 BOT 頻寬 和 CPU 使用率的 95% 左右，並且從 gateway 事件流中刪除這些事件是一個常見的功能請求。不幸的是，這個 boolean 開關也有關閉成員相關事件的風險，這對許多 BOT 來說是不可取的。需要建立一個更好的系統。這個系統被稱為 Intent。

Privileged Intents

2019 年 12 月左右，有人討論了 Discord 基礎架構伺服器中名為 Intent 的新功能。該系統的目標是採用更精細的方法來禁用事件，這是許多 BOT 開發人員一直所希望的功能。據推測，這種變化將與當時的工作方式向後兼容。不幸的是，與此同時，人們越來越擔心「dis.cool」：一個製作了網站和爬蟲的 user-bot ring，它可以大量竊取用戶資訊。

Discord 可能將這種不斷增長的 user-bot ring 視為一種「責任威脅」，並引入了「Privileged Intents」的概念，並與 Discord 基礎設施伺服器討論了該計劃，但同樣沒有就此諮詢程式庫開發人員。我在 Discord 基礎設施伺服器中的內線給了我一個Privileged Intents原始計劃的 gist。很明顯，這不是我們多年來一直要求的功能，而是由於 user-bot 和真實 BOT 之間的錯誤等效（false equivelance）而添加的限制。

在這一點上，我問過 Discord 員工 intent 是什麼，他們反駁說我在哪裡聽說過這樣的功能——暗示這是個秘密。為了不要洩露我現在的主要資訊來源，我沒有透露太多資訊。然而，最終 Discord 的員工透露了這個概念的基礎知識，並為我們快速概述了這一點。第二天，他們給了我們相同的 gist 並就此進行討論。

最初的 intent 規範只有標明PRESENCE_UPDATE作為 Privileged Intents。對於超過 100 個伺服器的「大型 BOT」，除非您明確請求 Discord 的批准或者關閉了 intent，否則這將阻止 BOT 加入更多伺服器。當時，要成為白名單的官方手續就是一個勾選框和一個文本框，您需要填寫這些勾選框和文本框以向 Discord 說明您為什麼需要這項功能，還可以選擇附加一段影片，顯示您的 BOT 對該功能的使用情況。

大多數程式庫開發人員和貢獻者對這些變化並不滿意，因為 Discord 過去官僚主義的處理方式代表 BOT 會在等待 Discord 回應時默默中斷。當時，超過 250,000 台伺服器中的 BOT 必須申請的大型 BOT 分片系統已經落後，因此人們越來越擔心官僚主義對我們的 BOT 的影響。我們得到承諾說，系統會很好，官僚主義不會產生負面影響。

關於 Privileged Intents 系統是否完成了任何事情，雙方都有重要的論點。大多數程式庫開發人員認為這些更改被誤導了，並且針對了錯誤類型的 BOT。威脅模型是建立在 user-bot 是不良行為者的基礎上，而不是常規 BOT，但更改針對的是常規 BOT。我們還認為，只需擁有一個 bot ring 就可以輕鬆避開這些限制，類似於現在使用 user-bot 所做的事情。

Discord 反覆提到 100 個伺服器閾值的影響很小，而且大多數 BOT 都沒有超過這個限制。對我們來說，大型 BOT 是超過 100 台伺服器並進入 100k+ 領域的BOT。當時，PRESENCE_UPDATE 事件嚴重過載，不僅提供在線狀態和狀態，還提供用戶級別的更新（例如姓名、頭像和identifier）。我們被告知，在更改生效之前他們將拆分這個事件，而這在 10 個月後在 API 的 v8 中才完成。

在與 Discord 員工進行大量討論後，他們告訴我們他們正在聽取我們的意見，他們決定GUILD_MEMBERS也將變成 previleged intent。 GUILD_MEMBERS 是控制您是否透過 gateway 獲取成員資訊的一個 intent，並且是如何透過程式庫調度成員級別事件的核心和靈魂。任何本地快取成員也需要這個 intent。當時，沒有足夠的事件提供成員資料，因此這代表所有程式庫的可用性都會受到影響。 Discord 的員工堅持認為這種變化利大於弊，而且官方手續只會是任何人都可以填寫的兩個文本框和勾選框。

這個添加不僅在 Discord API 伺服器中，就連在 GitHub 上都引起了軒然大波。時至今日，這項 GitHub pull requests 是該 repository 的所有問題和 pull requests 中討論最多的一項。這是因為在當時，API 中的大量功能都需要成員資料，例如檢查權限和審核。同樣，Discord 員工聲稱這些手續的影響很小，並且所有 BOT都將在一天內得到驗證。他們還聲稱，在未來，成員資料應該變得不再必要。遵守這些變更的截止日期為 2020 年 10 月 27 日。這項 intent 的引入日期為 2020 年 2 月 3 日。

他們向我們保證，他們正在聽取我們的意見。

Verification

在大約 3 個月的時間裡進行了大量涉及 Privileged Intents 的討論後，大多數程式庫開發人員、貢獻者和 Discord 員工都被排除在談話之外。結果，在此之後，與我們的交流基本上是無消無息。我們沒有與任何 Discord 員工談過任何事情，除了在 2 月初（在最初的反對聲浪之後不久）偷看一下 allowed_mentions 功能。

直到他們在 2020 年 4 月 7 日的 blog 中公佈了他們對未來的計劃之前，我們才知道 Discord 計劃做什麼。在這篇 blog 中，Bot 和 API 團隊公佈了他們透過展示 Figma 範例來說明他們希望如何將 BOT 整合到生態系統中，從而展示他們對該平台的未來願景。他們展示了許多概念，例如環境選單、按鈕和臨時訊息。我們中的許多人終於對即將到來的變化感到興奮。

不幸的是，隨著有關平台未來的消息傳來，對平台的額外限制傳出了警訊。我們不再需要填寫常規的兩個文本和勾選框表單，而是需要填寫整個調查問卷。最重要的是，需要提供政府頒發的 ID（譯註：例如身分證字號）以驗證您的 BOT，BOT 才能收到驗證複選標記以及個人資料徽章（後來停止使用）。如果不使用侵犯隱私的驗證系統，就不可能列入白名單使用 Privileged Intents。如果不通過這個驗證系統，就不可能讓你的BOT加入超過 100 個伺服器。

Discord 聲稱這樣可以透過防止惡意 BOT 增長和獲取敏感資料來幫助提高安全性和隱私性。程式庫開發人員回應說這無濟於事，因為惡意 BOT 仍然必須被邀請才能加入伺服器，而惡意 BOT 的癥結仍然是 user-bot。更不用說在之前的提案中，禁止所謂的惡意的 Privileged Intents 仍然會使您的 BOT 增長到超過 100 個伺服器。Blog 中透露的最終提案已經規定，任何加入超過 100 個伺服器的 BOT 都需要使用政府頒發的 ID 進行驗證，無論其是否禁用了 Privileged Intents。

由於在這個話題上有很多阻力，我做了一個表格來徵求當時開發者生態系統的意見，並收到了大約 1600 條回覆。我曾試著把結果分享給 Discord，希望可能改變他們對這個概念的看法或讓他們深入了解開發人員的感受，但他們告訴我，我的樣本量太小，無法列入考慮。稍有統計學知識的人都知道，1600 這個樣本數並非微不足道。更何況，大多數進行調查的人並不喜歡分享他們政府頒發的 ID 來驗證 BOT：

有很多關於 BOT 開發人員對變化的感受的數據，由於 Discord 員工不想看，我最終也沒能向他們展示。 大約在這個時間點，我的大部分動力都在消退。 我反對其核心的驗證系統，因為我認為它是侵犯性的和不必要的。 當向 Bot & API 團隊的項目經理 Mason 詢問我的 BOT 是否可以在未經驗證的情況下連接到 gateway 時，他粗魯地回答並用不必要的威脅語氣稱我為「烈士」：

「請問如果我可以在未經驗證的情況下連接到 gateway 嗎？」「只要我還在，我們就不會封鎖你們的 gateway 連線，除非你希望我們這麼做。很樂意能為一位烈士的事業盡心盡力。」

官僚災難

在打算驗證生態系統中的 BOT 之後，支援人員立即被請求淹沒，導致他們之前的「5 天 SLA」承諾完全失效。整個 BOT & API 團隊必須共同努力，才能確保他們能夠滿足驗證 BOT 的人員的需求。然而，儘管他們盡了最大的努力，但在 2020 年一整年中，驗證進度一直落後數週甚至數月，這種情況一直持續到 2021 年的今天。

Discord 最初使用「經過驗證的BOT開發者」徽章作為激勵，讓人們在生態系統中的努力得到「認可」。據他們說，這導致大量的人為了獲得徽章而申請驗證。最終，他們完全撤銷了徽章，並將徽章名稱更改為「早期驗證 BOT 開發者」。不移除徽章導致了有徽章的帳號進入了帳號黑市。在任性地截止徽章活動後，沒有獲得徽章的 BOT 開發人員的憤怒聲浪讓 Discord 員工重寫歷史，他們把那些只是要求獲得徽章的人給靜音了。他們將這種行為稱為「要求徽章」（badgeposting）。

「如果你們持續要求徽章，很不幸地，我會先被迫靜音你們。」

官方網站上當初對徽章的介紹：「你的團隊將會收到『經過驗證的BOT開發者』徽章，作為Discord開發者的成功的象徵。」同樣是官方人員在Discord上對於要求徽章的回應：「徽章並不是『成功的象徵』。如果你們這樣解讀，這是你們的問題。」

Discord 在整個 2020 年始終承諾他們將會實現傳說中的 5 天 SLA。儘管 Discord 指責徽章阻塞了驗證隊列，但問題並未解決。 我個人看不到這種穩定的 5 天 SLA 發生的未來。儘管僱傭了更多的支援人員來處理隊列，但進度仍然落後一個月，而且只會變得更糟，因為會有更多的人在截止日期前的接下來幾個月重新申請他們的 intent 請求。

斜線命令

2020 年 7 月和 8 月左右，Discord 員工開始與 Discord 基礎架構伺服器中的人員討論「斜線命令」（Slash Commands）最終進入 Discord 的可能性。 這個功能從 Discord 的歷史一開始就一直處於討論中，所以有些人大肆宣傳它終於要來了。 不幸的是，大約在同一時間，Discord 員工暗示「訊息內容」（message content）將被刪除或限制。

「他們計劃把 MESSAGE_CREATE 的內容鎖定在 previledge intent 之下，強迫 bot 開發者們使用斜線命令。」

在我的內線與我分享這些圖片後，我決定分享給我們私人伺服器中剩餘的程式庫開發人員。我們開始將斜線命令的引入視為對於我們舊工作的一種破壞。在這時候，斜線命令其實還沒有發布，主要處於開發階段。然而，我們認為當斜線命令被引入並公開時，他們會同時刪除訊息內容。

不久之後，Discord 基礎架構伺服器中的人員獲得了實作斜線命令用的 EA beta 版本。我的內線還給了我一份未公開的 gist，解釋系統將如何工作。 Discord 員工直到後來才與我們分享這份 gist 或資訊。當他們最終與我們分享 gist 時，他們計劃與我們會面，討論他們希望系統如何運作。我沒有參加，因為時間是在我工作的時候。參與的程式庫開發人員表示他們分享了很多關於他們希望斜線命令如何運作的意見，但大多數意見最終都被棄之不顧。

當斜線命令的測試版進入公開階段時，許多社群最終重複了程式庫開發人員和大型 BOT 開發人員與 Bot & API 團隊分享的相同批評和意見。在來自社區的一定壓力之後，他們終於實施了一些更改，儘管權限仍然是一個巨大的痛點。從根本上說，斜線命令有一個致命的缺陷：它們與用戶無關。這意味著傳統權限不適用於斜線命令。對於傳統 BOT，伺服器管理員可以透過關閉「讀取訊息」的權限來阻止特定 BOT 在某些頻道發言。對於斜線命令 BOT 則不可能這麼做，因為斜線命令會繞過所有形式的權限。

我們被告知權限系統會隨著時間的推移而改進，但迄今從未實現。斜線命令（又被稱作「互動」（interaction））繞過「@everyone」權限的能力直到 2021 年 5 月，也就是在問題被回報後的 6 個月後才得到修復。

訊息內容 Privileged Intent

大約在 2021 年 6 月上旬，我們聯繫了前 8 名最受歡迎的程式庫開發人員，討論了一個關於生態系統中對我們所有人都很重要的主題的特別會議。了解我們對訊息 intent 的了解程度後，我們認為這將是我們保護生態系統免受破壞並希望讓他們改變對整個事情的看法的最後機會。會議受到保密協議的約束，這讓我們不願簽署，但由於我們相信並被告知這將是我們在談判桌上獲得席位的最後機會，因此我們都同意唯一的目的是說服開發人員認為這個方向是個壞主意。

不幸的是，由於受保密協議的法律約束，我無法分享太多細節。但是，我必須說，所有程式庫開發人員的士氣下降得非常快。

我們所有的程式庫開發人員都反對將訊息內容更改為 Privileged Intents。它陷入了與其他 Privileged Intents 相同的官僚主義問題，但有著更具破壞性的後果。生態系統中的許多 BOT 都面臨著抉擇，要嘛重寫以迎合我認為沒有必要的更改，要嘛死亡。 Discord 似乎相信這種變化是為了變得更好──但他們沒有去探索或提出替代選擇。相反，他們選擇直接部署核彈，並希望以這種方式解決問題。 Discord 還認為，大多數 BOT 將在給定的時間行程內完全轉移到新的架構下。我不相信會出現這種情況。

未來的方向

Discord 計劃了很多事情，以便將來用戶可以更輕鬆地進行過渡。我不確定他們是否會在現在和截止日期之間真正完成所有這些計劃的改進。從歷史上看，他們只能在截止日期開始前一個月完成這些更改。與其在強迫用戶適應之前改善系統，他們決定首先宣布更改，然後再真誠地承諾他們將實施使過渡更加平滑的必要功能。這使得 BOT 開發人員沒有時間實際讓他們的 BOT 適應這些變更，因為所謂遷移用的功能尚不存在。

Discord 已經開始以草率的方式匆忙推出功能。環境選單作為較新的功能之一，收到了許多程式庫開發人員和 BOT 開發人員的大量意見，要求對類型（type）進行徹底檢查和拆分，以防止程式庫損壞並讓 API 更直觀易懂。儘管大多數用戶都在該功能的私人測試版中提供了如此簡單的意見，但卻很明顯地被忽略了，而 Discord 的員工聲稱他們只是想快速推出一些東西。

我不相信空等這些承諾會改善什麼，因為歷史證明了這些承諾的空洞。 我認為到 2022 年 4 月，情況不會從根本上改善，也不認為這種變化值得對生態系統產生持久的影響。 不幸的是，這是最終決定，我現階段唯一能做的就是遠觀。 我沒有動力去跟上我不再相信的生態系統。我希望一個豐富的 BOT 生態系統蓬勃發展，讓 BOT 充分發揮其潛力，但 Discord 一再認為限制才是上策。 這就是為什麼我決定辭去這個項目的維護者的職務。 我對 discord.py 和 API 的參與總是充滿熱情和希望。 但最近的這些變化讓我完全厭倦了這兩件事。

FAQ

我想那些想要了解細節的人會有很多問題。

為什麼停止開發？

自從引入驗證系統以來，我在 Discord 上工作的動力在過去一年中一直在減弱。在沒有 Discord 員工適當諮詢的情況下，持續的裝聾作啞、截止日期、謊言、煤氣燈效應和快速變化使我很難有必要的動力來應對頻繁的變化和施加在我身上的限制。

對我來說，訊息內容的 Privileged Intents 象徵著我們這些程式庫開發者所相信的創作自由和草根駭客的結束。現在控制權被倒置，事情只能圍繞 Discord 的局限性進行構建。BOT 不再會在僅受您想像力限制的沙盒中茁壯成長，而 Discord 現在是唯一能批准各方use cases的守門員。 Discord BOT 的未來完全依賴於 interaction 系統；事情必須由 Discord 員工明確編寫和支持，創造性的解決方案被擱置一旁。如果將來整個 gateway API 受到限制和棄用，我不會感到驚訝，唯一推薦的方法是創建完全基於 interaction 或基於 HTTP 的 BOT。我對 Discord BOT 的未來感受不到真正的希望。

但是，我不想給人一種 Discord 正在構建的東西並不酷的印象。他們確實很酷。按鈕和 UI 擴展等功能是我們自 2016 年以來一直想要的功能，很高興在平台中看到它們。只是這些功能加上了一種難以吞嚥的藥丸，會破壞整個生態系統。這是我不太願意付出的代價。

現在發生了什麼？

開發將會停止，repository 將進入唯讀模式。

我能做什麼？

不幸的是，除了告訴 Discord 你對這些變化的看法之外，你沒有什麼可以做來阻止這列火車。 生態系統破壞的想法給我帶來了很大的壓力和精神痛苦。 在過去兩個月的大部分時間裡，我都試圖向各種 Discord 員工傳達我的痛苦，但無濟於事。 Discord 似乎相信九個月後一切都會好起來的，但我不認同這種思維過程。

我的 BOT 會怎麼樣？

這種變化是根本性的，即使我被排除在方程式之外也一樣。Discord 預計到 2022 年 4 月前，所有 BOT 都將改用斜線命令——無論我是否提供支援。我為斜線命令提出的 API 與目前命令擴展的程式碼並不兼容，因為這兩個系統在範式（paradigm）上根本不同。 這意味著無論我選擇走哪條路，絕大多數程式庫用戶無論如何都需要重寫他們的代碼。

應該指出的是，Discord 希望所有超過 75 個伺服器的 BOT 在可預見的未來都改用斜線命令。 如果要申請訊息內容 intent，則不能將其用於命令處理目的；他們會明確否認你的意圖。 因此，實際上，每個人都必須改投斜線命令麾下才能讓 BOT 正常運行。

「雖然好像問過了，『我想要不用斜線命令來實現命令功能』並不是申請 intent 的有效理由對吧？」「沒錯。」

「想要使用舊的命令系統是申請權限的有效理由嗎？」「不，『我喜歡舊方式，我想這麼做』本身並不是批准的理由。」

我希望 BOT 能繼續運作！

在 8 月 4 日的開發人員問答環節中，BOT和 API 團隊的項目經理 Mason 鼓勵您重寫BOT，因為它「簡單」且「酷炫」。

嗯，流行的程式庫。不過，我們顯然無法控制第三方程式庫。他們是「第三方」。嗯，我們嘗試與他們密切合作，讓他們了解變化，嗯，回答他們關於實現、API 和一致性的問題，以及「嘿，這個 API 是否很糟糕」。呃，Slash Commands 自去年 12 月以來一直處於開放的開發者測試版中。 直到再過九個月後才會發生變化。 如果我數學沒有問題，那麼自從首次發布斜線命令以來，提供了 1 年 4 個月 / 16 個月的時間來適應這些變化。嗯，許多程式庫確實有支援斜線命令，有些則有非官方的fork來支援。我還要說，對於那些勇敢的開發人員來說，斜線命令在沒有程式庫的情況下也能很好地使用，但我知道這是一項更大的任務。嗯，但是如果您還沒有用過基於 HTTP 和傳出 webhook 的斜線命令，這是個非常酷炫且極易於擴展的東西。

因此，如果您希望您的BOT繼續工作，您有幾個選擇：

1.自己實現斜線命令系統。 程式庫（v2）提供了 on_interaction 來幫助你做到這一點，並且所有 endpoints 在技術上都在 bot.http 裡面。 2. 使用原始 API 實現斜線命令系統。 3. 等待具有競爭力的 discord.py fork 到來。 4. 使用新程式庫或不同的程式語言重寫您的 BOT。

2022 年四月前不會改善嗎？還有很多時間啊！

Discord 一再表示，他們相信到 2022 年 4 月一切都會好起來：

我們真心不認為這會發生。我們相信有足夠的時間讓所有 BOT 進行遷移。

然而，實際情況是大量的程式庫沒有實現斜線命令。 以下是支援列表：

程式庫	實作狀態	備註
discord.py	沒有支援
Discord.NET	沒有支援
Sleepy Discord C++	沒有支援
discordgo	沒有支援
disgord	沒有支援
discordjl	沒有支援
Dimscord	沒有支援
DSharpPlus	沒有支援
DiscordPHP	沒有支援	原本的實作已過期
Discordia	部分支援	不穩定 / 未發行
Eris	部分支援	不穩定 / 未發行
discord.rb	部分支援	不穩定 / 未發行
nyxx	部分支援	未發行
Ackcord	部分支援	未發行
discord.js	支援
JDA	支援
Discord4J	支援
Javacord	支援
Serenity	支援
Twilight	支援
nostrum	支援
Kord	支援

這裡包含了以任何形式實現它的程式庫，無論是在 master 還是其他分支中。 Discord 不僅期望其餘程式庫實現整個斜線命令功能，而且還期望所有用戶在截止日期前遷移。人們還有其他與 Discord 生態系統無關的事情要做，因此要求所有用戶都這樣做是荒謬的。

Discord will give us messages that mention us, that means everything will be better... right?

很不幸的是，不。這是個貼在一個非常大的傷口上的微小繃帶。實際上，儘管收到了提到 BOT 的訊息，但訊息 intent 的所有不好的一面（正如前面所說）都仍然適用。即使在這個 BOT 開發人員維護其訊息內容命令的烏托邦中，這也意味著用戶都必須重新學習 bot 前綴，相當不利於可用性。

我可以接手這個程式庫嗎？我可以維護！

不幸的是，我不打算給那些我不信任的人提供維護狀態。 這裡有一個安全問題，我感到不舒服，未知的第三方可以上傳針對一群 Discord 用戶的惡意軟體。 需要注意的是，我確實問過我願意轉手程式庫的對象，但他們都拒絕了，他們尊重我的決定並同意我的意見，他們也不喜歡 Discord 的發展方向。

但是，您可以自由地自己 fork 項目並實作您尋求的改進。

為什麼不實作斜線命令？

簡而言之：這不好玩。對我來說，實施斜線命令並不是特別困難，而且我已經在 2021 年 5 月製作了一個幾乎能用但非常不完整的本地副本。但是，我幾乎沒有繼續工作的動力。斜線命令代表了 Discord 中的方向變化，我根本不同意的變化。不幸的是，為了給平台增加更多的限制，這個功能被趕鴨子上架。

請注意，我的斜線命令的實作與 discord.ext.commands 實作完全不同，因為這兩種模型嚴格不兼容。 所以即使我發布了我的實作，大多數用戶也不得不完全重寫 BOT 來支援新的版本。

discord.py 伺服器會怎麼樣？

理想情況下，什麼都沒有。 我不打算對伺服器做任何事情，它可以保持原樣。 該程式庫仍在運行，並且仍然有很多用 discord.py 編寫的程式碼。 更重要的是，伺服器在我心中佔有特殊的位置，擁有一個我引以為豪的社區，我認為沒有理由將其燒成灰燼。

Discord API 伺服器呢？

一樣。 那裡什麼都不會發生。

R. Danny 呢？

由於未來將會上路的訊息內容 intent，我的 BOT 很可能會死，因為它無法進行調節。 如果你想知道我的 BOT 對我來說意味著什麼，當我與 Discord 員工討論這個話題時，我寫了一篇關於這個話題的單獨的 write-up。

你會考慮再次選擇這個項目嗎？

我不知道。這個決定來自 Discord 員工多年的不滿，族繁不及備載。 我不認為它們會被修復或在未來變得更好，但只有時間會證明。

如果不是 Discord 決定採取的方向，我會很樂意繼續在 discord.py 上工作。 實際上，我真的很喜歡這個程式庫，如果時間允許的話，我很想探索很多東西。 然而，在程式庫所做的一切背後，是一個公司實體，它一再給我帶來了多年來積累的這些不滿。很難將兩者徹底分開。

我的問題不在這裡！

我的錯。 如果在公告期間出現更多問題，我會將它們添加回此處，或者您可以直接在 discord.py 伺服器中詢問我，我會盡力回答。

我真的生你的氣了！

對不起。

銘謝

I'd like to thank the following people for all the help and support they've given me over the years, in alphabetical order.

• aj. Thanks for being the most responsive Discord staff I've ever been in contact with. Your willingness and proactivity when working with us was unparalleled and much appreciated.
• Bryan Forbes. Thanks for taking the time and effort to type hint the library initially. It was of great help.
• Gary. Thanks for being a supporter in the discord.py server and for being so kind to everyone in the server and to me. I greatly appreciate it.
• Hornwitser. Thanks for providing early design feedback for discord.py and untangling the spaghetti in the initial dispatch code.
• Ian Mitchell. Thanks for listening to my incoherent rants and frustration and trying to make things better.
• Ian Webster. Thanks for actually being kind enough to communicate with us when things went way south.
• Imayhaveborkedit. Thanks for being the go-to voice wrangler all these years when I couldn't be bothered.
• Jake. Thanks for actually being our pillar and maintaining the sanity in our Discord API server. Without you, we would have lost our vanity and many more things would have been worse. We'd often say that without your presence our server would cease to exist.
• LeoV. Thanks for being there early on and helping design the logo for the documentation.
• "Mole", you know who you are. Thanks for shedding light into the inequality that us library developers faced.
• NCPlayz. Thanks for being one of the only other persistent contributors to the library. Without you, implementing some features would have been too taxing to do alone.
• spoopy. Thanks for maintaining the code early on and providing invaluable feedback.
• Stanislav. Thanks for being our go-to contact early on in the API days. It was fun.
• The discord.py community. Thanks for being you.
• The other library developers. Thanks for sticking together through all the nonsense. Without our unity I'm pretty sure I would have quit long ago.
• The Red-DiscordBot community. Thanks for being kind and respectful to me. The feedback you guys gave when working with the command framework was invaluable to me.
• The various contributors for discord.py. Thanks for improving various things throughout the library; even the most minor contribution has a large impact.
• The various helpers in the discord.py server. Thanks for taking on a bulk of the hard work which usually goes unappreciated.

當然，也感謝你讀完這一切。

再見。