Inspiration
Imagine you are a college student who wants to use Photoshop for a short project but unfortunately Adobe recently ended its program for free educational access. Or maybe you are a researcher digging through the internet for papers relevant to your work but most of them are pay-gated with monthly/annual-based pricing above what you can pay out. Or perhaps you simply want to watch the latest hit TV series but don’t want to pay for a while Netflix subscription.
What it does
KeyStream offers a way for users to access these subscription-gated resources at a discounted price since they do pay for only the time they actively use the service. It additionally allows those who do own paid subscriptions to turn them into assets that earn passive income while they don’t actively need to use them.
How it Works
KeyStream consists of two components: the website and the browser extension. As a lender, you first use the extension to retrieve your authentication credentials. You then post it onto the website, pick a request to lend your credentials to, and click lend. After these simple steps, you automatically earn KeyStream Credits from your customer, which can be converted into TRX in your wallet through withdrawal on the website. As a renter, you first use the website to convert your TRX into KeyStream Credits. You then open the extension and click “Rent Login” and wait for a lender to fulfill that request. Once the request is fulfilled, you can go to Netflix, refresh the website, and be logged in. Once you are done renting, you click “End rental” and will be logged out of Netflix.
How it was Built
Our project has three core subparts:
- Smart contracts
- Live Website (keystream.xyz)
- Browser Extension (unable to get through approval process for the extensions store in the short duration of the hackathon)
Starting with the browser extension, this was how we were able to read and inject browser authentication tokens. Otherwise, these tokens, which are stored in cookies that are not visible to normal javascript, would not be reachable. We used Google’s extension development documentation (https://developer.chrome.com/docs/extensions/mv3/getstarted/) and this was actually our first time developing a Chrome extension! Not only did we have to learn how to make a Chrome extension, we had to figure out how to also make it work with cryptography libraries and web3. In particular, the way web3 is normally injected is not visible through simple means to the browser extension. After lots of experimentation, we were able to land on something that gave a smooth experience, but if we had more time, we could definitely have automated more of the user experience.
The live website is built with a standard Next.js + Tailwind stack. Building the interaction between the smart contracts and live site heavily relied upon Tron’s custom ecosystem of tools and development kits. For example, we integrated with TronWeb (https://github.com/tronprotocol/tronweb), used TronBox (https://github.com/tronprotocol/tronbox) to develop our smart contracts, and learned to use their custom deployment machinery and local testing setups through Docker (https://github.com/TRON-US/docker-tron-quickstart). It took a while to get used to the unique setup of TronBox (ex. figuring out how migrations worked and learning to translate between the different addressing systems). However, once we got a hang of it, it was nice to be able to quickly deploy and test things on both local networks and test nets.
NOTE: We actually discovered a but in TronWeb involving missing dependencies when it comes to newer React stacks. We submitted a pull request to the main repository that includes this change (https://github.com/tronprotocol/tronweb/pull/311) in hopes of removing this issue for other developers in the future.
The smart contracts also used Openzeppelin’s suite of secure and audited contracts, which we were lucky enough to be able to include due to Tron’s ability to use Solidity as a language.
Finally, it is worth noting that the lower transaction costs on Tron were very critical to the success of our project. First of all, the transactions we make are targeting small-value transfers. It would not be possible for these to each have high gas costs attached. Of course, Tron offers low gas costs already. But in fact, we experimented with how we could wrap as much of the functionality as possible in our contracts with TRC-20 and TRC-712 primitives so that we could leverage their native gas-free transfer functionality. We were able to get partially there but weren’t able to make the full transition in time for the submission deadline. In addition to saving general gas costs, pushing large encrypted byte strings to the blockchain is in particular very expensive. Being able to save cost here through the above methods but also using staking allowed us to be able to barely squeeze through the size of our data.
Our contracts are fully deployed on Tron Nile Testnet and integrated with a live site at keystream.xyz
What's next for KeyStream
Here are some next steps in the development process for KeyStream
- Streamlining Rental Process (removing the need for users to interact with credentials directly)
- Creating markets for rental services (allow people to bid for services rather than pay a set price)
- Deploying on Mainnet
- Extending to Other Subscription Services
Log in or sign up for Devpost to join the conversation.