List of Classes

Open Transactions is, at its core, a class library. I hope to have documentation for all these classes sometime soon.

In the meantime, be sure to read the detailed notes on the API and the Use Cases for the API.

USER / PSEUDONYM
OTPseudonym — Primarily a key pair. (Public/private keys.) Used as an identity; also manages lists of request numbers and transaction numbers for that identity on various OT servers. Often used for signing and verifying signatures on contracts. A pseudonym may have many asset accounts. A pseudonym may be registered on multiple servers.
OTIdentifier — A 256-bit hash, usually of a public key or a contract, displayed as Base62. (The Nym’s ID is a hash of his public key. An Asset Type’s ID is the hash of its asset contract. The Server ID is a hash of the server contract. Etc.)

CONTRACTS / INSTRUMENTS
OTContract — Most other classes are derived from this one. Contains the actual XML contents, as well as various data values that were loaded from those contents, including public keys. Also contains a list of signatures.
OTScriptable — Derived from OTContract, but enables scriptable clauses. Also contains a list of parties (each with agents and asset accounts) as well as a list of bylaws (each with scripted clauses, internal state, hooks, callbacks, etc.)
OTServerContract — Derived from OTContract. Specific to an OT server.
OTAssetContract — Derived from OTContract. Specific to an ASSET TYPE. (May be registered on multiple servers.)
OTBasket — Used in basket currencies. Derived from OTContract.
OTInstrument — Has a date range, a server ID, and an asset ID. Derived from OTScriptable.
OTTrackable — Has a transaction number, user ID, and an asset account ID. Derived from OTInstrument.
OTCheque — A financial instrument. Derived from OTTrackable.
OTCronItem — Derived from OTTrackable. OT has a central “Cron” object which runs recurring tasks, known as CronItems.
OTAgreement — Derived from OTCronItem. It has a recipient and recipient asset account.
OTPaymentPlan — Derived from OTAgreement. Allows merchants and customers to set up recurring payments. (Cancel anytime, with a receipt going to both inboxes.)
OTOffer — Derived from OTInstrument. An OTMarket has a list of these.
OTTrade — Derived from OTCronItem. These correspond to offers on the market. Anytime an offer processes on the market against another offer (a “trade”) then the quantities are updated here and saved as the latest cron receipt (with a copy going to your inbox, along with a copy of your original signed market offer.)
OTSmartContract — Derived from OTCronItem. All CronItems are actually derived from OTScriptable already (through OTTrackable/OTInstrument). But OTSmartContract is the first/only Cron Item specifically designed to take full advantage of both the cron system AND the scriptable system in conjunction with each other. Currently OTSmartContract is the only actual server-side scripting on OT.

DIGITAL CASH
OTMint — There is a different mint for each asset type, plus a new version of that mint replaces the old version, whenever a new series of the currency is rotated in. (This is necessary to allow the server operator to occasionally destroy the spent token database, which would otherwise continue growing forever, with the operator forced to maintain it forever.)
OTToken — A basic unit of untraceable digital cash. Tokens have denominations (1, 5, 10, 25, 100, etc) and OTToken works together with OTMint. All of the Lucre code in OT resides in these two classes. (Coin, Bank, PublicBank, etc.)
OTPurse — Since an OTToken can only have a set denominational amount (1, 5, 10, etc), it is necessary to carry purses full of tokens, in order to withdraw exactly the correct amount that you require (such as 8734, or 98, or 139, etc.) Thus, OT users will more commonly interact with purses than with actual tokens.

NUMBERED ACCOUNTS / SIGNED RECEIPTS
OTTransactionType — This is the base class for OTLedger, OTTransaction, OTItem, and OTAccount. Derived from OTContract.
OTLedger — Contains a list of transactions. Used in messages, and also used for inbox/outbox.
OTTransaction — The basic transactional unit, including a transaction number(s), and a list of transaction items.
OTItem — OTTransaction contains a list of these. (Usually two.) There might be a withdrawal item and a balance agreement item. Or a deposit item and a balance agreement item. Or a transfer item and a balance agreement item. Etc. (All transactions require a balance agreement.)
OTAccount — The class that handles the intermediary file for account balances.

CRYPTO UTILITY CLASSES
OTEnvelope — Encrypts/decrypts a piece of data (usually an OTASCIIArmor) using a Nym’s private and public keys.
OTPassword — OT is endeavoring to use secure password storage in RAM.
OTSymmetricKey — For password-based crypto.
OTAsymmetricKey — An OTPseudonym has a public/private key pair.
OTSignature — An OTContract has a list of these.
OTASCIIArmor — Takes string or binary data, and then packs it, compresses it, base-64 encodes it, and returns as a base64-encoded string. Derived from OTString.
OTSignedFile — Uses a Nym to sign any content, and then stores it as an OT contract, including the file path information inside the contract as well.
OTCachedKey — The private keys of the Nyms in the wallet are encrypted to the cached master key (as their “passphrase”.) The cached key itself is randomly generated and then kept encrypted to a symmetric key from a key derivation algorithm (from the user’s passphrase.) It uses threads to erase the cleartext portion of the cached key after X seconds have passed. The user will be forced to enter his passphrase again after X seconds.
OTCrypto — I’ve started the process of moving all OpenSSL-specific code into “OTCryptoOpenSSL” which is derived from OTCrypto and accessed as OTCrypto::It(). This will make it easier, in the future, to swap other crypto libs in and out of OT.
OTKeyring — If configured to do so, OT will cache the derived key (used in OTCachedKey, above, to unlock the actual cached master key) using the system keyring. Currently supporting: gnome-keyring, Mac Keychain, KDE KWallet, and Windows DPAPI.

We should always endeavor to use standard protected memory APIs and authentication agents (such as gpg-agent and ssh-agent.) We will endeavor to use our own crypto as a separate layer, wherever possible. We will endeavor to use random memory layout, and code obfuscation, stack smashing protection, static and dynamic analysis, clean out the buffer overflows etc. Security never stops!

CLIENT
OTClient — The primary class on the client side.
OTServerConnection — Manages the client’s connection to a specific OT server.
OTWallet — Manages client-side list of Nyms, Asset Contracts, Server Contracts, and Accounts.

SERVER
OTServer — The main class for the OT transaction server (transaction.exe).
OTClientConnection — Manages a single client connection to that server.
OTCron — Manages a list of Cron Items (that process their terms on a regular basis, including payment plans, market trades, and who knows, maybe someday: Ripple orders.)
OTMarket — Manages a list of active offers, and processes trades between them. There may be many markets on any given OTServer. Derived from OTContract.

FOR THE PROTOCOL
OTMessage — Derived from OTContract.
OTMessageBuffer — Contains a list of OTMessages.
OTPayload — Derived from OTData.

BASIC DATA TYPES
OTData — The base class for binary data in OT. (Like OTString, except for binary data.)
OTString — The basic string class for OT. (In the C++ language, the standard classes aren’t meant to be used as “first class” classes, but need to be wrapped. OTString is built around its interface with other classes in the OT library, and it is easy to swap the internal string code later, without impacting anything else.)
OTStringXML — Derived from OTString. Used in conjunction with the XML library that OT currently uses for its XML contracts. (irrxml.)