Agreements on Ipfs
This page explains how Ricardian contracts are used and accepted.
Giving rights to your users
In the previous guide I explained how to create and deploy a Ricardian Contract.
In the following guide, I I will explain the simple process of accepting this agreement and explain how they work on Ipfs.
What is Ipfs?
The Interplanetary file system or Ipfs is a distributed storage network that allows storing and accessing data in a decentralized way.
The content on Ipfs is accessable from anywhere as long as a single computer is hosting it. The identifiers attached to the link are called a CID, content identifier and they are unique for each data uploaded.
So each Ricardian contract is identified and accessed using the Ipfs content identifier.
After you have deployed a Ricardian Contract, you will have a link with a CID on your clipboard and this is what you should share with your users who need to accept it. This way you can give rights and authorization to your users to perform certain actions or access features.
Ipfs is not persistent. You need to pin the files. You can permapin the contracts to the Arweave blockweave to store the content forever.
Accepting an agreement
In order to accept the agreement, the users simply need to navigate to the page. If the contract is not available in all countries they will be prompted to add their location which uses the browser geolocation. Permission must be granted in the browser to proceed.
You will learn more about which countries are blocked from access in the "Geo-blocking and configuration" guide.
Contract details
There are a couple of extra details displayed about the contract on the page.
Created date is simply the date the contract was created.
Expiry date is the date after which the contract cannot be accepted anymore.
The network row displays the number of the network id, some networks have a button instead which when pressed will configure metamask to the selected network.
The Issue field is the address of the contract creator.
Clicking accept
When clicking accept, the user is prompted to sign the agreement with metamask, just the same as when deploying the same hash is calculated.
After the terms are accepted the user receives a proof, which is a similar contract, deployed on Ipfs.
The proof has the following details, other then the complete content of the agreement:
Signed on, which is the date the contract was signed on.
Network, show which network was used
Issuer, which is the address that created the ricardian contract
Participant is the address of the signer
Parent, which is a link to the agreement that was just accepted.
Collecting the proofs
The signatures of the issuer and the signer are both saved inside the deployed pages and can be verified and processed. This brings interesting opportunities for server side processing signatures and performing actions in place of the signer.
The signatures are domain specific so they cannot be used on-chain without the correct domain, they use the EIP712 standard.
You can use the redirect feature to collect the Ipfs CIDs on your website.
Check out the Verify Signed Contract dependency to implement Ricardian Contract verification and parsing easily.
Last updated