Les transports Slack dans OpenClaw

Le mode Socket et les URL de requête HTTP atteignent la parité de fonctions pour la messagerie, les commandes slash, App Home et l’interactivité, donc le choix porte sur l’endroit où tourne la passerelle plutôt que sur ce qu’elle sait faire. Voici la comparaison que dresse la documentation, l’avertissement sur plusieurs connexions pour une même application, le mode relais pour les équipes qui veulent une seule entrée et plusieurs passerelles, et les règles d’exécution de la connexion en mode Socket.

La comparaison

• Le mode Socket n’exige aucune URL publique de passerelle mais doit atteindre en sortie l’hôte websocket de Slack, tandis que le HTTP exige une URL publique avec DNS, TLS et un proxy inverse ou un tunnel et seulement du HTTPS entrant ; le mode Socket s’authentifie avec le jeton de bot ou d’utilisateur plus un jeton d’application portant la portée d’écriture des connexions, le HTTP avec le jeton de bot ou d’utilisateur plus le secret de signature qui vérifie chaque requête signée.
• Un portable de développement ou un hôte derrière un pare-feu fonctionne tel quel en mode Socket et exige un tunnel public ou une passerelle de préproduction en HTTP ; le mode Socket n’admet qu’une session par application et par hôte, si bien que plusieurs passerelles exigent des applications Slack séparées, tandis que le HTTP est un gestionnaire sans état qui laisse plusieurs répliques partager une application derrière un répartiteur de charge.
• Les deux prennent en charge plusieurs comptes sur une passerelle, chaque compte en mode Socket ouvrant son propre websocket et chaque compte HTTP exigeant un chemin de webhook unique ; les commandes slash arrivent par le websocket en mode Socket, où l’URL de commande est ignorée, et sont publiées vers l’URL de commande en HTTP, où le champ est requis pour la distribution.
• Sur une coupure de connexion, le SDK de Slack se reconnecte automatiquement et OpenClaw redémarre les sessions en mode Socket échouées avec un délai borné sous un délai de pong client fixe de 15 secondes, tandis que le HTTP n’a pas de connexion persistante et que Slack réessaie par requête ; la documentation choisit le mode Socket pour les hôtes à passerelle unique, les portables et les réseaux internes avec accès sortant, et le HTTP pour les répliques derrière un répartiteur, les websockets sortants bloqués ou un proxy qui termine déjà les webhooks.

Choisissez selon la forme du déploiement, pas selon les fonctions.

Connexions multiples et mode relais

Slack peut maintenir plusieurs connexions en mode Socket pour une même application et peut livrer chaque charge à n’importe laquelle, si bien que des passerelles OpenClaw séparées qui partagent une application Slack exigent une configuration de routage et d’autorisation équivalente ; sinon vous utilisez une application par passerelle, une entrée de relais unique, ou le HTTP derrière un répartiteur de charge. Le mode relais est cette entrée unique : un routeur de confiance détient l’unique connexion en mode Socket, choisit une passerelle de destination et transmet un événement typé par un websocket authentifié, tandis que la passerelle utilise toujours son propre jeton de bot pour les appels sortants à l’API web. La configuration règle le mode sur relais avec le jeton de bot et un bloc de relais portant l’URL du routeur, un jeton d’authentification et un identifiant de passerelle. L’URL de relais doit utiliser des websockets sécurisés sauf si elle vise localhost, et le jeton porteur et la table de routes du routeur font partie de la frontière d’autorisation Slack, parce que les événements routés entrent dans le gestionnaire de messages normal comme des activations autorisées. Une identité Slack fournie par le routeur dans la trame de salutation peut fixer le nom et l’icône sortants par défaut, une identité explicite de l’appelant l’emportant toujours, et le relais se reconnecte avec le même délai borné que le mode Socket et efface cette identité à chaque déconnexion. Les websockets de relais honorent l’environnement de proxy de l’hôte de la passerelle, les variables de proxy HTTPS, HTTP et ALL en majuscules et en minuscules et la liste d’exclusion : un relais sécurisé utilise un tunnel HTTP CONNECT quand un proxy est configuré, une entrée d’exclusion correspondante ou un websocket simple vers localhost se connecte directement, et les erreurs de proxy sont signalées plutôt que de retomber en silence sur une connexion directe.

Le mode Socket à l’exécution

• OpenClaw règle le délai de pong client du SDK Slack à 15 secondes pour le mode Socket, une valeur interne fixe que les opérateurs ne peuvent pas changer.
• L’objet de réglage du mode Socket avec ses clés de délai de ping client, de délai de ping serveur et de journalisation des ping-pong est retiré et n’est plus lu ; le doctor signale les réglages retirés par un avis général, sa correction retire ces trois champs à la racine du canal et sous chaque compte et supprime l’objet une fois vide, en vous laissant supprimer à la main toute autre clé que vous y auriez ajoutée, et les messages et événements d’application restent un état applicatif plutôt qu’un signal de vivacité du transport.
• Le délai de redémarrage commence vers deux secondes et plafonne vers trente, les échecs récupérables de démarrage, d’attente de démarrage et de déconnexion sont réessayés jusqu’à l’arrêt du canal, et les erreurs permanentes de compte et d’identifiants comme une authentification invalide, des jetons révoqués ou des portées manquantes échouent vite au lieu de réessayer indéfiniment.

OpenClaw sur Slack est le billet du canal que ces transports portent, et Configurer Slack dans OpenClaw l’endroit où chacun se configure.

Pourquoi une application par passerelle

L’avertissement sur les connexions multiples est celui qui piège les équipes qui font tourner une passerelle de préproduction et une de production sur la même application Slack : Slack enverra volontiers la moitié des événements à chacune, et seul un routage identique des deux côtés empêche que cela se voie. L’accès à distance d’OpenClaw couvre la façon dont une passerelle obtient une origine publique pour le chemin HTTP, et Slack Enterprise Grid dans OpenClaw l’installation entreprise où le mode relais n’est pas disponible du tout.

Sur Diali

Slack fait partie des canaux que Diali connecte depuis le tableau de bord, la configuration d’exécution étant générée et remplacée à chaque version, donc le transport qu’un agent hébergé utilise fait partie de cette configuration générée plutôt que d’un choix fait à la main. Slack sur Diali est le canal sur Diali et OpenClaw hébergé sur Diali l’assistant derrière lui.

• Le mode Socket n’exige pas d’URL publique ; le HTTP s’étend derrière un répartiteur.
• Deux passerelles sur une application doivent router à l’identique, ou passer par le relais.
• Délai de deux à trente secondes ; les mauvais identifiants échouent vite.