OpenClaw sur Nextcloud Talk

Nextcloud Talk est une extension de canal téléchargeable qui connecte OpenClaw à une instance Nextcloud auto-hébergée par un bot webhook Talk. Les messages directs, les salles, les réactions et les messages en markdown sont pris en charge, et les médias partent sous forme d’URL. Voici la configuration, dont la seule fonction du bot qui empêche les réponses d’échouer, les notes qui expliquent la plupart des surprises, le contrôle d’accès des messages directs et des salles, le tableau des capacités, et la référence.

Configuration

• Installez l’extension, puis créez le bot sur le serveur Nextcloud avec la commande occ, un nom, un secret partagé, l’URL du webhook et trois fonctions, webhook, response et reaction ; gardez la fonction response, parce que sans elle les réponses sortantes échouent avec un 401, et un bot existant se répare avec la commande d’état.
• Activez le bot dans les réglages de la salle cible, puis configurez OpenClaw avec l’URL de base et le secret du bot, dans la configuration, comme variable d’environnement pour le compte par défaut, ou par la commande d’ajout de canal dont les options URL et jeton sont des alias des champs explicites d’URL de base et de secret, avec une option de secret dans un fichier.
• Lancez la sonde, démarrez la passerelle si elle est arrêtée ; les changements de configuration se rechargent à chaud, et un environnement de service modifié exige un redémarrage.
• Les bots ne peuvent pas ouvrir de messages directs, donc l’utilisateur doit écrire au bot en premier ; l’URL du webhook doit être joignable depuis le serveur Nextcloud, avec une URL publique de webhook définie quand la passerelle est derrière un proxy.

Les bots ne peuvent pas ouvrir de messages directs. L’utilisateur doit écrire au bot en premier.

Les notes qui expliquent les surprises

Les requêtes de webhook sont signées par un HMAC sur le secret du bot, et les signatures invalides sont rejetées et limitées en débit. Un webhook de message ne renvoie 200 qu’après le stockage durable de l’événement brut, 500 en cas d’échec de stockage, et le 200 durable porte l’en-tête d’acceptation qu’un proxy inverse peut exiger ; les événements non pris en charge qui ne sont pas des messages reçoivent un 200 sans le marqueur et sont journalisés comme ignorés. L’écouteur admet au plus soixante-quatre lectures de corps non authentifiées simultanées, et le débordement reçoit un 429 avec une connexion fermée ; le budget est fixe, donc les déploiements qui le saturent devraient plafonner la concentration en amont et accepter que les livraisons refusées puissent être perdues. Les envois de médias ne sont pas pris en charge par l’API des bots, donc un média sortant est ajouté comme ligne de pièce jointe avec une URL. La charge du webhook ne distingue pas les messages directs des salles : définissez un utilisateur d’API et un mot de passe d’application pour activer la recherche du type de salle, mise en cache environ cinq minutes, sinon chaque conversation est traitée comme une salle. Les requêtes sortantes passent par la garde SSRF, avec une adhésion explicite pour un hôte Nextcloud sur un réseau privé de confiance, et avec les identifiants d’API et l’URL publique définis, la commande d’état sonde le bot et avertit quand la fonction response manque.

Contrôle d’accès

• Les messages directs sont en appairage par défaut, approuvé depuis la CLI ; les messages directs ouverts exigent la politique ouverte plus l’entrée générique, et la liste d’autorisation ne compare que des identifiants d’utilisateurs Nextcloud en minuscules, jamais les noms d’affichage.
• Les salles sont en liste d’autorisation par défaut et filtrées par mention : autorisez les salles par jeton dans une carte des salles, avec une entrée générique comme valeur par défaut, et des clés par salle pour l’exigence de mention, l’activation, une liste d’expéditeurs, des surcharges d’outils, une limite de compétences et un prompt système ; une liste vide ou la politique désactivée n’autorise aucune salle.
• Le tableau des capacités : messages directs, salles et réactions pris en charge ; fils et commandes natives non ; médias par URL seulement.

L’appairage dans OpenClaw explique le code d’approbation qu’envoie le réglage par défaut des messages directs, et Hooks et webhooks dans OpenClaw le contrat d’acceptation durable que suit le webhook.

La référence

Au-delà de l’URL de base et du secret : l’utilisateur d’API, le mot de passe et son fichier pour la recherche de salles et la sonde ; un port de webhook de 8788 par défaut, l’hôte, le chemin et l’URL publique ; les politiques de messages directs et de groupes avec leurs listes d’autorisation et les références de groupes d’accès ; les réglages par salle ; des limites d’historique pour les salles et les messages directs avec des surcharges par message direct ; une limite de morceau de texte de quatre mille, le mode de morceau et les clés de streaming par blocs ; un mode de référence de réponse à all par défaut ; un préfixe de réponse, un mode de tableaux markdown, l’adhésion au réseau privé, et des surcharges par compte avec un compte par défaut. OpenClaw sur Matrix est l’autre protocole auto-hébergé de la liste des canaux pour ceux qui font tourner leur propre serveur.

Sur Diali

Nextcloud Talk ne fait pas partie des canaux que Diali connecte aujourd’hui : ceux que nous faisons tourner sont WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS et la voix, et une instance autogérée est là où vit cette extension pour l’instant. Connecter votre premier canal en cinq minutes montre notre flux de connexion, OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière.

• Trois fonctions de bot, et response est celle qui compte.
• Sans identifiants d’API, chaque conversation est une salle.
• Soixante-quatre lectures simultanées, puis 429.