Banyan CLI

Outline

• Outline
• What is the Banyan CLI?
• Installation
  • Using cargo
• Usage
• Testing the Project
• Benchmarking the Project
  • Configuring the benchmarks
  • Running the benchmarks
  • Profiling the binary
• Contributing
  • Formatting
  • Pre-commit Hook
  • Recommended Development Flow
  • Conventional Commits
• Getting Help
• External Resources
• License

What is the Banyan CLI?

The Banyan CLI library is a tool for indexing, chunking, encrypting and decrypting large files and directories into manageable and portable CAR files of blocks that don't leak information about the original filesystem, plus a reconstruction manifest.

It it interacts seamlessly with our Web API to present you with an interface that can encrypt filesystems from scratch, or connect up to an existing Banyan account.

The CAR files generated by this tool can be uploaded to Filecoin, but we're happy to take care of that part too. Metadata files are optionally sent through Banyan's webapp, so you can share and manage your files from any device. Banyan handles all of this for its customers.

This repository uses WNFS to get features like granular and feature-packed cryptographic permissioning and file version control.

The core of this repository cross-compiles to WASM so you can access filesystems packed by the Banyan CLI in the browser.

It is meant to be used as a tool for preparing even large quantities of data for manageable archival storage on decentralized storage networks such as Filecoin.

It's meant to run anywhere.

Installation

Using cargo

To install our CLI tool using cargo, run:

cargo install --path banyan

Usage

The Banyan CLI is easy to use. Create a new Drive, run:

banyan drives create --name <NAME> --origin <ORIGIN>

Where <NAME> is a unique name for your new Drive and <ORIGIN> is the directory you want to create a Drive of. To then encrypt this Drive, run:

banyan drives prepare <--drive-id <DRIVE_ID> --name <NAME> | --origin <ORIGIN>>

This syntax is letting you know that you can use the Drive's <NAME>, its <ORIGIN>, or its unique generated <DRIVE_ID> as a way of telling the CLI which Drive you are referring to. The prepare command finds the correct Drive, scans your filesystem for any changes to it, and encrypts the data locally as a means of preparing it either for our services or for Filecoin directly.

To sync this encrypted data with our services:

banyan drives sync <--drive-id <DRIVE_ID> --name <NAME> | --origin <ORIGIN>>

The sync command determines if you are behind or ahead of the Drive we have persisted remotely and runs the appropriate networking code to transfer metadata and CAR files as needed.

To decrypt a Drive, run:

banyan drives restore <--drive-id <DRIVE_ID> --name <NAME> | --origin <ORIGIN>>

The restore command will either reconstruct new data in the original directory specified, or create a new one if that directory is no longer available. The Banyan CLI can intelligently use remote backups to reconstruct your files directly, even if you have no CAR files cached on disk.

Testing the Project

• Run tests

  cargo test --features cli
  

  This should run all the tests in the workspace.

Contributing

:balloon: We're thankful for any feedback and help in improving our project! We have a contributing guide to help you get involved. We also adhere to our Code of Conduct.

Formatting

For formatting Rust in particular, please use cargo fmt as it uses specific nightly features we recommend by default.

Pre-commit Hook

This project recommends using pre-commit for running pre-commit

hooks. Please run this before every commit and/or push.

• Install pre-commit on this project

  pre-commit install
  

• If you are doing interim commits locally, and for some reason if you don't

  want pre-commit hooks to fire, you can run

  git commit -a -m "Your message here" --no-verify.

Recommended Development Flow

• We recommend leveraging cargo-watch, cargo-expand and irust for Rust development.
• We recommend using cargo-udeps for
• emoving unused dependencies before commits and pull-requests.

Conventional Commits

This project lightly follows the Conventional Commits convention to help explain commit history and tie in with our release process. The full specification can be found here. We recommend prefixing your commits with a type of fix, feat, docs, ci, refactor, etc..., structured like so:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Getting Help

For usage questions, usecases, or issues reach out to us in our Discord channel.

We would be happy to try to answer your question or try opening a new issue on Github.

External Resources

These are references to specifications, talks and presentations, etc.

License