openclaw - 💡(How to fix) Fix Feature: Dynamic identity resolution for allowlists (dmPolicy: dynamic) [1 participants]

Problem

The current dmPolicy: "allowlist" and groupPolicy: "allowlist" require hardcoded sender identifiers in openclaw.json. Every new user requires a config edit + gateway reload. This does not scale for multi-user deployments, especially on channels like BlueBubbles/iMessage where identifiers can be phone numbers OR Apple ID emails.

Current Flow (broken for scale)

1. New user messages bot
2. Gateway checks allowFrom array in static config
3. Sender not found → message silently dropped
4. Admin must: SSH in, edit openclaw.json, add identifier, reload gateway

Proposed Solution

dmPolicy: "dynamic" / groupPolicy: "dynamic"

Instead of checking a static array, the gateway resolves identity dynamically at request time.

Option A — HTTP resolver:

{
  "dmPolicy": "dynamic",
  "dmResolver": {
    "url": "http://localhost:3456/internal/user/resolve",
    "params": { "channel": "{{channel}}", "address": "{{sender}}" },
    "cacheTtlSeconds": 300
  }
}

Gateway calls the URL with sender info. If 200 + user found → allow. If 404 → deny (or route to unknown-sender handler).

Option B — Authorization hook: A new hook event message:authorize that fires BEFORE the allowlist check. Hook returns { "allow": true/false }. This lets custom logic decide (e.g., query a database).

Unknown Sender Handler

When a sender is denied, instead of silently dropping, optionally route to a designated agent/session for self-service identity linking:

{
  "dmPolicy": "dynamic",
  "unknownSenderAgent": "onboarding"
}

Dynamic Group Policy

Similarly, groupPolicy: "dynamic" would check if a session binding exists for the group instead of requiring a static groups dict entry. If a binding exists → group is allowed.

Why This Matters

• Multi-user deployments (SaaS-style) cannot edit config per user
• iMessage identifiers are unpredictable (phone vs Apple ID email) — can't pre-populate
• The identity data already exists in databases (e.g., Supabase user_identifiers) — duplicating it into static JSON is tech debt
• WhatsApp/Telegram handle routing dynamically; BlueBubbles/iMessage should too
• The allowlist check at step 3 happens BEFORE hooks fire at step 4, so existing hooks can't work around this

Workaround (current)

Manual script that edits openclaw.json + sends SIGUSR1. Works but is operational overhead that grows linearly with users.

Environment

• OpenClaw gateway on macOS (Mac Mini M4)
• BlueBubbles channel
• Identity data in Supabase user_identifiers table