SDK Cheat Sheet
Date | Responsible | Changes |
---|---|---|
January 16, 2023 | @Omar Monterrey | Initial version |
May 24, 2023 | @Omar Monterrey | Added Schemas section to general concepts. Added schemas and circles reference to Summary of calls. |
May 25, 2023 | @Luis Fidelis | Add commands for managing signers in a circle. |
October 25, 2023 | @Luis Fidelis | • Added commands for managing policies • Added commands for managing anchors • Added commands for querying anchors and domains from wallet client |
Here you will find a list of common scenarios for using the SDK with different parameters
Initial Setup
Below you will find the initialization of some variables that will be used across different examples
SDK Initialization
Create a new instance of the SDK
If verifyResponseProofs
is true, the signer
property is mandatory as it will be used to automatically check responses.
If secure
is provided, all requests made by the SDK will send a JWT token to authenticate
Access Rules
Let’s create a simple helper function to generate access rules that will grant all permissions to the provided public key, meaning that public key is the owner of the record.
If you want more information regarding access rules, see also:
How to set up record access rules
Creating a Local Signer
In real scenarios we shouldn’t use a signer for everything, but in this case let’s create a Key Pair that we can use for everything
Creating a Remote Signer
Previously, we created a keyPair
locally, but in case we want to store it remotely we can self-sign it and send to the ledger. Note that secret
is optional and you don’t need to store it on the ledger.
Fetching and decoding a Remote Signer
After storing a signer remotely, you can fetch it anywhere to sign some other records using it. If the signer secret was encrypted using the .code
method, now you will use .code
again to decrypty it.
Onboarding
Let’s follow the process to have everything in place before we can make our first intents. For that, we may need Symbols and Wallets
Creating a Symbol
First, let’s create an USD Symbol. The code is very similar to creating a remote signer, in fact the creation of most records is very similar.
Creating a wallet
Now we need wallets that will hold balances of those symbols.
Retrieving a wallet and its balance
After we created our wallet, or any record, we can use the read
method to retrieve it. For wallets, we also have a balances
method to get the balances of an specified wallet
Registering a bridge
Registering a bridge on the server means creating a bridge
record for it, similar to what we did before with symbols and wallets.
If you want more information regarding bridges, see also:
Bank integration tutorial (open banking)
Updating a wallet (adding the bridge)
Now that we have a bridge registered, we can update our existing wallet to use this bridge.
Sending intents
Now we are ready to send intents between our wallets. Please have in mind that we are assuming that the server passed as property to config.server
in our teslabank
bridge is up and running, confirming all of our transactions.
Creating an intent
First, let’s create an issue intent to our tesla
wallet, so it holds some balance.
Signing an existing intent
In some cases we want to add signatures to intents that already exists, for example when validating them from bridges, it’s similar to an update but adding the signatures instead of changing the data.
Verifying record’s proofs
By getting the property .proofs
of our SDK instance, we can get a proofs verifier client that allows us to verify the proofs of a record
Retrieving error from record proofs (if any)
If our intent fails for some reason, a signature will be added to our intent’s proofs containing the error reason. We can extract that error using the error
method of the proof verifier client
General concepts
Record Create, Read and Update
Creating records
The rules for creating different types of record may vary a little, but as you could see they are pretty much the same. Sending a signed record to the server
Reading
When reading a record using the read
method, its returned value will have a property which name will match the name of the record (wallet
or symbol
, for example) that contains the record’s data, we will also get hash
and meta
properties for that specific record.
Updating
Similar to using the init
method to initialize the entire record, we can use the from
record with the entire record data (Including meta
and hash
) to update a record. Have in mind that the handle must exists and the hash will be validated.
Lists and pagination
When reading records using the list
method, its returned value will have a property which name will match the name of the record in plural (wallets
and symbols
for example) containing a list of the record’s data.
As described in About Querying, you can also apply filters when listing, in order to narrow down your results. For example, to only get the wallets whose schema is bank
, you would:
Schemas
schema
is a special type of record which contains a set of rules and constraints used to validate the record that references it. Schemas can be created for a specific record type and if at least one schema exists for any record type, all records of that type that are created or updated must reference at least one valid schema. Record types that can be validated using schemas are signer
, symbol
, wallet
, bridge
, intent
, effect
and circle
Creating an schema
Creating an schema is just like creating any other record.
Referencing an schema
To reference an schema, you just need to pass the schema
property of the record's data with the handle of the desired schema.
If you want more information regarding schemas, see also:
Summary of calls
When you see ...
, it’s a placeholder for the correct expected data, as documented earlier.
Signer
Symbol
Wallet
See About Anchors and About Wallets for more details.