An attachment store records potentially large binary objects, identified by their hash.

An identity service maintains an bidirectional map of Partys to their associated public keys and thus supports lookup of a party given its key. This is obviously very incomplete and does not reflect everything a real identity service would provide.

The KMS is responsible for storing and using private keys to sign things. An implementation of this may, for example, call out to a hardware security module that enforces various auditing and frequency-of-use requirements.

A network map contains lists of nodes on the network along with information about their identity keys, services they provide and host names or IP addresses where they can be connected to. The cache wraps around a map fetched from an authoritative service, and adds easy lookup of the data stored within it. Generally it would be initialised with a specified network map service, which it fetches data from and then subscribes to updates of.

Thread-safe storage of transactions.

Provides access to schedule activity at some point in time. This interface might well be expanded to increase the feature set in the future.

Identifier for service types a node can expose over the network to other peers. These types are placed into network map advertisements. Services that are purely local and are not providing functionality to other parts of the network dont need a declared service type.

A sketch of an interface to a simple key/value storage system. Intended for persistence of simple blobs like transactions, serialised protocol state machines and so on. Again, this isnt intended to imply lack of SQL or anything like that, this interface is only big enough to support the prototyping work.

Checks if the given timestamp falls within the allowed tolerance interval.

Thread-safe storage of transactions.

Storage service, with extensions to allow validated transactions to be added to. For use only within ServiceHub.

A service that records input states of the given transaction and provides conflict information if any of the inputs have already been used in another transaction.

A wallet (name may be temporary) wraps a set of states that are useful for us to keep track of, for instance, because we own them. This class represents an immutable, stable state of a wallet: it is guaranteed not to change out from underneath you, even though the canonical currently-best-known wallet may change as we learn about new transactions from our peers and generate new transactions that consume states ourselves.

A WalletService is responsible for securely and safely persisting the current state of a wallet to storage. The wallet service vends immutable snapshots of the current wallet for working with: if you build a transaction based on a wallet that isnt current, be aware that it may end up being invalid if the states that were used have been consumed by someone else first

Session ID to use for services listening for the first message in a session (before a specific session ID has been established).