The problem NFsTreamer solves

Existing centralized content platforms such as Twitch and Youtube take a cut from the creator’s revenue, which significantly hurts their earnings. We plan on bypassing the middleman and giving creators the freedom to generate their own revenue from their audience. We use collectible NFTs made by the creators, which the fans purchase and show as emotes in the creator’s twitch streams, thereby giving a genuine use case for NFTs apart from just a store of value in marketplaces.

We also eliminate the entry barrier of high gas fees, by giving the option of lazy minting to creators. So, with this creators can instantly create NFT vouchers for their creations without worrying about gas fees. Then when an actual user wants to buy their NFT, they can pay the gas fees and the listing price to acquire it.

Once you purchase your NFTs you can display in the creator’s Twitch stream by using it as emotes. This provides a proper use case for NFTs, where your NFTs are displayed on chat and the entire community can see it, instead of just relegating them as a store of value.

Challenges I ran into

1. Lazy minting (dealing with counterfeit vouchers)
   We wanted to make the platform openly accessible to creators whether they can afford to or not. Essentially getting a space where they can upload their content for free and not pay the gas fees (get the end user to pay for the gas fees)
   In order to do this we deploy the contract with the wallet address of the creator and set it as the minter role in the smart contract as shown below.

constructor(address payable minter)
ERC721("LazyNFT", "LAZ")
EIP712("LazyNFT-Voucher", "1") {
_setupRole(MINTER_ROLE, minter);
}

Now we went ahead with this as the structure for each nft voucher to be signed

struct NFTVoucher {
uint256 tokenId;
uint256 minPrice;
string uri;
string collection;
}

The creator has to visit the marketplace and sign these vouchers(if someone else apart from the creator registered with the smart contract tries signing a voucher the fans won’t be able to redeem it hence dealing with the issue of verifying the right person getting paid for the token)
This is done by using the lib/index.js file where we make use of EIP-712 to get a typed signature which can be used to verify the authenticity of the voucher being generated by the creator. Once the creator has generated these vouchers it is stored on a centralised mongoDB server and listed as redeemable vouchers. The mongoDB schema consists of a signature and the voucher information (which in turn contains all the fields that are declared in the smart contract).
When a redeem request is made to the contract the signature is verified to be the same as the voucher details
2)Twitch extension ( dealing with the ssl certificate issues)
Twitch extensions are essentially iframes that display a website embedded into their own website. This implies that over http we couldn’t do development. To work around this issue we used ssl certificates from mkcert and ngrok to serve the app over https.