Documents
Last updated
Last updated
For technical documentation, see DocumentRegistry
Accounts in Mezzanine can store documents via Mezzanine's document registry. The document registry stores versioned documents on-chain for all Mezzanine departments and boards: it is not redeployed each time that a Mezzanine instance is created.
Documents, similar to NFTs, store a URI that points to a decentralized storage network, such as Arweave or IPFS. Files stored on these types of networks are immutable and cannot be changed. For example, let's look at the smart contract of Bored Ape Yacht Club, a popular NFT collection. Calling the tokenURI( ) function with the token id, 0, returns the following URI, which points to IPFS: ipfs://QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/0.
If you go to this link, you will find the JSON file that contains the BAYC #0’s metadata:
These attributes are easily verifiable on OpenSea:
Files stored on IPFS must have nodes that pin them to guarantee that the file is rapidly queryable. Some of the most common providers for pinning are Filecoin and Pinata. Other decentralized storage networks exist that have similar functionality, such as Arweave. However, the most widely used decentralized storage network is IPFS.
Read the Pinata documentation to learn more about IPFS
The immutable storage of documents in Mezzanine will follow a similar pattern. In particular, documents store four different variables, one of which is determined by a Mezzanine user:
A document name
A document URI, which points to a file on a decentralized storage network
A version
The last time that the document was modified
The document name is the only variable determined by the user with one exception: each organization in Mezzanine will initially have an incorporation document that can only be modified by the organization's board of directors. The initial version of this document will always follow the same syntax. For company Foo, its incorporation document would aptly be named Foo Incorporation Document. Document names and URIs can always be updated by their owner, which in turn creates a new version of a document.
All documents in Mezzanine are versioned, and old versions will always be queryable and immutably stored. Documents are always versioned at zero, and each time that a document is updated, this version is incremented. For example, if Foo updates its initial incorporation document, the new version of this document will be one. Any versioned document can be updated such that the document's name and URI can be changed at the discretion of the owner.
A document URI will be provided and abstracted for all departments, modules, and boards that use Mezzanine. The Mezzanine team will work with a provider to make these documents easily queryable at all times. However, the provider and decentralized storage network have yet to be determined.
At the time of writing, documents in Mezzanine are not access-controlled. It has yet to be decided whether or not access-controlled documents will be included in the initial version of Mezzanine. The team is actively considering implementing access control via Lit Protocol. The enforcement of access control would occur off-chain via clever cryptography and would not change the above methodology for storing documents.
Certain functionality within Mezzanine is associated with the creation of a new document in the Document Registry. Here are some examples:
Assets in an organization's capital stack are associated with a document
An employment contract is associated with a document
A bill or invoice is associated with a document
The addition of these documents is optional. These actions will simply create a blank document in the document registry with no name or URI if a document is not provided. For example, if an organization hires someone but decides not to provide an on-chain document, a blank document will be added to the document registry. This blank document can then be updated retroactively if desired, such that it contains a name and URI.
Again, the above actions create associated documents. Specifically, all documents in the document registry are associated with an index. These indexes are then stored in correspondence with the above actions. For example, an asset in the capital stack knows its corresponding document's index. This index can then be used to query the Document Registry to clarify the intended functionality of the asset.
