List of Classes

From Open Transactions
Jump to navigation Jump to search

Open Transactions is, at its core, a class library. (See full documentation here.)

Also, be sure to read the detailed notes on the API.


HIGH-LEVEL API
OT_ME -- The high-level API, as used from C++. Used for sending messages back and forth with an OT server.
OTMadeEasy -- A SWIG wrapper for the high-level API. Used for all other languages, such as Python, C Sharp, PHP, etc.


LOW-LEVEL API
OT_API -- A C++ class that provides the lowest-level API (as a wrapper around this class library.)
OTAPI_Wrap -- The low-level API, as used in C++.
OTAPI_Basic -- The low-level API, as used in all other languages.


USER / PSEUDONYM
OTPseudonym -- Used as an identity. Each user wallet may contain multiple Nyms. Each Nym may be registered at multiple servers. When contracts are signed or verified, it is the Nym performing these actions. Each Nym has master credentials, which issue sub-credentials, which contain key pairs for signing, encryption, and authentication. OTPseudonym also manages lists of request numbers and transaction numbers for that identity on various OT servers. A pseudonym may own many asset accounts.
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.)
OTCredential -- This is the base class for credentials.
OTKeypair -- Encapsulates the functionality of a key pair (public/private key.)
OTSubcredential -- Derived from OTCredential. A subcredential is signed by a master credential. Subcredentials are what are actually used by Nyms for signing / verifying transactions.
OTKeyCredential -- A form of OTSubcredential that contains 3 OTKeypairs: for signing, authentication, and encryption. We won't use OTKeyCredential directly, but only as a common base class for OTSubkey and OTMasterkey.
OTSubkey -- Derived from OTKeyCredential. This is a form of subcredential that uses 3 key pairs (signing, encryption, and authentication.) There might be other subcredentials in the future which don't use key pairs, such as for 2-factor authentication. (But this specific subclass is for subcredentials with key pairs.)
OTMasterkey -- FYI, this is called "master key" instead of "master credential" because it ALWAYS has keys. Derived from OTKeyCredential. Each Nym has a "Source" string, and a NymID which is a hash of that source string. Each Nym also has a master credential(s), which can be used to issue sub-credentials. Most importantly, the master credential hashed ID should somehow verify against the source. For example, if the source is a traditional cert, then the master credential should be signed with that cert, and if it's not a self-signed cert, then it should also verify through its CA. Another example: if the source is a Namecoin address, then you should be able to lookup that Namecoin address and find the hashed ID for any master credential that claims that Namecoin address as a source. In this way, Namecoin can replace CAs. A master credential might also just be signed with itself (meaning revocation is not possible...)


UTILITY CLASSES
OTLog -- The OT logging class. Verbosity defaults to 0 but you can change it in the config file (up to level 5.)
OTCleanup -- This class is used to making sure specific objects are destroyed when it goes out of scope. (So we don't have to worry about cleanup for every single exist path from a function -- we know it will cleanup no matter how the function returns.)
OTNumList -- A utility class used for manipulating sets of long integers. It is also able to handle input/output as a string containing comma-separated numbers.
OTSettings -- Used for loading up (or creating) the config file.
OTFolders -- Used to look up various folders in local storage. Such as: OTFolders::Mint(), OTFolders::Nyms(), etc.
OTDataFolder -- Used for determining the data folder path across various platforms.
OTPaths -- Used for constructing any path in local storage, across various platforms.
OTAcctList -- The server needs to store a list of accounts, by asset type ID, to store the backing funds for vouchers. This class is useful for that. It's also useful for the same purpose, for stashes (in smart contracts.)
OTAmount -- Wrapper class for amounts, to be used wherever amounts are manipulated in OT. (It's not yet used in every place...)


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.
OTPayment -- A useful wrapper class for generalizing instruments like OTCheque, OTSmartContract, OTPaymentPlan, and OTPurse.


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 chaumian 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.
OTMint_Lucre -- While OTMint is the abstract interface, this is the actual implementation for the token mint (using Lucre.)
OTToken_Lucre -- While OTToken is the abstract interface, this is the actual implementation for blinded tokens (using Lucre.)


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.
OTAcctFunctor -- Abstract base class for any operation that can be performed across a range of asset accounts.
OTAcctFunctor_PayDividend -- Used for paying a dividend to shareholders. It iterates across all the asset accounts of a certain share type, and for each, sends a payment cheque to the account owner.


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 -- OTCrypto is OT's abstract interface to crypto functionality. It's accessed as OTCrypto::It(). This makes it very easy, 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.
OTPasswordData -- OTPasswordData is passed in those places where you need to collect a passphrase from the user. It contains the request string. For example, "Are you sure you want to transfer 10 BTC to Bob?" This way, no matter how deep the rabbit hole goes, no matter how many functions are called before the passphrase dialog actually has to pop up, the proper display string will be available to it. We will know, high-up in the API, that this is the action the caller is ultimately trying to accomplish. (There might be various signatures and verifications along the way, and we aren't sure until runtime, which one will be the first to trigger the dialog...)
OTSignatureMetadata -- Since Nyms are now able to have credentials, this means a Nym might have 20 credentials. So when you go to verify a signature, is OT supposed to just verify the signature against all 20 of them until it finds the right one? The solution is, we attach metadata to the signature which makes it much quicker/easier to find the right credential. OT doesn't even bother trying to verify certain credentials against a signature, if their metadata doesn't even match.
OTNym_or_SymmetricKey -- There are many places throughout OT where you have the option to use symmetric crypto (with a key) or asymmetric crypto (with a public and private key.) This class allows us to pass either one (a Nym or a Symmetric Key) into various functions, and the function will work either way.
OTCrypto_Decrypt_Output -- Sometimes I want to decrypt into an OTPassword (for encrypted symmetric keys being decrypted) and sometimes I want to decrypt into an OTPayload (For most other types of data.) This class allows me to do it either way without duplicating the static Decrypt() function, by wrapping both types.
OTCrypto_OpenSSL -- Derived from abstract base class OTCrypto. OTCrypto_OpenSSL contains the actual OpenSSL implementation for the crypto functionality in OT. If you wanted to use GPG instead, I already put the preprocessor defines into the code. Just make a copy of OTCrypto_OpenSSL, called OTCrypto_GPG. Then have that implementation call the GPG functions instead of the OpenSSL functions.
OTAsymmetricKey_OpenSSL -- If you make OTCrypto_GPG, then you must also make OTAsymmetricKey_GPG. (OTCrypto and OTAsymmetricKey are the abstract base classes and they go together -- if you subclass one, you must subclass both.)
OTLowLevelKeyData -- Wrapper class used for passing x509's and EVP_PKEYs around, so that a replacement crypto engine will not require changes to any function parameters throughout the rest of OT.

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!


SCRIPTING
OTScript -- The abstract base class for scripting in OT.
OTScriptChai -- Derived from OTScript. This contains the actual implementation where OT makes chaiscript-specific calls. New languages are very easy to add. If you wanted to add, say, Lua, just make a copy of OTScriptChai called OTScriptLua, and code it to use Lua calls instead of chai calls (done.)


SMART CONTRACTS
OTStash -- A stash is like an account hidden inside a smart contract. Smart contracts are able to "stash" funds internally, for use in scripts such as escrow and server wiring.
OTStashItem -- Used by OTStash. (Each named stash has a different storage account for each asset type.)
OTBylaw -- A smart contract contains a list of bylaws. Each bylaw contains scripted clauses, and persistent and constant variables (which are available from inside the clauses), as well as hooks (giving the ability for clauses to trigger at various times) and callbacks, which enable external code to ask the smart contract certain questions, like, Does Alice have the right to trigger the dispute clause? etc.
OTClause -- A scripted clause on a smart contract. A bylaw contains a list of these.
OTVariable -- A variable on a smart contract (Available from within all the clauses.) For example, one clause might increment a count, and store that count in a variable. Then later on, another clause is triggered, and it's able to see that same variable, and make decisions based on its state.
OTParty -- Each smart contract contains a list of named parties. For example, "Alice" and "Bob." Later on, which actual Nyms have signed and activated the contract, those names are associated with the specific NymIDs of the signers. All scripted clauses must refer to Nyms by name only -- this way if any "bad" IDs are somehow injected into a running clause, they will be useless, since the clause can only operate based on the names.
OTPartyAccount -- Each party to a smart contract must declare specific asset accounts by name. For example, "alice_gold". This way when the smart contract is running, it would be futile to inject any account IDs, since a scripted clause can only operate based on the account names, which are translated internally into their proper IDs, based on the signed contract.
OTAgent -- Each party has a list of agents who are authorized to act on behalf of that party. Currently the agent for any party is the same Nym. (The owner Nym -- aka the party -- is also the same Nym ID inside the authorized agent.) But in the future, this mechanism will enable corporations that can appoint agents to act on their behalf.


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.
OTCallback -- Used for the passphrase dialog. Let's say you are coding OT in Python. Make your own Python-based subclass of OTCallback, and code it to pop up a Python dialog to collect a passphrase.
OTCaller -- Then create an OTCaller, and register your OTCallback instance with it, so that your passphrase dialog is what pops up whenever OT needs to collect a passphrase from the user. (Otherwise OT will be forced to ask at the command line, instead.)


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
OTPayload -- Derived from OTData.
OTMessage -- Derived from OTContract.
OTMessageBuffer -- Contains a list of incoming OTMessages.
OTMessageOutbuffer -- Contains a list of sent messages.


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.)


DATABASE
OTDB::Storage -- The storage context (Abstract base class.)
OTDB::StorageFS -- Storage context (filesystem implementation.)
OTDB::Storable -- All "storable" objects are derived from this class. The OTDB::Storage class can save/retrieve these objects.
OTDB::OTPacker -- Abstract base class for the packer, which is used to pack storables before they are written to storage. Currently there are msgpack and protobuf implementations for this interface. (Protobuf being the one that is mostly used these days.)
OTDB::PackedBuffer -- The output from OTPacker that's written to local storage. Upon retrieval, this is the object that is unpacked in order to produce the original storable.
OTDB::OTDBString -- OTDB::Storage often writes/reads strings to/from local storage. This is the string storable.
OTDB::Blob -- OTDB::Storage often writes/reads blobs (Binary Large Objects) to/from local storage. This is the blob storable.
OTDB::StringMap -- OTDB::Storage often writes/reads string maps (key/value pairs) to/from local storage. This is the string map storable.