La présence dans OpenClaw

Quels clients sont connectés à ma passerelle en ce moment, d’où, et à faire quoi ? OpenClaw y répond par la présence : une vue légère et au mieux de la passerelle elle-même et des clients visibles qui lui sont connectés, l’application macOS, WebChat, les nœuds et le reste, affichée sur la page des appareils de l’interface de contrôle et l’onglet des instances de l’application macOS. Voici les champs d’une entrée, qui peut lire la liste, d’où viennent les entrées, comment elles sont fusionnées, quand elles expirent, et les conseils de débogage pour les lignes en double.

Ce que porte une entrée

• Un identifiant d’instance stable, fortement recommandé, un nom d’hôte lisible, le type de client distinct de son nom d’affichage, une IP au mieux que l’extension de géolocalisation peut résoudre en ville approximative, une chaîne de version, des indices de matériel, et un fuseau IANA auto-déclaré qui reste utile quand l’IP est en boucle locale, tunnelisée ou derrière le NAT d’un opérateur.
• Un mode parmi ui, webchat, cli, backend, node, probe et test, les secondes depuis la dernière saisie de l’utilisateur quand elles sont connues, une raison libre où la passerelle elle-même n’émet que self, connect et disconnect, et l’identifiant d’appareil, les rôles et les portées de la poignée de main de connexion.
• Un horodatage de dernière mise à jour qui inclut les battements de cœur et n’est pas un horodatage d’activité de l’utilisateur, le début de la période en ligne continue courante de la personne authentifiée, partagé entre connexions qui se chevauchent, et la dernière interaction acceptée observée, absente tant qu’aucune activité n’est vue.
• Les clés des sessions que le client déclare explicitement regarder, filtrées pour chaque destinataire.

La passerelle amorce toujours une entrée « self » au démarrage pour que les interfaces montrent l’hôte de la passerelle avant même qu’un client se connecte.

Qui la voit

La liste est partagée avec les opérateurs disposant de l’accès en lecture d’opérateur, et les accès en écriture ou administrateur accordent aussi la lecture. Les lecteurs voient les horaires de connexion et d’activité des autres et leur fuseau déclaré, y compris des personnes qui ne regardent aucune session ; les connexions de nœuds, les opérateurs limités à l’appairage et les autres connexions sans accès en lecture reçoivent une liste vide dans l’instantané de connexion et aucun événement de présence, et l’appel de présence système exige le même accès. Les références de sessions suivies sont filtrées séparément pour chaque destinataire selon les mêmes règles de visibilité que la liste des sessions : les sessions cachées ou manquantes sont omises entièrement sans compte ni espace réservé, les brouillons, les sessions incognito et les restrictions de rôle d’opérateur suivent ces règles, les références supprimées sont omises même pour les administrateurs, et être regardé n’accorde pas au spectateur l’accès à une session. Les abonnements aux messages seuls ne déclarent pas une présence de spectateur. La documentation dit explicitement que cette politique n’isole pas toutes les métadonnées de la passerelle, et que des frontières de confiance de passerelle séparées sont la réponse quand des lecteurs ne doivent pas se voir.

Producteurs et fusion

• Quatre producteurs, fusionnés : l’entrée self de la passerelle amorcée au démarrage, la poignée de main WebSocket qui insère une entrée par connexion acceptée, des balises périodiques plus riches d’événements système que l’application macOS utilise pour le nom d’hôte, l’IP, la version et la vivacité, et les connexions de nœuds avec le rôle de nœud. Les clients en mode cli, backend ou probe ne deviennent volontairement pas des entrées pour que les brèves connexions de plan de contrôle ne traînent pas pendant toute la durée de vie ; les clients en mode test restent suivis parce que les suites les utilisent comme doublures.
• Les entrées vivent dans une seule carte en mémoire à clés insensibles à la casse : les clients WebSocket d’utilisateurs ont une ligne par connexion pour que deux onglets ne s’écrasent pas, les nœuds sont indexés par identifiant d’appareil, puis d’instance, puis de connexion, et les balises fusionnent par identifiant d’appareil ou d’instance quand il est fourni et sinon par hôte analysé ; un identifiant d’instance stable aide les consommateurs à associer les lignes mais ne fusionne jamais des connexions d’utilisateurs distinctes. L’interface de contrôle regroupe les lignes par espace de noms d’identité enregistré, si bien que les connexions partageant une identité de profil qualifiée forment une personne tandis que les connexions non qualifiées de même identifiant brut forment un groupe distinct.
• La présence est volontairement éphémère : les entrées de plus de cinq minutes sont purgées et la carte contient au plus deux cents entrées, les plus anciennes retirées d’abord. À travers un tunnel SSH, la passerelle peut voir le client en boucle locale, donc le traitement de connexion omet l’IP pour les clients détectés locaux plutôt que d’enregistrer l’adresse du tunnel.

OpenClaw à plusieurs utilisateurs explique les fiches de personnes qui séparent la durée en ligne de la fraîcheur du battement de cœur, et Les nœuds d’OpenClaw, les mains distantes les connexions qui apparaissent ici avec le rôle de nœud.

Déboguer les doublons

La page des appareils joint la liste de présence aux enregistrements durables d’appairage et de nœuds, épingle d’abord la balise self de la passerelle et utilise les identifiants d’appareil ou d’instance correspondants pour les métadonnées en direct de plateforme, de version, de modèle et de récence de saisie, tandis que l’application macOS marque chaque instance active, inactive ou périmée selon l’âge de sa dernière mise à jour. Pour voir la liste projetée pour votre propre connexion, appelez la présence système sur la passerelle ; pour les doublons, vérifiez que les clients envoient un identifiant d’instance stable dans la poignée de main, que les balises le réutilisent, et rappelez-vous que des connexions d’utilisateurs distinctes ont des lignes distinctes qui expirent après la durée de vie. La passerelle OpenClaw expliquée est le processus qui tient la carte, et Les sessions d’OpenClaw les clés vers lesquelles pointe une référence de session suivie.

Sur Diali

Sur Diali, la liste vit dans la passerelle de votre assistant comme partout ailleurs : sa propre entrée self, les onglets de navigateur que vous ouvrez sur l’interface de contrôle, et tout ordinateur que vous avez appairé comme nœud, les lignes s’effaçant cinq minutes après leur dernière mise à jour. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit qui peut atteindre cette passerelle.

• Au mieux, en mémoire, cinq minutes, deux cents lignes.
• Une ligne par connexion d’utilisateur ; la CLI et les sondes n’apparaissent jamais.
• Les sessions suivies sont filtrées par lecteur.