Privilegierte Intents und Bot-Verifizierung: Was Discord deinen Bot lesen lässt — und was nicht

Zwei Mechanismen entscheiden, was ein Discord-Bot sehen kann: Intents, mit denen er die Ereignisklassen deklariert, die er empfängt, und die Verifizierung, die die sensiblen davon absichert, sobald der Bot breit installiert ist. Beide werden meist mitten im Projekt entdeckt — der teuerste Zeitpunkt.

Was ein Intent ist

Öffnet ein Bot seine Gateway-Verbindung, deklariert er, welche Kategorien von Ereignissen er will. Discord schickt dann nur diese. Das existiert aus Skalierungsgründen — ein Bot, den Voice nicht interessiert, sollte nicht jede Voice-Änderung in jedem Server empfangen — und ist zur wichtigsten Datenschutzkontrolle der Plattform geworden.

Die meisten Intents sind unbeschränkt: Guilds, Nachrichten, Reaktionen, Voice-Status. Drei sind privilegiert, und dort sitzt die Reibung.

Die drei privilegierten Intents

Server Members umfasst die Mitgliederliste sowie Beitritts- und Austrittsereignisse. Presence umfasst Online-Status und Aktivität. Message Content umfasst den eigentlichen Text von Nachrichten samt Embeds, Anhängen und Komponenten — mit der wichtigen Ausnahme, dass ein Bot Inhalte immer sieht bei Nachrichten, die er selbst gesendet hat, in Direktnachrichten an ihn und in Nachrichten, in denen er erwähnt wird.

Diese Ausnahme ist der Designhebel. Ein Bot, der per Erwähnung oder Slash-Command aufgerufen wird, braucht den Message-Content-Intent nicht, um das zu lesen, womit er aufgerufen wurde. Ein Bot, der alles scannt, um ein Auslösewort zu finden, schon.

Die Hundert-Server-Schwelle

Unterhalb von rund hundert Servern kann ein Entwickler privilegierte Intents im Developer-Portal ohne Prüfung einschalten. Ab dieser Zahl muss der Bot verifiziert werden, und die Intents müssen einzeln beantragt und genehmigt werden.

Für einen Bot, der für eine einzige Community gebaut ist, kommt diese Schwelle nie — ein echter und unterschätzter Vorteil eines eigens gebauten Bots: Er darf nutzen, was er braucht, ohne Prüfverfahren, und wird nicht von einer Richtlinienänderung abgeschaltet, die auf öffentliche Bots zielt.

Was die Verifizierung tatsächlich verlangt

Die Verifizierung verlangt eine Begründung für jeden privilegierten Intent, gemessen an dem, was der Bot tut. Eine vage Antwort oder ein Intent, den die beschriebenen Funktionen nicht brauchen, ist der übliche Grund für eine Rückfrage. Praktisch heißt das: „Vielleicht brauchen wir das später" trägt nicht — und darauf zu bauen kostet eine Neufassung.

Zum Verfahren gehört außerdem eine Identitätsprüfung des Entwicklerkontos. Gut zu wissen, bevor man ein Geschäft auf ein anonymes Konto stellt.

So entwirfst du ohne Nachrichteninhalte

Fast alles, was Communities von einem Bot wollen, lässt sich auf Interaktionen bauen. Slash-Commands tragen ihre Argumente selbst. Buttons und Auswahlmenüs tragen die Identität dessen, der sie gedrückt hat. Modals sammeln strukturierte Eingaben. In jedem Fall bekommt der Bot genau das, was er braucht, und nichts sonst.

Die Funktionen, die Nachrichteninhalte wirklich brauchen, sind schmal: Keyword-basierte Automoderation, die Discords eigenes AutoMod inzwischen nativ abdeckt, und Auswertungen über Nachrichtentexte, die den Datenschutzpreis selten wert sind. Braucht deine Spezifikation den Intent, lohnt die Frage, ob die Funktion es wert ist — Discord wird sie dir ohnehin stellen.

Presence ist teurer, als es aussieht

Der Presence-Intent erzeugt ein sehr hohes Ereignisvolumen — jede Statusänderung jedes Mitglieds in jedem Server. Bei einer großen Community dominiert er den Traffic und den Speicher des Bots, meist für eine Funktion, nach der niemand gefragt hat. Solange keine dokumentierte Anforderung von Live-Präsenz abhängt: aus lassen.

Skalierung ändert die Form

Ab einigen tausend Servern muss ein Bot seine Gateway-Verbindung über mehrere Sockets sharden, und das globale Anfragelimit plus routenspezifische Limits beginnen alles einzuschränken, was über Mitglieder iteriert. Ein Ein-Community-Bot umgeht das vollständig; ein öffentlicher Bot ist von Anfang an darum herum gebaut. Das sind verschiedene Produkte — und von einem zu verlangen, sich wie das andere zu verhalten, ist der Anfang der meisten „unser Bot ist langsam geworden"-Geschichten.

Was du fragen solltest, wenn du einen beauftragst

Welche Intents braucht das, und warum jeder einzelne. Was passiert, wenn der Bot eine Stunde ausfällt. Wo liegen die Daten und wer kommt daran. Setzt der Entwurf Nachrichteninhalte voraus, und wenn ja, wie sähe die Funktion ohne aus. Vier Fragen — und die Antworten sagen dir, ob das Ding entworfen oder zusammengesetzt wurde.

Was passiert, wenn ein Intent abgelehnt oder entzogen wird

Ein Intent ist nicht dauerhaft vergeben. Er kann bei der Verifizierung abgelehnt und später entzogen werden, wenn die Begründung nicht mehr zu dem passt, was die App tut. Dann bleiben die Ereignisse einfach aus — der Bot stürzt nicht ab, er wird still, und das ist der deutlich schlechtere Fehlerfall.

Der defensive Entwurf ist, laut zu scheitern. Prüfe beim Start, welche Intents tatsächlich gewährt wurden, protokolliere einen klaren Fehler, wenn ein benötigter fehlt, und deaktiviere die betroffene Funktion ausdrücklich, statt sie leise nichts tun zu lassen. Ein Bot, der ansagt, was er nicht kann, ist debugbar; einer, der so tut, als sei alles in Ordnung, nicht.

Ohne die privilegierten testen

Eine verbreitete Falle: Der Bot funktioniert in der Entwicklung, wo er in einem Server läuft und der Entwickler alle Intents eingeschaltet hat, und verhält sich in Produktion anders. Entwickle mit genau den Intents, die die Produktions-App bekommen hat, nicht mit allen.

Dasselbe gilt für Berechtigungen. Teste mit der Rolle, die der Bot wirklich haben wird, an der Position, die sie in der Hierarchie wirklich einnimmt — die Mehrheit der „gestern ging es noch“-Meldungen kommt von einer geänderten Rollenreihenfolge und nicht vom Code.

Einen bestehenden Bot von Nachrichteninhalten lösen

Übernimmst du einen Bot mit Präfix-Kommandos, ist die Migration überwiegend mechanisch: Jedes Präfix-Kommando wird ein Slash-Command mit typisierten Argumenten, jeder Keyword-Auslöser wird ein Button, ein Kontextmenü-Eintrag oder eine AutoMod-Regel. Die Arbeit steckt in der Inventur, nicht in den einzelnen Umbauten.

Mach die Inventur ehrlich. Die meisten Alt-Bots haben eine Handvoll Kommandos, die jemand benutzt, und einen langen Schwanz, den seit einem Jahr niemand aufgerufen hat. Diesen Schwanz zu migrieren lässt das Projekt teuer aussehen; ihn zu löschen ist meist richtig — und die Entscheidung, die niemand treffen will.

Die Checkliste im Developer-Portal

Bevor ein Bot in die Nähe der Produktion kommt: Intents genau auf das gesetzt, was der Code nutzt; die OAuth-Einladung auf die wirklich nötigen Rechte zugeschnitten statt auf Administrator; der Token außerhalb des Repositories; Zwei-Faktor-Authentifizierung auf dem Entwicklerkonto; und eine Beschreibung im Portal, die zu dem passt, was die App tatsächlich tut — denn diese Beschreibung liest eine Prüferin.

Nichts davon dauert eine Stunde, und alles davon ist schwerer nachzuziehen, sobald der Bot in einer Community läuft, die von ihm abhängt.