Repo roadmap to first release

[bigspider]

This issue wants to identify and track the various tasks to complete before a publishable version (not necessarily releasable, but developer-ready).

The most urgent issue imho is to properly partition the project into completely independent modules, so that each module is self-contained, and docs and dependencies are clear.
Different modules could be independent repos in the future, but it might be useful to keep the monorepo structure for now, as long as each module is into its own root folder and properly packaged. The /docs folder should be deleted, or only contain general architectural docs (e.g. the end-2-end paradigm, security model, etc.)

Imagining an end-2-end flow, we have the following components:

• The vm: a bolos app running on a hardware signer (or on the speculos emulator)
• The vm client: a generic client for the vm running on the host, that is able to provide the binary, outsurced RAM, Merkle proofs, etc.
• The app: compiled to target Risc-V
• The app client: specific to the app, extends (or builds on top) of the vm client and is entirely application-specific.

All the paths contained /vm/... below should be renamed to /<name chosen for the vm>/... once the name is chosen.

==============================================

/vm - Virtual Machine app
VM app to be installed on the device.
Tasks:

• Move relevant docs from /docs
• Design and add a method to enable "sideloading": that is, if you compile a binary yourself, you should be able to run it (even in production). It could use a "binary registration flow" similar to the policy registration flow of the bitcoin app, where the app is registered once and the device will return an HMAC of the hash of the manifest after user's approval; the HMAC will later prove that the manifest can be trusted. TBD if registration should be permanent (hmac key derived from the seed), or use a randomized keys which is lost if the vm is reinstalled; both options could be available at the same time, perhaps.

==============================================

/host - Python client side library (rename to vm-client-python?)
Generic client to be ran on the client side of an app.
Contains the generic logic to communicate with the VM, providing the necessary data and proofs, and to send binary messages to the app and receive responses.
Generally, it wouldn't be ran directly; rather it is imported and extended in order to build app-specific clients (which know the encoding of messages and responses, e.g. via a protocol based on json or protobuf).

Tasks:

• Make it a standalone python package
• Add docs
• Add cliend side support for registering an app (once that's implemented in the vm)

==============================================

/app/app-rust/sdk - Rust SDK (move to /vm-sdk-rust)

Tasks:

• Make it a standalone rust crate
• Document how to compile a Rust app
• Document how to setup your dev enviroment instead of using Docker

=============================================

Rather than a boilerplate, we will just develop some good simple apps that will serve as example.

[greenknot]

If I can make a few comments:

• I'd rather have a single documentation folder if it targets developer. It's easier to have doc in a single folder, especially if we enable GitHub pages, while it's painful to jump across different website/repositories. For documentation regarding the internals of a component, it makes sense to have a dedicated folder, though.
• Design and add a method to enable "sideloading": this isn't a high priority topic for now, IMHO. One can have 2 VMs, one with a dev key, one with a prod key.
• Add a module for registering an app: I'm not sure what it means
• I don't think boilerplate apps are useful: they are additional code to maintain and if a few apps are developed correctly, they can serve as example. I originally developed a boilerplate app and eventually removed it since one can look at apps doing real stuff.

[bigspider]

• I'd rather have a single documentation folder if it targets developer. It's easier to have doc in a single folder, especially if we enable GitHub pages, while it's painful to jump across different website/repositories. For documentation regarding the internals of a component, it makes sense to have a dedicated folder, though.

Well, the main documentation for the developer is the sdk, I suppose, so that should have full walkthrough for everything.
Mostly, I care about distinguishing the docs for the VM developers (us), from the app developers using the VM (the world).

• Design and add a method to enable "sideloading": this isn't a high priority topic for now, IMHO. One can have 2 VMs, one with a dev key, one with a prod key.
• Add a module for registering an app: I'm not sure what it means

Personally I think this is quite important: someone should be able to compile a binary, and tell the VM "trust this binary from now on", instead of relying on some HSM's signature.
By "adding a module" I just mean to add some API to the VM for this feature. Bad wording, I'll change it.

• I don't think boilerplate apps are useful: they are additional code to maintain and if a few apps are developed correctly, they can serve as example. I originally developed a boilerplate app and eventually removed it since one can look at apps doing real stuff.

Indeed, I agree. Removed that part.