Crate vcon_server 

The vcon-server program. The binary in main.rs is a thin front end; everything it runs lives here so tests can drive it.

This library is not an API for other crates. It exists for the vcon-server binary, its tests and its fuzz targets, and any release may change it without notice: semver covers the program’s command line, HTTP API and data directory, not these modules. To read or check vCons from Rust, use the vcon crate.

Modules

access

Turns the bearer token on a request into a caller, or refuses it.

api

The HTTP API, served over TLS only.

audit

The audit log: one record per request, written in the same transaction as the change it describes. A record holds no vCon content, no token and no client address.

catalog

An SQLite catalog, encrypted with SQLCipher under its catalog key.

clock

Time, behind an interface so tests can set it.

commands

The commands other than serve: tenants, keys and the audit logs. Each takes the data directory as its work shares it, opens the registry with recovery when it runs alone and without when it may run beside a server, and prints what the matching admin route answers: one JSON object a line.

config

The server’s configuration: one TOML file. A configuration error stops the start and names its key, and an unknown key is an error.

console

The console: a web page served on the TLS listener at /console/. It is a client of the HTTP API and nothing more. Its three files are built into the binary and need no key: they are the same for every caller, hold no data and change nothing. Every request the page makes is an API request that carries the key the user signed in with.

datadir

Who may use the data directory at once. serve runs alone among servers; a command that rewrites the registry or the tenants’ catalogs runs alone; the other commands run beside a server and beside each other, but never beside a command that runs alone.

envelope

Keys and the encryption that protects every stored body.

fs

The filesystem calls Store makes for object files, behind an interface so tests can simulate a crash. The catalog is SQLite, which does its own I/O and is durable once a commit returns.

ids

Identifiers, written in lowercase hex: a tenant or a version is 128 random bits, a key 64 bits.

mcp

The MCP server: the HTTP API’s operations as MCP tools for AI agents.

query

Query strings: the one rule every route that takes parameters reads them by, so the HTTP routes and the tools built on the same functions refuse the same queries.

retention

A retention period: a calendar period of whole years, months or days, added to a time in UTC.

serve

vcon-server serve: the server, run from its configuration.

store

One tenant’s vCons: a sealed object per kept version and a catalog row for it. The catalog is the truth: a version exists once its row is committed, and an object with no row is garbage. Every rule is here; the catalog and the objects are reached through the backend traits.

tenants

The registry of tenants: each one’s id, name, retention period and wrapped tenant key, kept in server.sqlite under a catalog key derived from the master key, with the admin audit log beside them. Each tenant’s vCons live in tenants/<id>/, in a Store of their own.