🚧 Under construction! 🚧
chel
chel help [command]
chel version
chel keygen [--out=<key.json>]
chel manifest [-k|--key <pubkey1> [-k|--key <pubkey2> ...]] [--out=<manifest.json>] [-s|--slim <contract-slim.js>] [-v|--version <version>] <key.json> <contract-bundle.js>
chel deploy <url-or-dir-or-sqlitedb> <contract-manifest.json> [<manifest2.json> [<manifest3.json> ...]]
chel upload <url-or-dir-or-sqlitedb> <file1> [<file2> [<file3> ...]]
chel latestState <url> <contractID>
chel eventsAfter [--limit N] <url> <contractID> <hash>
chel eventsBefore [--limit N] <url> <contractID> <hash>
chel hash <file>
chel migrate --from <backend> --to <backend> --out <dir-or-sqlitedb>
Note: in many (if not all) instances, the <url> parameter can refer to a local folder path, in which case the command will operate without making a network connection, and will instead use the folder's contents to perform its operations.
{
"version": "1.0.0",
"cipher": "algo",
"pubkey": "...",
"privkey": "...",
"encrypted": "algo"
}
If "encrypted" doesn't exist - it means the "privkey" was saved in the clear.
Let's say you have the following files:
contract-bundle.jscontract-slim.js
Running chel manifest --add-key alex.json --slim contract-slim.js deploy-key.json contract-bundle.js will generate the following contract-bundle.manifest.json:
{
"head": {
"manifestVersion": "1.0.0"
},
"body": JSON.stringify({
"version": "<contract version string, 'x'> by default",
"contract": { "hash": "<hash of contract-bundle.js>", "file": "contract-bundle.js" },
"contractSlim": { "hash": "<hash of contract-slim.js>", "file": "contract-slim.js" },
"authors": [
{"cipher": "algo", "key": "<pubkey from deploy-key.json>"},
{"cipher": "algo", "key": "<pubkey from alex.json>"}
]
}),
"signature": {
"key": "<which of the 'authors' keys was used to sign 'body'>",
"signature": "<signature>"
}
}
It will upload both versions of the contracts, and this JSON.
This format makes it as efficient as possible for using the contract system from both in-app and from the commandline.
The CLI tool will always use the self-contained contract bundle, whereas apps can load less code by loading the slim version of the contract. You just need to make sure that none of the external dependencies that you're referencing ever change if you do this, as otherwise you will get different state between the two versions of the contracts.
Note also that Chelonia is fundamentally language agnostic. We started out using Chelonia to build JS apps, but you can use this protocol with any programming language that supports source evaluation at runtime.
Some commands of this CLI tool (like latestState), only support JavaScript, but that is a limitation of resources on our side, and not a fundamental limitation of the protocol.
Deploys manifest(s) generated with chel manifest.
Automatically uploads any corresponding contract files.
Outputs the hash(es) corresponding to the manifest(s).
Useful command:
cp -r path/to/contracts/* test/assets/ && ls ./test/assets/*-slim.js | sed -En 's/.*\/(.*)-slim.js/\1/p' | xargs -I {} ./src/main.ts manifest --out=test/assets/{}.manifest.json --slim test/assets/{}-slim.js key.json test/assets/{}.js && ls ./test/assets/*.manifest.json | xargs ./src/main.ts deploy http://127.0.0.1:3000
Current release hashes will always be listed here.
eefc0c783937e879153c2bc36f3aa435570d6ab4b8d786af2c11c72d21984a91 dist/chel-v2.2.3-aarch64-apple-darwin.tar.gz
8211e8f01ebe06020e2cb383b931d761d103a3de7a7e3fac7948aa0feb275358 dist/chel-v2.2.3-aarch64-unknown-linux-gnu.tar.gz
924e00ee0b3a7aa87bea58baad44bed75e41cab0581da9ea3409e713a594f64c dist/chel-v2.2.3-x86_64-apple-darwin.tar.gz
30671935a46194b4e4dcbc56e9f5272421f45dc602a0fef9536ba8d5e9eaa26d dist/chel-v2.2.3-x86_64-pc-windows-msvc.tar.gz
88aef6fbc2fe671a2a2b3bf6ed99cfdae3a1083b452cc963b5162bcacb03979f dist/chel-v2.2.3-x86_64-unknown-linux-gnu.tar.gz
See HISTORY.md