The scope of the software is huge. And it is not possible to achieve that in one go (no matter how well you define “one go”). So we will do it in phases, the way real software gets shipped anyway. So let’s chalk out a small plan of features, without timelines. The last time I tried something, it was with a not-so-concrete plan with fixed timelines, I could not deliver. So this time, I am doing two things - I am making a better plan and I am letting the timelines a bit loose. The focus therefore is on the result, not on the timelines; although the timelines are still in the view.
The following is going to be the plan for making Chamber, in stages.
The alpha (MVP) stage
This is the stage in which we will build the most core functionality without any bells and whistles. Here is a list of functionality that I am targeting:
- CLI. The CLI interface with a few commands. The definition and the set of commands as expected are mentioned here: Chamber CLI commands and options.
- Storage Layer. The storage system and mechanism to be used. Auto-expansion should be baked in.
- Encryption mechanism. The encryption mechanism and key derivation process to be completed.
- Ensuring a vault is ready for future upgrades. As development progresses, many things will change. It should be possible to migrate an existing vault to a newer format when introduced. This mechanism will de decided and introduced in the beginning to make the software usable from MVP stage.
This feature set will allow someone to start using Chamber right away.
This stage will NOT:
- allow inserting large files (size limit to be decided later, but probably would be between 10 to 50 MB).
- have any GUI related work.
- support splitting/joining.
- support mounting.
- support password/key change.
- contain any support for hosting the vault elsewhere.
- be optimized and would probably consume more memory and compute.
- support any extra authentication mechanisms.
- promise fault tolerance and may not support verifications.
- no support for CoW (Copy-on-Write) behavior of any kind.
- support shrinking of a vault file after deletion of a file.
- promise to be cross-platform.
This stage might contain bugs but should have enough definition around the core elements that allows for future improvements and enhancements.
Timeline: 1 Week from start.
The Beta 1 stage
The stage where the users who are interested in help test Chamber should be usable by most technical users. The following features will be added:
- CLI improvements: More commands will be added, richer information to be shown for each command and reliability of the output should improve.
- Allow inserting large files: A file of larger size should be acceptable inside the vault.
- Allow a vault to shrink: After a file is removed from the vault, the vault file will shrink accordingly.
- Support Password change: The user should be allowed to change the password (but not the encryption key, yet).
- Introduce memory optimizations: Since large file processing will be enabled, some memory consumption optimizations will be introduced.
This stage will still not be ready for everyday use. It will still not:
- support change to encryption keys
- support CoW
- support any extra authentication mechanisms
- over-optimize memory requirements
- support splitting of a vault (or joining the splits)
- support any form of mounting
- have anything around the GUI
- have any support for hosting
- promise to be cross-platform (users would have to test this if we release).
This stage would still probably contain bugs but should be relatively fewer.
Timeline: 2-3 weeks after start.
The Beta 2 stage
The stage where most technical users should be able to use Chamber without having to overly worry about crashes, though there still can be some troubles along the way. Along with better stability, the CLI interface will start getting a better, more stable CLI option set.
The following features should be made available at the end of the period:
- Allow change to encryption keys: If the user wants to change the encryption key, he should be allowed to. This will be a “long running command” (something that happens in the background over time without blocking normal operations).
- Support for long running commands: If someone starts a long running process, the software must record all the steps to be taken before taking them. This should allow us to sequence long running commands. For example, if someone wants to both change the encryption key and then copy a directory from host FS into the vault, then the encryption key change will be done first and only then will the copy operation started. This should allow fault tolerance and allow all operations to complete reliably. Remember: stability over performance.
- Cross Platform: The software should be allowed to run on Windows, macOS and Linux (acceptable modern versions only). No support for mobile at this stage.
- Basic hosting features: A web server which can at least respond to APIs that can be called while NOT mounting the vault file should be built (this alone is a big ask).
- Support for Vault Split: If the “splitting” is enabled for the vault, the split files will be generated and maintained. They all should show the “auto shrink” behavior. If a file is deleted from any of the split files, the split size should shrink.
The stage will skip on (will NOT):
- extra authentication mechanisms.
- auto-join small splits.
- joining splits into a large vault again.
- gui related work
- support full blown web hosting
- memory optimizations
- support mounting
- support CoW
Timeline: 1-2 months after starting.
The first final release
The entire feature set of the final release is not yet decided and can take a long time. This page might get updated as things progress.
The stages planned so far are already planned way too ahead without a single line of code written, without bypassing a single challenge. No more plans at this point of time!