Modules

MSFLib is a core package, msflib, plus optional feature modules. The core is required by everything else. Each module is a separately installable msflib-* package (for example msflib-auth) that plugs into a host FastAPI app. The home page has the full package map with dependencies and a guide to choosing what to install.

Pages by area

Foundation

• core (msflib): settings, base models, actions, event bus, scope, policy, database setup, seeding, utilities. Every other package builds on it.

Identity and tenancy

• auth: login, tokens, password reset, OAuth, identity dependency factories.
• account: accounts and profiles.
• tenancy: the Tenant model and tenant resolution.
• workspaces: workspaces and membership.

Configuration and notifications

• workspace_config: tenant, workspace and user scoped configuration.
• notifications: account notifications and broadcasts.
• workspace_notifications: workspace-level notifications.

Commerce

• payments: Stripe and Paystack payments.

AI, documents and knowledge

• ai-core: LLM, embedding and vector-store infrastructure.
• ai-api: retrieval and Q&A endpoints.
• conversation: channels, threads and messages.
• drivelink: virtual filesystem.
• ingestion: shared ingestion job queue.
• documents: document ingestion.
• knowledge: scoped knowledge model and semantic queries.

How a module is wired

Modules follow the same shape, so once you have wired one the next is familiar:

1. Install the package (and its extras, if any).
2. Settings: add the module's settings class to your app settings. Each has a namespace, so its values are read as settings.scope("AUTH"). They are set through environment variables: AUTH__ENABLE_GOOGLE_OAUTH when the settings are composed as nested fields, plain ENABLE_GOOGLE_OAUTH when your settings class inherits the module's settings class (subclassed). See Tiered configuration.
3. Models: import the module's models before you create tables, so they are registered on SQLModel.metadata. Modules whose tables reference others (ai-core references tenancy) need those models imported too. See Models, data and tables.
4. Dependencies: call the module's dependency factory with your session and settings, and keep the result in one deps.py. See Dependency injection.
5. Routers: call the module's router factory with those dependencies and include the result in your app. See Mounting routes.
6. Events: if the module exposes register_event_hooks, call it with your app emitter (app_emitter = bind_app_emitter(app)). Listeners fire only for code that runs in a request, or inside with use_app_emitter(app):; scripts and threads in your web app's process need that wrapper. A worker process has no app object: register its listeners on the worker's emitter, AppEmitter(get_emitter()), as the ingestion and knowledge pages show. See Event bus.

Not every module has every step. The module pages say which apply.

Behaviour may change (#280)

The NAMESPACE__KEY environment variable style (step 2) only works when the namespaces are composed as fields, as compose_settings_model does (composed). Subclassed hosts must use flat field names.

Page layout

Every module page follows the module page template: purpose, install, wiring, configuration, key concepts, examples, troubleshooting, API reference, see also.