FURPS: Chatbot Ecosystem

Functionality

• Support a range of bot types, including:
  • Broadcaster bots: emit messages to a defined audience or channel
  • Listener bots: respond to or process events from specific sources
  • Assistant bots: provide contextual or task-based help
  • Event responder bots: react to time-based or triggered events
  • Community tools: Example polls, moderation bots, onboarding flows (TBD)
• Enable rich conversational interaction:
  • Command parsing (example: /poll)
  • Inline responses with markdown and button components
  • Conversation threading:
    • Replies are grouped under the invoking message (threaded view)
    • Bot interactions maintain state scoped to the conversation context
    • Example:
      • When a user sends a command (e.g. /poll), all bot responses to that command are grouped under it, not scattered in the main flow.
      • If a user replies to a bot message, the reply is nested or linked clearly to the original message.
      • Bots can manage and track conversation state within a thread, instead of treating each message as independent.
• Support local, privacy-preserving execution using sandboxed runtimes (e.g. QuickJS)
• Integration with Waku for decentralised messaging transport
• Support for both interactive and passive bot modes.
  • Example: notify on events vs. respond to prompts
• Granular permissions model for bots
  • Bots must declare their requested capabilities in a structured manifest. All permissions are opt-in and controlled by the user. Categories include:
    • Message Access:
      • None: Can only see direct mentions (default)
      • Recent: Can access all messages in a single thread from the point they were installed
      • Full Chat: Can access the entire chat history and new incoming messages
    • Media Access:
      • Read image attachments, audio, and documents
      • No microphone or camera access
    • Identity Access:
      • View public identity information (chat key, ENS name, wallet address, (DID?))
      • Request user cryptographic signatures (user-prompted only)
      • Default: No identity access
    • Network Access:
      • Fully blocked by default
      • Can be enabled to:
        • Perform outbound HTTP requests
        • Use webhooks or polling
      • May be restricted to allowlisted endpoints
      • Network-active bots should be flagged in the UI!
    • Channel Access:
      • Thread-only (default) (specific 1:1, group, or community chat)
      • Multi-Chat (explicit user-granted chat list)
      • Global (rare, requires strong justification and visual warnings)
    • Interaction Scope:
      • Passive: (default) Can only respond when mentioned or invoked
      • Reactive: Can reply to any message within its allowed message scope
      • Proactive: Can initiate conversations or send messages without being triggered (e.g. scheduled alerts, background monitoring)
    • Execution Mode Declaration:
      • Visual badges should indicate elevated permissions
    • User Controls & Transparency:
      • Explicit consent prompts at install/use
      • In-app dashboard for reviewing and revoking bot permissions
      • Bots must appear in participant lists for any chat they observe
      • Auditability: all granted permissions clearly visible to the user
  • The model should include:
    • Permission Dashboard for users to audit and adjust what each bot can access at any time.
    • Default Deny Policy — bots should be granted no permissions by default unless explicitly approved.
    • Visual Indicators (e.g. shield icons or labels) to show when a bot is running with elevated or risky permissions.

Usability

• Simple, intuitive UX for invoking bots via @ mentions, commands (/help), or emoji triggers (🦄🪄)
• Configurable responses with markdown support and buttons
• Visual distinction between bot messages and human messages (e.g. icon or style)
  • Bot messages should include distinctive icons, badges (e.g. 🤖), or alternate message bubble styling.
  • Optionally, bots may use a clearly marked name prefix or display tag (example [BOT]) to signal automation.
• Clear onboarding and affordances for recognising bot profiles
  • When a bot is first added or encountered, users should see a clear explanation of what the bot does and what permissions it requests.
  • Bot profiles should indicate their role and include a description, optional usage examples, and runtime information (permissions).
  • Tooltips or UI overlays can reinforce that an account is a bot and not a human participant.
• Option to mute, block, or rate bot usefulness
• Unified invocation pattern across mobile and desktop
• Support for localisation (i18n) and accessibility (a11y) including screen-reader friendly commands, high-contrast modes, and keyboard navigation.

Reliability

• Bots should execute reliably without crashing the app or stalling conversations
• Fallback behaviour for unsupported or untrusted scripts
• Resilience to malformed bot responses (e.g. excessive output or infinite loops)
• Message retries if connectivity fails (especially in asynchronous contexts)
• Logs for debugging (only client-side for local bots)

Performance

• Minimal resource overhead for local bot execution
• Fast message response (within 500ms ideal target for local bots)
• Efficient caching and load-time for embedded runtimes (e.g. lazy loading QuickJS context)
• Optional execution limits (e.g. JS runtime memory/time constraints)
• Optimised serialisation for Waku transport if used

Supportability / Security

• Bots MUST be sandboxed, with no access to local files, device sensors, or identity unless explicitly granted
• Developers should be able to easily write, package, and share bots with a clear manifest format
• Support version pinning and interface stability for long-term bot compatibility
• Encourage open-source or auditable bot packages
• Bots should be reviewed and rated by the community where applicable
• Transparent permission declarations must be enforced
• Support deterministic execution (for repeatable test/debug flows)