# Chrys' Onboarding

## Preliminaries

Walk Chrys through the teams, people, and who does what.


## First Exploration

* Read the [Codex Whitepaper](https://docs.codex.storage/learn/whitepaper)
* Get Codex:
* compile from source and run the test suites;
* run the testnet tutorial and peer into how it works.

## Warm Up

#### 1. **Get acquainted with Nim and, our build system, and how to build Codex.**

* Nim resources:
* Status' Nim style guide: https://status-im.github.io/nim-style-guide/00_introduction.html
* Nim manual: https://nim-lang.org/docs/manual.html
* Nim book: https://nimprogrammingbook.com/
* Build system:
* how it works;
* why do we use it instead of [nimble](https://github.com/nim-lang/nimble); briefly cover its shortcomings, note that it is still used for building dependencies;
* mention limitations such as lack of incremental compilation;

#### 2. Editor Tooling

* VSCode Editor Extension: https://github.com/nim-lang/vscode-nim;
* nim-langsever for navigation (sadly, haven't been working lately): https://github.com/nim-lang/langserver
* walk thorough modify/compile/run workflow:
* calling env.sh before starting the editor;
* [use ccache](https://ccache.dev/).

#### 3. First Task: Slot Repair

When storage is purchased for a certain dataset $F$, Codex will erasure-code it and split it into $n = k + m$ "slots", or disjoint partitions, such that any $k$ such partitions are enough to recover the file. Fig. 1 shows one such dataset with $k = 3$ and $m = 2$. All going well, we can assume that each of these slots will be allocated to a different _storage provider_ which, hopefully, fail independently from one another.


**Figure 1.** A dataset $F$ with $k = 3$ and $m = 2$.

Currently, $F$ needs to be erasure-coded _at the node that wishes to purchase storage_, which we refer to as the _storage client_ (SC). Once the SC posts its storage request on-chain, interested _storage providers_ (SPs) will attempt to grab a slot each, and contact the provider to download the block range that makes up that slot (Fig. 2).


**Figure 2.** Storage providers willing to take the storage deal under the terms offered by the storage client slots so they can store them.

If a slot fails before a storage contract is over; i.e., if fails to submit timely storage proofs, Codex might decide to put it back on the market for some other storage provider to pick up. The problem, of course, is that the block range that makes up the failed slot might no longer exist on the network, meaning that the provider wishing to pick up that slot will have to reconstruct it from available data (repair).

Fig. 3 illustrates how this works: the provider will need to download enough blocks to reconstruct each block in the slot. Once they are able to do it, they can start submitting proofs for the slot and take the contract to themselves.


**Figure 3.** Provider $3^{\prime}$ attempts to repair a failed slot.

The code that gets triggered when a Codex node needs to either download or repair a slot [is here](https://github.com/codex-storage/nim-codex/blob/e9c6d198732874203755c473363b624562725df8/codex/node.nim#L614). The signature for the callback proc is:

proc onStore(
    self: CodexNodeRef,
    request: StorageRequest,
    slotIdx: uint64,
    blocksCb: BlocksCb,
    isRepairing: bool = false,
): Future[?!void] {.async.} =

The `isRepairing` flag is set to true when Codex should repair a slot (Fig. 3) instead of just attempting to download it (Fig. 2), but the code currently in there will always attempt to download. Your task is to implement the actual repair process; i.e., to fetch the blocks required to reconstruct the slot and then reconstruct it instead of directly attempting to download the slot when `isRepairing` is set to true.

#### 4. Second Task: Add Encrypt-by-Default to Codex

Files uploaded to Codex are currently stored unencrypted at storage providers. We would like to make those encrypted by default. Since every Codex client has a private key, the idea would be to derive file-specific using this key as randomness.

It would probably make sense to make the Codex key more user-frienly in the process, like allowing the user to derive the key from a passphrase.

#### 5. General Advice to Make Life Easier.

* ++Propose before you build++. For the task above, this advice applies particularly to how command line arguments should work. We'll try to come to a decision quickly but people will have opinions and it's always best to run these things through the team before going with one decision or the other.
* ++Small PRs if possible++. Several, smaller PRs are easier to review and less likely to get stuck over one big PR.
* ++Make sure people are onboard++. When you are planning on doing larger changes, make sure people are on board or you may end up in a frustrating PR review paralysis. This is particularly true if you get blocked by someone who's not in a reasonable timezone and can't iron out differences over face-to-face discussion. Over time you'll get a feeling for who you need to bring on board for what. I'll always be here to facilitate and prevent things from getting stuck as much as I can.