The id of the database to update.

The SQL statements to execute. The statements will be executed within a transaction and will be committed if all statements succeed.

Bear in mind the maximum size limit of a single message is 64MB, and around 1MB seems to be optimal in terms of performance.

Details of any error that occurred on the call.

Set to commit the transaction. If not set, the transaction will be rolled back.

Initialise the request with the database id and whether to execute within a transaction.

Also includes the SQL statement to execute.

To retrieve subsequent pages, send a `next` request.

To end the call, send an `end` request. Only really necessary for transaction-based calls, otherwise clients can just close the stream.

A status will be sent on error.

The initial response for SELECT statements will be a header containing the column names and types.

Each row in the result set will be sent as a VariantRow.

NYI - For INSERT/UPDATE statements the number of affected rows will be sent.

The id of the database to execute on.

Set to start a transaction. If not set, each statement will be executed in its own transaction.

The SQL statement to execute.

This can be used to limit the number of rows returned by `SELECT` statements to avoid overloading a client. It is similar to using 'LIMIT/OFFSET' clauses on the 'SELECT' statement, but this method is easier to manage and the entire result set will be prepared on the Volt, and the client can then page through it by sending successive messages.

Set to indicate that the query will be cancelled if the client disconnects.

This is useful for long running queries, where it might be desirable for the client to be able to cancel the request before all the data is received. However this requires a worker thread to be allocated to the query until it completes, which may affect performance and limit the number of concurrent queries that can be executed due to file handle limitations.

Only applicable to `SELECT` statements, ignored otherwise.

The values to set for each parameter defined in a database view.

This field is only relevant to 'query' databases, i.e. those with kind `tdx:sqlite-view`.

The values in the map should be keyed by parameter name.

A query may have no parameters defined, in which case leave this field empty.

The target database resource id, which must already exist, and the authenticated account must have write access to the resource.

The target table name.

Not yet implemented - flag indicating that data is to be inserted into an existing table.

Optional - when not sending the data via this RPC, this should contain the id of a resource that contains the CSV data. If set, the authenticated account must have read access to the resource.

Optional - the interval to receive progress updates, in number of rows. E.g. set to 1000 to receive progress updates every 1000 rows. Set to 0 to disable progress updates.

The number of rows scanned to infer the schema. Set to 0 to scan the entire file.

The initial request must contain the configuration parameters for the import.

Set to indicate that the upload is complete.

Subsequent requests may contain the data to be imported, unless importing from an existing resource that contains the CSV data. It is recommended that the block size is less than 1MB.

Set to abort the import.

The status will contain any error info.

The number of rows processed - this will be sent after every `progress_interval` rows.

The total number of rows to be imported.

A simple error code that can be easily handled by the client.

Mirrors the grpc StatusCode enum, 0 => OK

A developer-facing human-readable error message in English. It should both explain the error and offer an actionable resolution to it.

Long form error description.

The resource being accessed.

A human-readable short identifier of the resource.

The identity that owns the resource.

The kind of resource.

The identity attempting access.

The JSON path array for looking up verifiable credentials.

A human-readable short identifier of the subject.

The kind of identity.

Requested access.

Optional extra data.

Assigned decision.

Time at which the request was made.

Time at which the decision was taken.

Counter of number times this access was requested.

The alias id.

The corresponding identity id.

The actual alias, e.g. a common name or key fingerprint.

This will only be populated if alias_type == tdx:public-key

This will only be populated if alias_type == tdx:public-key, and the key is stored in the Volt.

The alias type, for example public key, email, phone number etc.

The identity that issued this alias.

Indicates if this alias has an authenticate policy decision assigned.

Optional description of this alias.

The path name of the proto file, relative to the 'root' of the namespace, e.g. "tdx/volt_api/volt/v1/volt.proto".

The actual protobuf file contents.

Optional - the service(s) contained in this protobuf file, if omitted here they will be loaded dynamically from the protobuf.

Unique connection id.

A human-readable name for the connection.

The remote address of the proxy service.

The certificate authority of the proxy service.

Indicates this connection is enabled.

Indicates this connection is currently in use.

Indicates that this connection will handle HTTP proxying as well as GRPC.

Set to indicate the Volt API itself is not automatically exposed to the connection.

Optional challenge that can be presented in the authentication request.

The id of the target Volt that this connection is bound to.

Indicates that this connection hosts a DID registry that we should synchronise with.

The id of the last DID registry operation that was synchronised.

Indicates that this connection hosts a DID registry that we should synchronise with.

The timestamp of the last VC registry operation that was synchronised.

The globally unique resource id.

Optional description.

Human-readable resource name.

Not in use.

The id of the Volt that hosts this resource.

Optional description of any services exposed by this resource.

Attributes assigned to the resource.

The version of the platform.

The resource version.

The identity of the resource owner.

Creation timestamp, milliseconds since epoch.

Last modification timestamp, milliseconds since epoch.

Not in use.

The taxonomy of the resource.

The online status.

For most kinds of resource this indicates that the server hosting the resource is online, the exception being identity resources, in which case the status reflects whether or not the identity has a live connection.

All built-in resources are hosted by the Volt itself and are therefore always online when the Volt is running.

Resources hosted by external servers are online if the server itself is online and has registered the resource as online using `setServiceStatus`.

The size of the resource store in bytes.

The path to the resource store.

Alias(es) that can be used to refer to the resource rather than the id.

Each alias must be unique to the Volt, this is enforced by the API.

No format restrictions are currently applied to alias, but this may change in future, for the time being it makes sense to stick to alphanumeric characters and '_' or '-'.

The hash of the resource content contained in the store.

Not yet supported.

The configuration used by the host of this service.

The identity of the client that is exposing the service.

For example, if a third party is exposing a database service via a Volt, it will first authenticate and obtain a client DID and credentials in order to be able to create service resource(s).

Any resources that are owned by this client will be marked as online if the client itself is online, i.e. has a live connection to the Volt.

This will be empty if the service is a built-in Volt service.

The id of the resource that holds the protobuf definition for this resource.

For example, if a third party is exposing a database service via a Volt, it will create a service resource that holds details of the protobuf methods exposed by the service.

For built-in services, i.e. those hosted by the Volt, this will set to the Volt id.

The address of the grpc server hosting this service.

Only relevant to grpc-hosted services.

The certificate authority (chain) that signed the service server certificate.

This is only relevant to grpc-hosted services.

The public key of the service host, which is used to encrypt payloads.

This may change as the service comes and goes online.

The connection id currently used to host this service.

Internal use only.

The discovery mode.

The ping timestamp of the server hosting this service.

The protobuf definitions of the APIs exposed by this service.

The fully qualified names of the protobuf services, for example tdx.volt_api.webcam.v1.WebcamControlAPI.

Internal use only.

The alias id.

The corresponding session id.

The credential type, for example public key, verifiable credential, challenge etc.

Optional description of this credential.

The id of the verifiable credential, if the credential type is volt:vc-claim.

The verifiable credential in JSON format, if the credential type is volt:vc-claim.

The subject id extracted from the `vc_json` field.

The issuer id extracted from the `vc_json` field.

The comma-separated type(s) extracted from the `vc_json` field.

The challenge string, if the credential type is volt:challenge.

The key fingerprint, if the credential type is volt:public-key.

The PEM-encoded public key, if the credential type is volt:public-key.

Optional PEM-encoded private key, if the credential type is volt:public-key. Only used for ephemeral REST-base sessions created dynamically after OTP authentication.

Type-specific extra data stored with the credential.

More type-specific data stored with the credential.

The globally unique Volt id.

Human-readable name of the Volt.

The actual host/ip the volt is physically running on (might be a local ip if behind firewall).

The address of the endpoint HTTP server.

The global (Relay) address of the volt. Any given volt may be advertising on more than one Relay instance. The value given here will depend on the Relay instance that handled the endpoint query response.

The root certificate of the Relay instance referred to in `relay_address`.

The self-signed certificate used by the volt to sign client certificates.

The Volt public key in PEM format.

The base58 fingerprint of the Volt public key.

The online status of the Volt.

Indicates that this Volt acts as a Relay.

The API version supported by the endpoint.

Optional description of the endpoint.

The list of DID registries that this Volt trusts.

The name of the Volt.

Human-readable description of the Volt.

The database driver in use.

The local file path location of the Volt storage.

The key strategy in use, this determines how the root key is stored.

The identifier for the key, the semantics depend on the key strategy in use.

The Volt certificate authority.

The Volt API server certificate.

Optional hostname of the Volt if using DNS or a static IP address, e.g. tdxvolt.com

Port to use for hosting the Volt management service.

Port to use for hosting the Volt grpc service.

The Volt http server key file path.

The Volt http server certificate file path.

The Volt http server certificate authority chain file path.

Indicates the Volt will be discoverable by clients using the discovery api.

Optional challenge code that can be used aid in the process of authenticating clients.

Indicates that clients must present the correct challenge code in order to be able to authenticate.

Internal use only.

Internal use only.

Internal use only.

Set to indicate this Volt acts as a Relay.

This means this Volt can act as a proxy for other Volts (or in fact any client) that connect to it.

Set to run the Relay open to any client, i.e. clients can utilise the Relay without first authenticating.

Determines if the Volt HTTP server is enabled.

Determines whether the HTTP server employs TLS.

Determines whether the HTTP server supports forwarding.

Determines if the Volt REST API is exposed via the HTTP server.

Determines if the Volt Websocket API is exposed via the HTTP server.

The hostname:port at which the Volt API is currently running.

Set to indicate the Volt file store is encrypted.

This is a unique connection id.

Indicates that these parameters refer to a connection to a remote Volt rather than a local Volt.

The certificate authority of the Relay if this is a remote connection via a Relay.

Optional override of the http address, rather than using the default of fixed_host:http_port.

This is useful if the Volt is behind a firewall or NAT, and the http server is listening on a different port

from 80 or 443 but this is hidden by the proxy. For example, if the `fixed_host` is `coreid.com` and http server is

listening on 2115, but the proxy is forwarding 443 to 2115, then the http_address_override would be set to

`https://coreid.com`.

An optional alias that can be used to refer to the Volt rather than the `id` field.

This alias must be unique within the scope of the Battery in which the Volt is stored.

The runtime version this Volt is running.

If set, indicates that any client that provides the correct challenge during authentication will automatically be approved to access the Volt.

If set, indicates that any client that proves ownership of a DID known to the Volt will automatically be approved to access the Volt.

If set, indicates that clients can register DIDs with this Volt.

Zero or more URLs of trusted peer DID registries.

If set, enables outbound SMTP.

The SMTP host to use for sending emails.

The SMTP port to use for sending emails.

The SMTP username to use for sending emails.

The SMTP password to use for sending emails.

If set, enables sessions that authenticate using credentials rather than a DID to create resources in the 'anonymous' system folder.

The decision to apply to all authentication requests that do not match any other policy.

The default is PROMPT.

If set, enables caching of policy decisions.

If set, enables the terminal API.

The time at which the Volt was started.