Reboot Framework

The library implements application-layer envelope encryption using three layers of keys to provide encryption at rest, crypto-shredding, and cheap rotation:

1. Root KEK: Derived from the REBOOT_CRYPTO_ROOT_KEYS environment variable; never stored.
2. WrappingKey: A random 256-bit key stored encrypted under the root KEK. This is the revocable unit tied to a specific scope.
3. DEK (Data Encryption Key): A random per-value key used to encrypt the actual plaintext. The DEK is wrapped (encrypted) by the WrappingKey.

This architecture ensures that a leaked database backup is inert without the root keys, and that data can be permanently deleted (crypto-shredded) by destroying a single wrapping key without needing to rewrite the encrypted data.

An OAuth provider in Reboot defines how the system identifies users. You pass a provider instance to OAuth(provider=...). Because each provider issues unique IDs, switching providers after you have production users will strand user-keyed state. For flexibility with multiple sign-in methods or user management, it is recommended to use a broker like Auth0 or Ory.

Available providers in reboot.aio.auth.oauth_providers:

• Development(): For local development; shows a fake account picker.
• Anonymous(): No sign-in; every visitor is a new user.
• Google(...): Sign-in via Google.
• GitHub(...): Sign-in via GitHub.
• Auth0(...): Broker for multiple sign-in methods and user management.
• Ory(...): Broker for multiple sign-in methods via Ory Network or self-hosted Ory.

Reboot integrations provide APIs to interact with third-party services. These interactions are isolated as side-effects, ensuring they compose safely and handle partial failures or retries without compromising system integrity. Currently supported integrations include:

• Mailgun: Supports sending email messages using the Mailgun API.

Reboot applications use Gherkin .feature files located in the tests/ directory to define application behavior. These files serve three purposes:

1. Specification: A shared agreement between developers and coding agents.
2. Tests: Executable scenarios run by pytest using built-in steps.
3. Documentation: Visualized in the developer dashboard's Features page, showing rules, scenarios, and exercised methods.

Reboot provides a standard library of data structures and APIs for common tasks. Available libraries include:

• Ciphertext: Envelope encryption with a revocable wrapping key for encrypting values at rest and crypto-shredding via key destruction.
• OAuth Token Manager: An encrypted, per-service store for user OAuth tokens to facilitate external service calls.
• PubSub: Implementation for subscribing to and broadcasting to topics.
• Queue: A durable queue for enqueuing and dequeuing items.
• OrderedMap: A recommended implementation of a collection/dictionary/map that can exceed memory size.
• SortedMap: An older implementation of a collection/dictionary/map that can exceed memory size and maps efficiently to Reboot's underlying storage.

A Reboot backend provides a unified interface where the same types, methods, and durable state are accessible regardless of the client type. Supported frontends include:

• Web: A React application running in the browser.
• React Native: A mobile app for iOS and Android (currently in alpha) using the same generated hooks as the web app.
• MCP UI: Methods exposed as MCP tools with React components rendered within AI interfaces like ChatGPT, Claude, or VS Code.
• AI Agents: External agents connecting via MCP, or internal Pydantic AI agents running within workflows.
• Services: Direct calls from other scripts, backend code, or via HTTP (including custom HTTP routes for webhooks).

The Item is a generic data type used to pass and retrieve data from Reboot standard libraries (such as enqueuing and dequeuing from Queues). It serves as a convenience type for marshalling and unmarshalling data rather than a standalone library. It supports three data formats:

• Value: Represents dynamically typed data (JSON-like), including nulls, numbers, strings, booleans, recursive structs, or lists.
• bytes: Stores a raw string of bytes.
• Any: Wraps a protobuf message.

Reboot provides built-in default authorization rules to secure state types before a custom authorizer is written:

• User methods: Callable only by the specific user they belong to, or by internal application code.
• All other state types: Callable only by internal application code. Any external call is denied by default.

In development mode (rbt dev run), calls to types without an authorizer() are allowed (with a warning) to facilitate rapid building, but these are strictly denied in production (rbt serve or Reboot Cloud).