Audius Track Upload

Setup

1. Install Rust, Solana, Anchor, and IPFS
2. Run an IPFS node and ipfs add <path-to-track>. Save the resulting CID.
3. Switch to the program directory and run anchor build from cli
4. tbd

Design Rationale

I decided to use Anchor to write the project because of its clean setup. I started with writing the instructions setup, creating a new context for the program TracksLibrary and creating an Account type Tracks. It seemed ideal to use a HashMap to store the tracks library because fetches will O(1), especially if the track_id format is changed.

For unique key generation, my first idea was to use Rust's random library and generate a set of alphanumeric characters. However, Solana, and other blockchains, strive for a no-std envrionment. The next idea was to use a simple counter u64. The design is to update the current maximum track id when a new track is uploaded. Then, a new ID can be generated by incrementing from the most current one.

For the purposes of this program, I did not include safety checks or constraints for the account types.

Returning the track for a given track_id is a simple fetch from the tracks library hashmap.

Future tasks

• Implement a getter for current track id maximum from solana storage

• More tests are needed for successful check of validated blocks

• Permission this system so that only a given wallet can control a given track

  Upload track would take another argument specifying the signer, and the track creation would also include a property signed_user. Any following actions performed for the given track_id has to match the signed user attached to the track. Otherwise an error is thrown NotTrackOwner

• Add in additional track metadata like "title" or "album art"

  Currently the Track struct holds one piece of data, the ipfs CID where the track resides. The struct can be extended to add a metadata type, which can include details for Title, album art etc. It's important to add another struct for metadata, instead of adding all the additional data to the struct itself. Keeping those separate will reduce fragile code and also future proof the program, since metadata properties can often change, but the basic Track struct would not.