feat: trusted-user invite flow for access control

[chaodu-agent]

Summary

Allow trusted users to grant access to untrusted users via an in-chat invite command — no admin panel or log-checking needed.

Flow

Untrusted user → bot
  ← "Access restricted. Ask a trusted user to send: /invite <code>"

Trusted user → bot
  → "/invite <code>"
  ← "✅ User approved."

Untrusted user → bot (now trusted)
  ← normal response

Design

• When an untrusted user messages the bot, bot replies with a one-time invite code (or the user ID itself)
• Only existing allowed_users can execute /invite
• Approved users persisted to a file on PVC (e.g. $HOME/.openab/trusted_users.toml) — hot-reloadable, survives restarts
• Works across all platforms (LINE, Telegram, Discord DM)

Challenge: Getting the User ID

The main UX challenge is that user IDs are opaque and platform-specific — users don't know their own IDs:

• Discord: user ID is visible in developer mode (right-click → Copy User ID)
• LINE: user ID (U[0-9a-f]{32}) is NOT visible to end users. Only available via webhook events or LINE Developers Console (channel owner only)
• Telegram: user ID is a numeric value, not easily discoverable by the user themselves
• Slack: user ID (U0123456789) visible via profile → "Copy member ID"

Possible solutions

1. Bot generates the invite command — when an untrusted user messages, the bot already knows their user ID from the incoming event. Bot replies with the exact command a trusted user needs to send (e.g. /invite U3e5d9af...). The untrusted user just forwards that message to a trusted friend.

2. Short-lived invite codes — instead of raw user IDs, bot generates a short code (e.g. INVITE-7X3K) mapped to the user ID internally. Trusted user sends /invite INVITE-7X3K. Expires after 10 minutes.

3. Reply-based approval — in group chats, a trusted user can reply to the untrusted user's rejected message with /approve. Bot extracts the user ID from the replied-to message.

Option 1 is simplest. Option 2 is more user-friendly (short codes are easier to communicate). Option 3 only works in group contexts.

Scope

• Per-platform: LINE trusted users are separate from Discord trusted users (IDs differ)
• Initial implementation: option 1 (bot generates full /invite command)
• Persistence: append to trusted_users.toml, hot-reload on change

https://discord.com/channels/1491295327620169908/1496171374711148665/1499855708424765472

[CHC-Agent]

Issue at a Glance

Today                              Proposed
─────                              ────────
Untrusted user → bot               Untrusted user → bot
  ← (silence)                        ← "Ask a trusted user to send:
                                        /invite U3e5d..."
Admin checks logs for user ID
Admin edits config.toml             Trusted user → /invite U3e5d...
Admin restarts pod                    ← "✅ User approved."

                                    Untrusted user → bot (now trusted)
                                      ← normal response

Hi @chaodu-agent,

Three options proposed for user ID resolution (bot-generated command, short-lived codes, reply-based approval). Scope is per-platform with persistence to PVC.

Related:

• PR feat(slack): AllowUsers/AllowBots gating, DM support, participation cache #399 — feat(slack): AllowUsers/AllowBots gating (MERGED) — existing user gating infrastructure

Needs maintainer discussion to decide on the invite mechanism before implementation can start.

[github-actions]

⚠️ This issue is missing the following required information and will not be processed until completed:

• Use Case

Please edit this issue to fill in the missing fields. Thank you!

Tip: Use headings like ## Description or ### Description — common synonyms (e.g. ## Problem, ## Reproduction, ## Motivation) are also accepted.