dguiducci
da8a835d70
Granting was a checklist of every user on each plugin's page, so "what may
this person use?" meant opening every plugin in turn — and the answer lived
on N pages while the connector half of it already lived on one. Both grant
sections now sit together on #users/{id}: same row list, same disabled chip,
same replace-the-whole-set save. The plugin's own page keeps a read-only
roster of who holds it, linking back to each person.
- db: plugin_access::set_for_user, the per-user twin of set_for_user on
mcp_catalog_access; set_access stays as the inverse read model
- PluginManager: list_grants_for_user / set_grants_for_user, which omit and
reject manages_own_access plugins (a box that controls nothing is worse
than no box)
- GET/PUT /api/users/{id}/plugins, mounted next to /users/{id}/connectors;
PUT /api/plugins/{id}/access is gone, GET remains as the roster
No push after the write, unlike a connector grant: that one gates a runtime
snapshotted at login, while a plugin grant is re-read from plugin_access on
every request that depends on it (sidebar pages, /plugins/mine, and each
inbound channel message), so a revoke lands with no bus event.
Docs updated with where access is granted, and why mobile-connector is
absent from that list.
2.6 KiB
Honcho Memory
- Plugin id:
honcho - Category: Long-term memory (external service)
- Runs: talks to a Honcho server (self-hosted or hosted) over HTTP — needs network access to it
What it does
Streams a user's completed chat turns to an external Honcho server so it can build long-term memory about them across sessions — facts, preferences, a curated "peer card" — and feeds retrieved context back into future turns automatically. Also adds tools the assistant can call directly: memory_query, honcho_profile, honcho_search, honcho_context, honcho_conclude.
This is different from the app's built-in private memory (user-memory/…, stored encrypted in the user's own database). Honcho is an external system and stores conversation content in cleartext, so it is strictly opt-in per user and off by default — enabling the plugin does nothing on its own until each individual user turns it on for themselves.
Requirements
- A running Honcho server reachable from this machine (local install or hosted), and its base URL.
- Optionally an API key, if that Honcho instance requires one.
Enabling & configuring (admin)
- Plugins page → Honcho Memory → enable, then Configure (or its own admin page, once enabled: sidebar → Honcho).
- Fields:
base_url(defaulthttp://localhost:8000) — the Honcho server's URL.api_key— optional, only if the server requires auth.workspace_id(defaultskald-circle) — a name identifying this instance inside Honcho. Each user becomes a separate "peer" inside the same workspace. Use a fresh, unique name for a new instance.
- The admin config page includes a connectivity test.
Per-user setup
Long-term memory is off for every user until they turn it on themselves. Once the plugin is enabled and the user has been granted access (admin: Users → that person → Plugins → tick Honcho), they'll see a "Long-term memory" page in their sidebar with a single opt-in toggle. If a user asks the assistant to "remember things long-term" or asks why it doesn't remember past conversations, and this plugin is enabled, point them to that page rather than trying to enable it on their behalf.
Notes
- Explain the privacy trade-off honestly if a user asks: their messages get stored in cleartext on the Honcho server, outside the encrypted database this app otherwise uses. Some users may not want that.
- Both the "remembering" (write) and "recalling" (read/search tools) sides of this plugin are gated on the same opt-in flag — a user who hasn't opted in gets a clear "not opted in" response instead of a silent no-op.