Événements et exploitation Discord dans OpenClaw

Au-delà des messages, un bot Discord a une poignée de surfaces opérationnelles : ce qu’il fait quand quelqu’un réagit, s’il remarque un coéquipier qui passe en ligne, quel statut il affiche, si le chat peut réécrire sa configuration, comment son trafic quitte l’hôte, et comment il traite les identités relayées. L’extension Discord d’OpenClaw couvre chacune par un petit bloc de configuration. Les voici l’une après l’autre, avec les gardes qui empêchent la fonction de présence de devenir du bruit.

Réactions et événements de présence

• Les notifications de réactions par guilde ont quatre modes, désactivé, propres, le défaut, toutes, et une liste d’autorisation qui utilise la liste d’utilisateurs de la guilde ; les événements de réaction deviennent des événements système attachés à la session Discord routée.
• Une guilde peut adhérer aux réveils de l’agent routé quand un membre humain passe de hors ligne à en ligne : l’intention de présence doit être activée dans la configuration et comme intention privilégiée sur la page du bot de l’application, l’agent routé a besoin d’un battement de cœur activé, et le bloc de guilde nomme un identifiant de canal dont les spectateurs sont éligibles, une liste d’utilisateurs facultative pour les restreindre, une fenêtre de suppression à la reconnexion, une limite de rafale et une fenêtre de rafale.
• OpenClaw amorce les membres actuellement en ligne depuis chaque instantané complet de guilde, route les transitions observées de hors ligne à en ligne, traite un premier signal en ligne ultérieur d’un membre inconnu comme nouvellement disponible sans affirmer de statut antérieur, ignore les bots et les états inchangés, et conserve un délai de huit heures par utilisateur à travers les redémarrages ; l’éligibilité suit la permission de voir le canal sur le canal ou son parent, les fils privés exigeant en plus l’appartenance ou la gestion des fils.
• Quand Discord établit une nouvelle session, les événements dérivés de la présence sont supprimés pendant la fenêtre de reconnexion, trois cents secondes par défaut, tandis que l’état de la guilde se reconstruit, pour que les membres réobservés ne puissent pas réveiller l’agent un par un ; les événements mis en file sont aussi limités par guilde à la limite de rafale, huit par fenêtre glissante de soixante secondes par défaut, une session reprise n’est pas une nouvelle session, et les guildes de plus de soixante-quinze mille membres exigent une mise à jour hors ligne explicite avant de saluer. L’événement porte des identifiants immuables d’utilisateur, de guilde et de canal sans noms d’affichage.

L’agent décide s’il faut saluer et comment.

Statut et présence automatique

Les mises à jour de présence s’appliquent quand un champ de statut ou d’activité est défini ou quand la présence automatique est activée. Un statut seul fixe en ligne, inactif ou similaire ; une chaîne d’activité fixe un statut personnalisé par défaut, et un type d’activité choisit jouer, diffuser, écouter, regarder, personnalisé ou concourir, la diffusion exigeant une URL d’activité et l’URL exigeant à son tour le type de diffusion. La présence automatique est un signal de santé de l’environnement : sain se projette sur en ligne, dégradé ou inconnu sur inactif, et épuisé ou indisponible sur ne pas déranger, rafraîchi toutes les trente secondes avec un minimum de quinze secondes entre les mises à jour qui ne doit pas dépasser l’intervalle.

Écritures, proxy, PluralKit

• Les écritures de configuration depuis le canal sont activées par défaut et affectent les flux des commandes de définition et de retrait de configuration quand les fonctions de commandes sont activées ; un seul indicateur les désactive pour Discord.
• Le trafic WebSocket de la passerelle Discord et les consultations REST au démarrage pour l’identifiant d’application et la résolution des listes peuvent être routés par un proxy HTTP ou HTTPS avec un réglage de proxy explicite, global ou par compte ; les connexions WebSocket n’héritent pas des variables d’environnement de proxy ambiantes du processus de la passerelle, donc le réglage est le seul moyen.
• La résolution PluralKit projette les messages relayés sur l’identité d’un membre du système avec un jeton facultatif pour les systèmes privés : les listes peuvent utiliser un préfixe d’identifiant de membre, les noms d’affichage des membres ne correspondent par nom ou slug que sous l’indicateur dangereux de correspondance par nom, les consultations interrogent l’API PluralKit avec l’identifiant du message d’origine, et une consultation échouée laisse le message relayé traité comme un message de bot, abandonné sauf si le réglage d’autorisation des bots l’admet.

OpenClaw sur Discord est le canal que ces blocs configurent, et Le battement de cœur d’OpenClaw l’exigence derrière les réveils de présence.

Deux sortes de présence

La présence Discord ici est le statut propre du bot et les transitions en ligne des humains d’une guilde ; c’est autre chose que la liste de présence des clients connectés de la passerelle. Les réactions dans OpenClaw couvre l’outil de réaction que les modes de notification complètent, et La présence de la passerelle OpenClaw la liste côté passerelle qui partage le mot.

Sur Diali

Sur Diali, les notifications de réactions et le statut du bot suivent les valeurs amont par défaut pour le bot Discord connecté, et le réveil par événements de présence exige l’intention de présence privilégiée, qui s’active par application de bot dans le portail développeur. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière derrière laquelle se trouve le jeton du bot.

• Les réactions deviennent des événements système ; propres est le défaut.
• Les réveils de présence exigent l’intention, un battement de cœur, et huit heures entre deux salutations.
• La santé devient le statut : en ligne, inactif, ne pas déranger.