The robust and trustless solution to sign, manage, store and modify documents. Everything is powered by the next-generation layer-one blockchain NEAR platform.
Blockchain choice justification:
NEAR is not the most popular blockchain at the time of writing but it has a very good foundation to be chosen for a decentralized application that is at least theoretically a mass consumer-focused app. It needs to be cheap and fast, it should be scalable and allow users to easily enter it without having any prior setup and it also should not impact the environment. Compared to ethereum NEAR has it and make it beneficial for such use case.
The problem description:
We all sign or at least acknowledge documents or agreements with various parties. These can be banks, real-estate agents and landlords. The same is true for companies that do endeavors formalized by means of agreements with consumers and other businesses
A single agreement that bounds two parties can have several revisions issued and thus management (i.e storing, signing, issuing) of this all is complex.
There are more and more such solutions t reduce the friction of document management but at the time of writing, none of these is based on web3. That is why NEAR Document Cloud is yet another solution to this problem but this time there is decentralization involved.
User Interface
The UI layer is currently at the wireframing stage. Generally, my personal opinion is that any UI is infinitely better than no UI even for means of communication among technical guys. It automatically makes everyone on the same page and clearly understand the idea.
To read more about designing user interfaces specifically for web3 click here
Let's discuss the NEAR document cloud's most important frames and treat it as the best explanation of the whole project's purpose
Listing agreements
Here we show all agreements either issued by or issued for the logged-in user. This is a kind of a welcome page where the user can immediately see any actions to be performed i.e sign a newly issued agreement before some due date.
On the agreements list we also can see a clear distinction between agreements issued by me and those issued for me (where I am supposed to sign)
Issuing new agreement
Any user can add an agreement. Adding agreement requires input at least ipfs link to the initial document version and intended signer. All remaining details are a matter of potential extension and decision on where to store these (on-chain vs off-chain).
Signing agreements
Users can sign the agreement only if it has been issued with explicit indication he/she is the intended signer. Trying to sign an agreement that has not been issued for acting user will throw (reject tx).
In the image above we can see the Agreement with the credit cart operator not signed because it has been updated - the issuer has added revision two and to formally be in force this agreement needs to be signed again. This can be easily achieved by clicking the sign with the wallet button and acknowledging the tx.
Adding new revision
User can only add revision for those agreements he/she has issued. Trying to add a revision to an agreement issued by someone else will result in transaction rejection.
Adding new revisions could potentially be achieved on a separate screen and require just entering ipfs link to a new document. All other details of the agreement like previous links, signing history, or other details should be read-only at this stage.
Adding a new revision sets the whole agreement in isSigned : false the state, no matter if it has been already signed or not. Conditions have changed and the agreement can not be automatically in force/signed without the signer explicitly signing it again.