Pyr

Pyr’s goal is to solve the problem of where to store digital content after it has been published to be retrieved by the customers. Setting up an automated registry of content and a purchasing mechanism has been possible for a while but the solutions for a distributed content hosting layer are just now maturing. This problem has traditionally been solved by the role of publishers or services like Spotify and iTunes for a cut of the sales or advertising revenue. There may even be another middle man with the case of the music industry where the music label will also take a cut. These companies do also provide some amount of marketing by hyping up the content, but now that distributed technologies are emerging to take over the hosting and distribution tasks, creator’s should be able to reclaim more of their cut and then be able to license out royalties per sale on their terms. I wanted to build a project I could hand to my friends and they can monetize their digital work without ever having to talk to a middle-man or the customer.

Technologies used to build Pyr include the ERC-721 NFT standard, Fleek’s tool suite, and LibP2P. When approaching Pyr as a creator the first tool used is Fleek’s Space Daemon which after accepting all necessary information adds the content to a unique bucket. By default Fleek makes this an encrypted bucket. Once the data from the bucket has been returned the publish function is called in the Pyr contract to create an entirely new ERC-721 contract owned by the creator; Pyr holds no admin control whatsoever over that contract. From there the creator can monitor stats of that content such as total sales or retrieve it from Fleek if the creator deletes it from their local machine. As a consumer you would first interact with the Pyr contract to browse all content published through it, as events are emitted for each new piece of content, then more metadata can be pulled from each individual contract. After purchasing the content, having a balanceOf with that contract greater than 0, using PubSub the consumer’s client publishes a message to the bucket metadata in the contract. That messages contains a signed proof it’s from an Ethereum address that does own at least one token with a lifespan of 20 blocks before the signature expires. Once that message is received by a peer subscribed to that content, anyone who has purchased the content and already retrieved it or the original creator, they verify the sender’s ownership of the content and then responds with the necessary info for the new consumer to join the bucket, the missing piece being the encryption key.