Plugin and App connect: catalog, guided auth, and a fast developer scaffold (cf. Grok Bot connectors) #359
Description
Why
FlyBot's value for daily life and work grows with the Apps and Plugins people can attach. Today installing and wiring a connector is still too heavy compared with Grok Bot's connector / plugin flow (search → install → authenticate → tools appear). We need convenient mechanisms so a third party can plug in quickly, and so a user can connect Slack, Calendar, Drive, etc. in minutes.
What to learn from Grok Bot (reference, not copy)
- A catalog of installable connectors with search.
- One-click install, then a clear auth path (OAuth / token) with status: needsAuth / connected / error.
- Tools appear automatically after auth; skills can document when to use them.
- Secrets stay in a vault; the bot never pastes tokens into chat.
- Per-connector instructions and rate limits are attached to the tools.
Proposed FlyBot mechanisms (discussion draft)
For users
- Plugin / App catalog in the UI: search, one-click enable, status badge (off / needs sign-in / ready).
- Guided connect: OAuth or token form in-app; never paste secrets into the chat transcript.
- First-run recipes: "Connect calendar for morning brief", "Connect Slack for team reminders" (Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353–Proactive reminders 3/3: 24/7 runtime and Slack/email delivery #355), each 2–3 steps.
- Per-Bot grants: a connected App is not automatically usable by every Bot; default deny, same spirit as [Team] Gate cross-owner agent routes by per-Bot grants (default deny; superseded the publication gate) #51.
For developers
- Stable plugin contract: package layout, lifecycle hooks, tool schema, permission declarations (what the plugin may read / write / send).
- Scaffold:
create-flybot-plugin(or equivalent) that produces a working stub + tests + a README demo slot (docs(timeline): add a screen-recording demo at the top of the Timeline plugin docs #350 style). - Sandbox and caps: network allow-list, rate and cost limits ([Team] Bound agent loops and resource consumption #56), no silent elevating of privileges.
- Interop adapter reuse: the live-e2e adapter contract (
docs/interop/live-e2e-adapter.md) as a pattern for "any app that speaks the contract". - Publish path: how a community plugin is listed, versioned, and signed; how it rides the daily tag (Release cadence: at least one tag per day, small and stable #351).
Personal vs team
- Personal: user connects Apps for their own Bots.
- Team: manager can require or forbid Apps; audit who connected what ([Team] Add a human-readable authorization and task audit trail #57); cross-owner use only with grants ([Team] Gate cross-owner agent routes by per-Bot grants (default deny; superseded the publication gate) #51).
Acceptance for a first cut
- A new user connects one App (e.g. calendar or Slack) end-to-end in under 5 minutes following in-app steps.
- A developer publishes a hello-world plugin from the scaffold and sees it in the catalog on a local instance.
- Revoking auth immediately removes tools; no leftover tokens in logs.
- Docs: user guide + developer guide, zh/en.
Open questions
- Do we extend
@flybot/*plugins only, or also support external "Apps" as first-class connectors? - Where does the catalog live: in-repo, a registry, or both?
- OAuth: who is the client app (FlyBot Desktop vs each deployed instance Deployment step 1: official image and one isolated instance per person #352)?
- How much of Grok Bot's MCP-style connector model do we adopt vs keep FlyBot-native?
Related
#352 deployment, #353–#355 proactive reminders (need outbound channels), #51 grants, #57 audit, #351 daily tags.
Process
RFC in this issue first; implementation via OpenCode + Codex review.
Activity
Birfy commentedon Oct 19, 2026
Owner decision (2026-10-19): Connector tools are ON by default for the owner's own Bots, so no setting is needed for that. Only the switch for use by OTHER people (friends / room members) through a Bot is needed: default off, with an explicit owner opt-in. This is consistent with the 2026-10-18 connector decision. The RFC should be edited to drop any per-Bot owner-side enable setting.
Document the agent operating model in AGENTS.md (ThinkFlowLab#414)
Birfy commentedon Oct 19, 2026
Triage on main
7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-info, not agent-ready. The owner decision above settles the default (on for the owner's Bots; one off-by-default switch for other people). Still blocking: the RFC text should drop the per-Bot owner-side enable setting, and a first concrete slice (e.g. catalog search + guided auth for one connector) needs its own issue with expected behaviour.Birfy commentedon Oct 20, 2026
Triage (maintenance, 2026-10-20 08:59 Asia/Shanghai)
On main
bae4128: the user side is mostly there. Settings has a Connectors page with GitHub (token) and Composio. One Composio key opens Gmail, Slack, Calendar, Notion and others, with a common-apps list plus a "More apps" field where you type names (core/src/client/connectors.js,core/src/host/connectors.js). Composio asks for each app's sign-in the first time a Bot needs it. Keys are kept and redacted bysecrets.js, never put in chat or the DSH profile. Access matches the owner decision above: on for your own turns, and off for other people unless you turn on sharing for that Bot (core/src/host/connector-access.js). There is no searchable catalog, no per-app status and no plugin scaffold.Expected behavior: connect an app in a few clicks, see whether each app is ready or needs sign-in, and have tools appear without pasting secrets into chat.
Smallest first slice: on the Connectors page, replace the typed "More apps" list with a search over Composio's app list, and show a status for each picked app (needs sign-in / ready). Nothing else changes.
Details I decided (say if you disagree)
Question for the owner
(a) Ship only the Composio search + status slice, and park the developer side.
(b) The slice plus a
create-flybot-pluginscaffold and an in-repo plugin catalog.(c) Instead, add a generic "Add MCP server (URL + token)" connector.
Recommendation: (a).
Birfy commentedon Oct 20, 2026
Owner decision (2026-10-20): Confirmed option (a): replace the Connectors page's typed App name with a search over Composio's App list, showing each App's status (needs sign-in / ready). The developer scaffold (create-flybot-plugin) is deferred.
Birfy commentedon Oct 20, 2026
Claimed by maintenance run (2026-10-20 09:54 Asia/Shanghai). Working on branch
feat/359-composio-app-search(fork Birfy/FlyBot), developed in parallel with sibling issues; first slice per the Owner decision only.Birfy commentedon Oct 20, 2026
Minor details decided while developing (PR #479, 2026-10-20 11:00 Asia/Shanghai):
x-api-keyheader, and the search never saves it. After connecting, it uses the saved key.GET /toolkits?search=…&sort_by=usage&limit=20; the query is capped at 64 characters and debounced 250 ms in the UI. Without a key, or when the search fails, the built-in list of common apps is filtered instead (with a "Could not search Composio" hint).GET /tool_router/session/{id}/toolkits: Ready when the app needs no auth or has anACTIVEconnected account, otherwise Needs sign-in. It is asked when the row is ready, when the app list changes and when Choose apps opens or closes. Nothing is shown until Composio answers.SHARED_BLOCKEDlike the other connector endpoints.Birfy commentedon Oct 20, 2026
Cleanup: issue closed. Removing stale agent-working and assignee.
Keep the owner's keys to the owner's own use of a Bot
Save the owner's keys for all of the owner's Bots by default (ThinkFl…
Timeline: which tools each Bot used, and how often they failed (Think…
Timeline: which tools each Bot used, and how often they failed (Think…
Timeline: stuck requests, tool use and team health (combined) (ThinkF…