Contrôle d’accès et routage iMessage dans OpenClaw

iMessage n’a ni mentions natives, ni listes d’autorisation côté serveur, et une base de discussions qui signale parfois un groupe comme un message privé, donc la couche d’accès d’OpenClaw travaille davantage ici que sur la plupart des canaux. Voici les politiques de messages privés et de groupe, les deux barrières de groupe qui piègent la plupart des installations silencieuses, la mention obligatoire bâtie sur l’identité de l’agent, les invites par groupe, les sessions, les liaisons ACP, et les écritures de configuration.

Politiques de messages privés et de groupe

• La politique de messages privés prend appairage, la valeur par défaut, liste, qui exige au moins une entrée, ouvert, qui exige le joker, et désactivé ; les entrées de liste doivent identifier des expéditeurs, handles ou groupes d’accès statiques d’expéditeurs, tandis que les cibles de discussion par identifiant, GUID ou identifiant textuel vont dans la liste des expéditeurs de groupe et les identifiants numériques de discussion dans le registre des groupes.
• La politique de groupe prend liste, la valeur par défaut, ouvert et désactivé, la liste des expéditeurs de groupe peut aussi référencer des groupes d’accès statiques, une liste d’expéditeurs de groupe non définie retombe sur la liste des messages privés tandis qu’une liste explicitement vide bloque tout expéditeur de groupe sous liste, et un bloc de canal complètement absent fait retomber l’exécution sur une politique de groupe en liste avec un avertissement même quand les valeurs par défaut des canaux disent autre chose.
• Sous la politique en liste, le routage de groupe exécute deux barrières successives : la liste des expéditeurs par handle, groupe d’accès, GUID, identifiant textuel ou identifiant de discussion, où une liste effective vide bloque tout expéditeur de groupe, et le registre des groupes, appliqué dès que la carte a des entrées, où la discussion doit correspondre à une entrée explicite d’identifiant ou à une entrée joker, une carte vide laissant la liste des expéditeurs décider seule.
• Chaque barrière a son propre avertissement nommant une solution différente : un avertissement unique au démarrage par compte quand la liste effective des expéditeurs est vide, corrigé en définissant la liste des expéditeurs de groupe ou celle des messages privés parce qu’ajouter des entrées de registre seules laisse la première barrière bloquer, et un avertissement unique par discussion à l’exécution quand un expéditeur a passé la première barrière mais que la discussion manque dans un registre rempli, corrigé en ajoutant cet identifiant de discussion ou le joker ; la configuration de groupe recommandée règle la politique en liste, une liste d’expéditeurs avec le numéro de l’opérateur et une entrée de registre joker exigeant une mention.

Les réponses reviennent sur iMessage en utilisant les métadonnées du canal et de la cible d’origine.

Mentions et invites par groupe

iMessage n’a pas de métadonnées de mention natives, donc la détection des mentions utilise les motifs de mention configurés de l’agent, puis les motifs globaux, et quand ni l’un ni l’autre n’est défini dérive des motifs du nom et de l’emoji d’identité de l’agent routé ; les groupes exigent une mention par défaut même sans motif explicite, si bien que le message d’un expéditeur autorisé peut être ignoré sauf s’il contient le nom ou l’emoji de l’agent, une liste de motifs explicitement vide au niveau de l’agent ou global supprime les motifs dérivés de l’identité et laisse iMessage incapable d’appliquer la barrière, et les commandes de contrôle des expéditeurs autorisés contournent la barrière. Pour traiter chaque message des expéditeurs autorisés dans un groupe, vous réglez la mention obligatoire de cette discussion sur faux dans la carte qui fournit déjà la politique de groupe du compte, la carte racine ou la carte du compte quand elle remplace la racine, en utilisant l’identifiant numérique de la liste des discussions d’imsg ; une carte de compte vide n’hérite de la racine qu’avec au plus un compte configuré, les cartes de compte remplacent toute la carte héritée si bien qu’une surcharge volontaire doit d’abord copier chaque politique joker et par groupe, une nouvelle entrée joker préserve l’admission des autres groupes avec leur mention obligatoire par défaut, une carte restreinte reste restreinte, et la liste des expéditeurs contrôle toujours l’accès. Un message sans mention ignoré journalise un avertissement avec l’identifiant de la discussion et la solution, les répétitions étant supprimées par un cache borné. Chaque entrée de registre accepte aussi une invite système injectée dans l’invite système de l’agent à chaque tour traitant un message de ce groupe, résolue comme pour les groupes WhatsApp : la propre invite du groupe quand l’entrée existe et définit la clé, une chaîne vide supprimant le joker, sinon l’invite du joker, et jamais pour les messages privés.

Sessions, liaisons, écritures de configuration

• Les messages privés utilisent le routage direct et les groupes le routage de groupe, les messages privés se fondent dans la session principale de l’agent sous la portée principale par défaut, les sessions de groupe sont isolées par identifiant de discussion, les réponses reviennent par les métadonnées du canal et de la cible d’origine, et un fil à plusieurs participants qui arrive signalé hors groupe est traité comme du trafic de groupe, avec barrière et isolation de groupe, quand son identifiant de discussion est explicitement configuré dans le registre des groupes.
• Les discussions iMessage peuvent être liées à des sessions ACP : la commande de lancement avec l’indicateur de liaison ici dans un message privé ou un groupe autorisé route les messages futurs de cette conversation vers la session lancée, les commandes de nouvelle session et de réinitialisation réinitialisent la session liée sur place, et la commande de fermeture la termine et retire la liaison ; les liaisons persistantes sont des entrées typées de premier niveau correspondant au canal iMessage avec un identifiant de pair qui est un handle de message privé normalisé, un identifiant de discussion, recommandé pour des liaisons de groupe stables, un GUID de discussion ou un identifiant textuel.
• Les écritures de configuration lancées par le canal via les commandes de réglage et de retrait de configuration sont autorisées par défaut quand la commande de configuration est activée, et la clé d’écritures de configuration réglée sur faux les désactive.

OpenClaw sur iMessage est le billet du canal auquel ces règles appartiennent, et Configurer iMessage dans OpenClaw le flux d’appairage qui admet le premier message privé.

Deux barrières, deux avertissements

La plupart des groupes iMessage silencieux tiennent à la première barrière : quelqu’un liste la discussion sous les groupes sans jamais définir de liste d’expéditeurs, si bien que chaque message de groupe est écarté avant que le registre soit consulté, et c’est pourquoi la documentation donne à chaque barrière son propre texte d’avertissement et sa propre solution. Les groupes d’accès dans OpenClaw couvre les entrées de groupes d’accès partagées que les deux listes acceptent, et Le contrôle d’accès Telegram d’OpenClaw le même modèle à deux contrôles sur Telegram.

Sur Diali

iMessage ne fait pas partie des canaux que Diali connecte aujourd’hui : WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS et voix. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière qui s’applique à chaque canal connecté.

• Des expéditeurs dans les listes, des identifiants de discussion dans le registre.
• Pas de métadonnées de mention : le nom et l’emoji de l’agent sont la mention.
• Copiez toute la carte avant de la surcharger par compte.