The problem Pixie solves

The problem that Pixie addresses and solves is how files and media are currently shared and consumed in Web3. The most ideal and natural thing that comes to our mind when we talk about storing and retrieving files is to store your files over IPFS and use the public hash to access them, and anybody that has the file hash can access them. This is fine and serves its purpose, but what if we want to restrict file access based on certain conditions or parameters, or better yet, manage or monetise access to an IPFS-stored file or media?

Challenges I ran into

The list is quite long, but I had the most fun tackling these challenges one at a time.

• The key thing in my project was to store encrypted data over IPFS rather than uploading the media file directly, and later decrypt and serve them the media only if they qualify for it. I started by writing my own encryption and decryption mechanisms. My approach was to simply convert files to strings (included 2-3 intermediary steps) and then later encrypt these strings with a simple algorithm like AES via a key and store that key as an environment variable (not the best approach but was fine to begin with). Then I came across Lighthouse which offers a solution to store encrypted files and provide tools to share access. From there, I decided to leverage Lighthouse and build on top of it.
• I started off by storing all the user and file data on chain, but I knew this might not be the best way to execute a project like this. I discovered Polybase that offers a web2 db-like solution (and much more things related to auth and permissions) and decided to use it for storing most of the data off chain.
• I wanted to use NFTs as access tokens to the files and give users the ease of minting file-specific NFTs from the application itself. I had implemented ERC721 before, but I did an ERC1155 implementation this time as it was perfect in a situation like mine where I needed to have multiple tokens of one type and batch mint them with ease.