Copyright & Security

In the render hive, all files related to a work are always the intellectual property of the artist – no matter who or how many other nodes rendered it. However, on a distributed network, where your Blender files and rendered artwork is send between an anonymous group of people, it needs to be discussed how copyright claims of artists can be supported.

How can you proof that you are the creator and owner of the art, if you send your Blender file to an unknown person that could do anything with it? Unfortunately, it is nearly impossible to prevent that people do that just in the same way that it is impossible to prevent that people download a picture on the internet and re-publish it under their name.

What the Renderhive project can do, however, is to empower all users with tools that give them the freedom and proofs to take legal actions against bad actors. To do this, we use the immutability and security of Hedera's distributed ledger technologies in combination with the content verification mechanisms of the IPFS. Together, they provide you with cryptographically verifiable, immutable proofs of ownership of each file that you send to the render hive. These proofs are independent from the Renderhive project and, thus, remain verifiably via Hedera’s distributed ledger even if the Renderhive project would seize to exist. These proofs rely on the following concepts:

• Content identifiers (CID). Whenever a render request is submitted by a client to the network, the Blender file of that request will be stored on the IPFS. Instead of folder names and links, content on the IPFS is addressed by so-called content identifiers (CID), which are labels that point to a user's data. This CID is a unique, cryptographically calculated representation of a file or folder. That means, that a CID of a Blender file will always be unique to this exact file in its current state. If the file is modified in the slightest way (e.g., by undeleting the default cube), it will result in a new CID. The CID of each Blender file will be logged on the Hedera Hashgraph along with a timestamp so that an artist can always verify at what date and time a file was sent to the network for rendering.

• Render contracts. Client and render nodes can choose from a set of predefined terms of service (e.g., non-disclosure terms, no pornographic or violoent content, etc.) under which they operate and expect other nodes to operate as well. Renderhive will only match those render requests and offers, which agree on the same set of terms. After matching offers and requests, a render contract document is automatically created including all the terms, prices, node identifiers, and the CIDs of the artist’s files. The document is stored on the IPFS and its CID is logged on the Hedera network. That way, both client and render nodes can always proof that the counter party accepted the specific terms.

• Encryption. The IPFS is a public network without native encryption. Everyone that knows a CID can download the related file. If desired by the client, Renderhive will encrypt files that are exchanged via IPFS between client and render nodes with a symmetric key (a password) that is only exchanged between the client and render nodes that signed the render contract. While technically everyone can download the encrypted files from the IPFS, no one can open or read it without knowledge of the aforementioned symmetric key.