Accepts an invitation, an entity accepts an invitation and becomes part of the invitation.
The invitation to be accepted.
Optionalparams: AppendInvitationParametersOptional parameters for accepting the invitation.
The updated XOInvitation instance.
Appends the invitation with the new information.
The identifier of the invitation to append. The invitation must already exist in the store.
The parameters to append the invitation with.
The appended invitation.
Creates an invitation that can be shared with other entities, user, application, etc. Invitation is the fundamental communication unit in XO, all the interactions done using the xo template are done using invitations.
The parameters for invitation creation.
Parameters required for creating a new XO invitation.
Identifier of the action within the template to initiate.
Identifier of the template to use for this invitation.
A promise that resolves to the constructed invitation.
Executes an action for a given invitation.
The identifier of the invitation whose action to execute. The invitation must already exist in the store.
Parameters for executing the action.
Resolves with the transaction hash when the action is executed.
Generates the locking bytecode for a specified template output and role.
Role is important because in the template definition it can direct to a different secret or a locking script for that to be discovered and used, it must know what role is provided. Also, it's important for libauth compiler to know what role is being used to generate the locking bytecode.
Currently, only "standard" type (e.g. P2PKH) locking scripts are supported. In the future, this method will be extended to support more output script types based on template definitions.
Future definition of primitives is going to define how other non-p2pkh locking scripts are validated, for example, p2pkh is possible because the engine know what a private key and public key is more such primitives will be defined and they will be helpful in generating and validating locking scripts of different types.
Process overview:
TODO: Support additional types of outputs/scripts tied to template specification. TODO: If important to make this process faster, consider emitting an event and pushing process to the event loop. TODO: Encrypt the new information, update the encrypted state servers.
Identifier of the template.
Identifier of the output (from the template).
OptionalroleIdentifier: stringRole identifier (corresponding to a role in the output's script).
The generated locking bytecode as a hexadecimal string.
Generates a locking bytecode using the engine's default template, output, and role identifiers.
A promise that resolves to the generated locking bytecode as a string.
Generate locking data and derivative index for P2PKH.
Retrieves the current chain status from the electrum application.
The current chain status.
Fetches a stored invitation by identifier
The identifier to look up.
The stored invitation, or undefined.
Finds suitable resources for an invitation.
TODO: May become private. This may change in the future and become a more advanced coin selection method used directly by the engine. The current behavior is that it finds "spendable" outputs, but we may adjust this to actually find "suitable" outputs.
The invitation to find resources for.
Optionaloptions: GetSpendableResourcesParametersParameters for finding suitable resources.
The list of suitable resources.
Retrieves a template by its identifier from the state.
Template identifier.
The template object.
Fetches a stored template by identifier
The identifier to look up.
The stored template.
Imports a template into the Engine after sanitization and validation.
JSON or object containing the untrusted template to import.
Resolves when the template is imported.
TODO: Implement this.
State sync should always be working, any hiccups in the sync process should be resolved Unable to do so should halt all operations unless no remote servers are provided.
Initializes the state sync process.
Resolves when the state sync is initialized.
Lists all the imported templates.
The list of imported templates.
Lists missing requirements for the provided invitation.
The identifier of the invitation to analyze. The invitation must already exist in the store.
The missing requirements.
Lists requirements for the provided invitation.
The invitation to analyze requirements for.
The requirements information.
Gets all the script hashes from all the templates.
An array of script hash data objects.
Retrieves a list of script hash data stored for a given template identifier.
The identifier of the template.
An array of script hash data objects.
Lists the starting actions available in a specified template.
Template identifier.
The list of starting actions.
Lists all the unspent outputs.
The list of unspent outputs.
TENTATIVE METHOD: DEFAULT LOCKING STRATEGY UNKNOWN
Sets the default locking parameters (template, output, and role identifiers) for the engine. TODO: The default identifiers exist as the strategy on how to create the change and default unlocking conditions are unclear. This is likely to change in the future.
The identifier of the template to use as default.
The identifier of the output within the specified template.
The identifier of the role to use as default for this output.
Resolves when the default parameters have been successfully set.
Signs the provided invitation once all the resources are reserved and the invitation is complete. This method is used to sign own inputs and provide unlocking data for them, this appends the invitation and adds new commit with unlocking data.
The identifier of the invitation to sign. The invitation must already exist in the store.
Resolves when signing is complete.
Stops the engine instance and cleans up resources.
Resolves when the engine is stopped.
Subscribe to the script hashes for a template.
TODO: Make this a private/internal method. We may change how/where this is defined in the future. We'd like to ensure events are propagated to the sync server with an ACK and that the states match between remote and local.
Template identifier.
Resolves when the script hashes are subscribed.
Synchronizes the store of unspent outputs for a given script hash with the current state of the blockchain.
This method performs the following:
The script hash for which to update the stored unspent outputs.
Update the unspent outputs for all of a templates lockingBytecodes.
TODO: Make this an private/internal method.
Template identifier.
Resolves when the unspent outputs are updated.
StaticcreateInitializes and creates a new XO Engine instance. Configures the state, initializes the sync server and monitor for app and blockchain events
BIP39 mnemonic to be used for this instance of the engine.
Database configuration options.
An initialized Engine instance.
XO Engine class: Acts like an orchestrator for the XO system.