I recently came into an exciting opportunity regarding the Aztec Protocol, an Ethereum Layer 2 scaling solution that offers private-by-default transactions through the application of zero knowledge. Since I learned how to code, privacy applications within the distributed systems space has been what I want to focus on, so suffice to say I have been extremely motivated working on the application. In the pursuit of creating the absolute best project I can to have a chance at this job, I decided to write about the process and the decisions I made in building the end result. I present to the reader the “Airdrop Bazaar”, a distributed, PGP-encrypted file-sharing application built with an ownership and blockchain component tied in through the use of smart contracts built and deployed onto Polygon, another Ethereum Layer 2 solution.
My first thought when I discovered this opportunity was remembering a random tweet I had seen from an FTX dev who sent their initial cover letter as an NFT airdropped over the Solana network. This inspired me to build an application around the problem of how to stand out in the application process and display my skills in a novel way.
My thought following this was how to incorporate all of these pieces. Here I am, applying to a Fullstack Engineer position at a privacy-focused Ethereum L2 protocol. I needed to figure out a plan for a focused application that tied together privacy, web3 and fullstack development, and implement pieces of the general architecture of distributed systems along with a significant “wow” factor that would suitably convey my software development ability. Not only that, it had to incorporate some of the classic interview steps in a novel way, such as sending cover letters and resumes over in the form of an NFT. Not too much to shoulder, right?
I had a lot of pieces swirling around. The initial idea was to create a way of anonymously owning NFTs by using the Aztec contracts on Ethereum to connect with the Polygon network, due to its low cost and ease of use. I didn’t love this idea because it doesn’t make sense to do this, for a few reasons. My first argument against this idea is that people buy NFTS so that they can publicly brag that they own them. A lot of the hype around this technology is for the purpose of “clout”, a term for one’s level of influence and standing within a community. My second thought was that this wouldn’t make too much financial sense; I would still have to use 3 different networks and airdropping something over such an application wouldn’t be cost efficient. Another argument is that this project wouldn’t withstand the “future” test; I’m positive that native zero knowledge NFT solutions are being built as I write this, and wiring these 3 networks together seems pretty janky, to put it plainly. The final argument that caused me to look in a different direction was that this would simply take too much time. Time is an important factor in this situation, and I only had about 2 weeks to built a project from inception to presentation.
Thus I settled on starting off with the base of a simple Airdrop frontend and contract that could be deployed at very low cost on Polygon. I knew that I could create this and build from there in a relatively short time period and in a very high-quality way, which seemed ideal. From there, my mind went to the thought of encryption. It originally came from the thought that I don’t want my application materials, such as my resume and my cover letter, to be public. So I decided to add an option to the proof of concept that the user could upload their items to IFPS with PGP, which uses asymmetric encryption to encode material in a way such that only the recipient with the private key of the public key that the sender encoded the material with could decrypt it. This made a lot of sense to me, especially since the platform was meant to have the core functionality of user-to-user file sharing, not necessarily user-to-many.
Hence I decided on “Airdrop Bazaar”, named for its airdrop functionality, which combines sharing and ownership capabilities, along with the term “bazaar”, which I decided upon simply because the term “marketplace” didn’t apply. The term “bazaar” seemed fitting also because it personally invokes feelings of a new frontier, where the best products win. I felt that applied to this idea, because the novel tech stack I planned on using in addition to the blockchain space are very much at the cutting edge.
So there I had it. Then it was time to start building.
The first piece of the stack that I wanted to focus on was the smart contract. I knew it would be a relatively simple contract, as all it would be doing would be to facilitate a relatively simple NFT collection. After doing some research and building out the initial contract, I remembered the existence of the Foundry tool, which is a Solidity unit testing framework built in Rust. It seemed very appealing because the unit tests were also written in Solidity, compared to the norm of writing tests in Javascript with Hardhat. I remembered finding somewhere in my research that a significant advantage to this approach was the lack of “context switching”, where the process of working on something suffers because of the requirement of switching between environments. This applies to any period of attempted focus; just going to check your phone briefly would be considered a “context switch” and disrupts focus. Javascript and Solidity are indeed extremely different environments, and I did feel during development the pros to this approach. It felt very natural to tweak the contract and then change the tests without leaving the Solidity environment, and I’m very happy that I made this decision. Not only was the lack of context switching great, but Foundry is also written in Rust, and is extremely fast when running the tests. The final advantage when I was getting familiar with this framework was how easy it was to also deploy the contracts that I built, and I will definitely be coming back to Foundry when I find myself working in the EVM again.
After cementing the smart contract, the next step was to build out the frontend. I wasn’t sure where to start, and knew that Nader, a phenomenal DevRel engineer at Edge and Node, had uploaded a thorough tutorial building out an NFT frontend and related smart contract suite deployed on Polygon. It was perfect. After going through the tutorial, which used Next.js as the frontend framework, I began customizing it for my application. However, I personally prefer Vue to React, and was conflicted as to whether I should call it a rewrite and start over with a Vue 3 base. I have grown very close to Vue in my professional work over the past year, and love its slot system, as well as Vue’s developer experience building forms and the separation between Javascript, HTML, and CSS that each .vue file delegates. I wasn’t sure whether to switch because React has the best web3 integration, but after looking into the Vue web3 support and how I could work around some of the less-supported pieces, I went all in and got started on the rewrite. I am very happy I made this decision, but it did not come without a fair share of difficult bugs to work through.
The source of many of the bugs ended up not being from my choice of Vue, but rather from my choice of Vite as the bundler, which is one of, if not the fastest Javascript bundler. Due to the streamlined nature of Vite, I had issues with incorporating various pieces of the stack, but was able to work through each bug. One notable bug was not being able to use the ipfs-http-client package, which failed because Vite does not bundle packages with the same builtins as Webpack. I was able to work around this limit by implementing a simple Javascript http client, and was able to access and upload to my IPFS endpoint with that.
It was a challenge finishing this frontend through and through, but was some of the most enjoyable development I’ve done in a long time. It really required me to flex my coding muscles in a way that I haven’t been able to in my professional day-to-day, and the end result struck me as something truly beautiful. Previous to beginning work on this project, I lacked experience working with low-level data types and data encoding in Javascript, but getting those pieces functional was very enjoyable, and this entire project significantly contributed to my development knowledge and intuition in a large way. It can become easy to get used to a way of doing things, which I have in my professional work, but this project really switched things up. Working on it was inspiring to continue to grind on similar side projects in the future, which I have lacked motivation to complete in the past.
After finishing the MVP, the next step was to polish up the CSS and general feel of the app. This meant adding animations, settling on a unified color scheme, style layout, and font, and building a component library for easily implementing and tweaking the pieces of the app. I got to a point where I was able to call it “finished”, but as it is with these projects, there’s always more to add.
Moving forward, there are a few things on the list to implement that will vastly improve the app as a whole. The first is to figure out how to use the secp256k1 keys each user is required to have in establishing a web3 connection. I explored this option, but Metamask makes it very difficult for apps to access the user’s private key, as it should, and stopped exploration when I realized how much time this would take to solve. It is top priority moving forward because implementing this would allow for private-by-default files, same as Aztec does with transactions on their network. The user would no longer need to keep track of any keys other than their wallet credentials, and could simply click through the UI, instead of having to upload the key files required to encrypt content. Not only would this remove the necessity of other key files and enable encryption by default, but it would also improve the UX by removing many pieces of the form that are currently necessary.
The second item on the agenda would be to include the use of Web Assembly. Since learning Rust, I’ve long had an interest in WASM because of its incredible speed and what it enables within the browser environment. With WASM, I will implement absurd-sql, an extremely fast browser database. While the necessity of keeping track of key files would be mitigated with the feature described earlier, I will still keep the option to use said files, and this database would be a perfect way to store profiles that users commonly reference, and would also contribute to a better UX. Web Assembly would also enable faster manipulation of lower-level data types. Instead of using openpgp.js, I will use the Rust openpgp implementation, compiled to Web Assembly, and the process of converting files to a Uint8Array would also be done with this technology. Most importantly, I want to learn how to use WASM, and this would accomplish that in a fascinating way that would benefit Airdrop Bazaar.
The final series of improvements that I have on the horizon would be to implement a store for the app, so that data is loaded and injected into components more efficiently, and to continue to polish the app. Typescript is also another love of mine, and I implemented it into the app is it stands right now, but the types could definitely be improved, starting by preventing the use of the “any” keyword. I also really enjoy making type definitions as specific as possible, and that could be taken a long way, especially with how it’s possible to generate Typescript wrappers for WASM code compiled from Rust. The polishing never really ends, in my opinion. That’s just part of being a software developer; there’s always things to improve upon in any project.
There are a lot of reasons this project appealed to me. Not only are there so many interesting things to improve, it also has a serious real world use case. Fundamentally, this project enables file sharing in a completely private way that cannot be prevented by centralized entities. Airdrop Bazaar could be used to share important legal documents, real estate documents, sensitive music, media, code, or anything that cannot be leaked. It could be used to create entire collections of private NFTS, and different zero-knowledge components could also be integrated to lead to even more privacy and anonymity. The application can be taken in many different directions, and that is the sort of idea that has the strongest hold on me. I will continue to iterate on Airdrop Bazaar, and look forward to watching it grow over the coming months.
I had a great time building this application. I hope the reader finds it as compelling and interesting as I did. It has been an extremely stressful last few weeks, as it has been difficult finding time to work on this as well as my professional work, but making it happen has been fundamentally rewarding and meaningful. I’m really happy with the result, and hope the reader checks it out! The project is currently hosted using Fleek, a decentralized hosting service, and it be found through the link below.
https://plain-haze-8016.on.fleek.co/
The repository can be found below, and feel free to contribute, open issues, or fork it.
https://github.com/adunne09/airdrop
Thanks for reading!
Alex