Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Consumers & Delivery

Xenocept’s principle here is: the user decides what happens with their sessions.

When you press Submit, Xenocept does two things:

  1. Persists the session locally in its AeorDB-backed store.
  2. Optionally dispatches the session to one or more configured destinations.

Local storage is the source of truth. Delivery is a side effect: if every destination fails, the session is still safe locally and can be re-dispatched later.

How Delivery Actually Works

Delivery happens through plugins. Every destination wraps a plugin (identified by a reverse-DNS pluginID) plus a pluginConfig blob the plugin understands. There are a handful of built-in plugins that ship with Xenocept, plus a system for installing or writing your own.

The flow:

  1. User configures one or more destinations through the Settings UI (or directly via the Destinations API).
  2. Optionally, the user enables auto-send on some subset of destinations.
  3. After Submit, the frontend’s plugin loader runs each destination’s plugin, passing the session.
  4. The plugin uses Xenocept’s low-level delivery primitives — POST /api/v1/deliver/http, POST /api/v1/deliver/file, POST /api/v1/deliver/command — to do the actual work (call an external service, write a file, run a command).

Built-In Plugins

Plugin IDWhat it does
org.aeor.xenocept.fileWrites the session’s screenshot (and optional metadata) to a configured filesystem path.
org.aeor.xenocept.emailEmails the session out via a configured SMTP setup.
org.aeor.xenocept.aeordbPushes the session into an external AeorDB instance.
org.aeor.xenocept.claude (separate repo)Delivers to Claude Code via the MCP channel server. See MCP.

Additional community plugins can be installed via the Plugins API (/api/v1/plugins/install, ).

Sub-Pages