Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Understanding the context and construction of DID-Linked Resources
Our objective in building DID-Linked Resources on cheqd is to improve the way resources are stored, referenced and retrieved for our partners and the broader SSI community, in line with the existing W3C DID Core standard.
📝 Architecture Decision Record for On-ledger Resources
Full discussion and details on the design of cheqd's on-ledger resources are available in its ADR
Create a DID-Linked Resource associated with a cheqd DID over REST API
Using the /resource/create API, users are able to create custom DID-Linked Resources, including:
Schemas
Credential Definitions
Trust Registries
Status Lists
Logos associated with DIDs
Governance files
Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:
Before you can create a DID-Linked Resource, you need to create a "parent" DID which is used to link the Resource on-ledger. Use the API in the page below to create a DID:
DID-Linked Resources can be any type of file or content that is below ~45kb in size.
For the purpose of an example, lets use an AnonCreds schema (JSON file) as the resource:
Save this file locally and call it something like resource.json.
Prepare a file with resource and encode it into base64, base64url or hex. On Unix systems, you can use the following command input:
Expected output:
Resources are grouped by having identical names and types. This means if you want to create a new version of the same Resource, you will need to specify the same name and type in the following request.
Set up your account
Set up your account with cheqd Studio and log in to start using the APIs.
Create an Issuer DID
Create a W3C conformant DID on cheqd using the did:cheqd DID Method.
Learn more about DID-Linked Resources
Understand the context and technical composition of cheqd's DID-Linked Resources.
This endpoint creates a DID-Linked Resource. As input, it can take the DID identifier and the resource parameters via a form, or the fully-assembled resource itself.
/resource/create/{did}
DID identifier to link the resource to.
Encoded string containing the data to be stored in the DID-Linked Resource.
Encoding format used to encode the data.
base64url, base64, hexName of DID-Linked Resource.
Type of DID-Linked Resource. This is NOT the same as the media type, which is calculated automatically ledger-side.
Optional field to assign a set of alternative URIs where the DID-Linked Resource can be fetched from.
Optional field to assign a human-readable version in the DID-Linked Resource.
List of key references (publicKeys) which will be used for signing the message. The should be in hexadecimal format and placed in the wallet of current user.
Once created, issuers of Verifiable Credentials may want to reference resources within the body of issued Verifiable Credentials.
As mentioned in the section on Context for Resources, this may be useful for referencing:
Schemas;
Status lists;
Trust registries;
Visual Representations of Verifiable Credentials;
Documents; or
Logos
within the contents of Verifiable Credentials themselves.
Below is an example of a Verifiable Credential for an IIW event ticket which includes a fully qualified DID URL for the schema and logo, using resources on-ledger.
The schema in the above Credential dereferences to the following data:
Search and query for DID-Linked Resources
The /resource/search API allows users to search for specific entries of a Resource on the cheqd Network. For example, if there are multiple Resources associated with the same DID, the search functionality allows applications to make requests only to a specified Resource.
This endpoint returns the DID-Linked Resource for a given DID identifier and resource identifier.
/resource/search/{did}
DID identifier
did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0Fetch a DID-Linked Resource by Resource ID unique identifier. Since this is a unique identifier, other Resource query parameters are not required. See <a href="https://docs.cheqd.io/identity/credential-service/did-linked-resources/understanding-dlrs/technical-composition">DID-Linked Resources</a> for more details.
3ccde6ba-6ba5-56f2-9f4f-8825561a9860Filter a DID-Linked Resource query by Resource Name. See <a href="https://docs.cheqd.io/identity/credential-service/did-linked-resources/understanding-dlrs/technical-composition">DID-Linked Resources</a> for more details.
cheqd-issuer-logoFilter a DID-Linked Resource query by Resource Type. See <a href="https://docs.cheqd.io/identity/credential-service/did-linked-resources/understanding-dlrs/technical-composition">DID-Linked Resources</a> for more details.
CredentialArtworkFilter a DID-Linked Resource query by Resource Version, which is an optional free-text field used by issuers (e.g., "v1", "Final Version", "1st January 1970" etc). See <a href="https://docs.cheqd.io/identity/credential-service/did-linked-resources/understanding-dlrs/technical-composition">DID-Linked Resources</a> for more details.
v1Filter a DID-Linked Resource query which returns the closest version of the Resource at or before specified time. See <a href="https://docs.cheqd.io/identity/credential-service/did-linked-resources/understanding-dlrs/technical-composition">DID-Linked Resources</a> for more details.
1970-01-01T00:00:00ZRequest integrity check against a given DID-Linked Resource by providing a SHA-256 checksum hash. See <a href="https://docs.cheqd.io/identity/credential-service/did-linked-resources/understanding-dlrs/technical-composition">DID-Linked Resources</a> for more details.
dc64474d062ed750a66bad58cb609928de55ed0d81defd231a4a4bf97358e9edReturn only metadata of DID-Linked Resource instead of actual DID-Linked Resource. Mutually exclusive with some of the other parameters.
"Resources" are identified with a did:cheqd Decentralized Identifier with a Universally Unique Identifier (UUID) that acts as a permanently-accessible link to fetch the resources from the cheqd ledger. We refer to this as the "resource ID".
Using UUIDs, we can have a high level of confidence that no two identical resource IDs will ever be created. This is important for ensuring the integrity and uniqueness of each individual resource.
Figure 1: DID-linked Resource DID URL path
This will be explained further in the section on DID URL dereferencing to fetch a resource.
Resources are organised into groups called "Collections". Each DID may have an associated Collection, and the Collection ID is derived from the unique identifier of the DID.
Collections can store any type of Resource, but for the purpose of this documentation we will focus on the use case where the Collection is used for storing a set of schemas.
The most important concept used in this design is that each on-ledger Collection is identified using a DID and is described using a DID Document.
The DID Document acts as metadata, providing information about the Collection, such as who is able to update it, when it was created and what are the latest and deprecated versions of Resources within the Collection.
For example, the following DID:
did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d
will derive the Collection ID: 1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d
Figure 2: Relationship between a DID and Resource Collection
A Collection is created using a createResource transaction, and specifying the Collection ID as the same identifier as that of the parent DID.
Note that the Collection ID may take the syntactical form of a 'Hyperledger Indy' DID identifier or may be a Universally Unique Identifier (UUID). This is described in the cheqd DID method.
To create a "DID-Linked Resource", you must already have created a 'parent' DID, from which the Collection ID can be derived. When you carry out the createResource transaction, you must:
Generate a new, unique UUID for the Resources
Specify the same Collection ID as the unique identifier of the parent DID
Sign the createResource transaction with the Verification Method keys of the parent DID.
This is shown in the diagram below:
Figure 3: Relationship between a DID and DID-linked Resource
Example of createResource transaction using Veramo SDK:
Multiple, DID-Linked Resources can be stored in a Collection, for example, this could be different versions of the same Resource over a period of time or semantically-linked resources. This enables unique resources to be stored directly on-ledger and be retrievable through DID resolution and dereferencing.
Once you have created a resource, the DID Document will automatically reference the resource and the collection within the didDocumentMetadata in a newly defined section called linkedResourceMetadata.
This relationship is shown in the diagram below:
Figure 4: DID Document metadata with DID-linked Resource metadata
For simplicity, we will focus on the use case where a Resource is a schema. The same logic used in fetching schemas from the ledger can be applied to any of the aforementioned types of Resources.
The syntax of a Resource metadata for a single schema is as follows:
Any valid IANA Media Type (colloquially known as "file type") is allowed as an on-ledger Resource. The only restriction is that the Resource should fit within a block, which de-facto restricts it to ~190KB to fit within the ~200KB block limit. Any files larger than this are recommended to be stored and linked via long-term immutable file discovery mechanisms such as IPFS.
A Golang library is used to derive and set media type based on the file extension of provided resource file. This makes it much simpler to maintain, since there is no list of file types that the cheqd ledger needs to gatekeep.
The following list defines which specific parameters a resource request format may contain:
resourceUri
resourceCollectionId
A string that conforms to a cheqd-supported unique identifier format. For example a UUID: 46e2af9a-2ea0-4815-999d-730a6778227c
resourceId
A string that uniquely identifies the resource, cheqd uses UUIDs. For example a UUID: 0f964a80-5d18-4867-83e3-b47f5a756f02
resourceName
A string that uniquelt names and identifies a resource. This property, along with the resourceType below, can be used to track version changes within a resource.
resourceType
A string that identifies the type of resource. This property, along with the resourceName above, can be used to track version changes within a resource. Not to be confused with media type.
resourceVersion
(Optional) A string that identifies the version of resource. This property is provided by the client and can be any value
alsoKnownAs
(Optional) An array that describes alternative URIs for the resource.
The following list defines which specific parameters a resource response format may contain:
resourceUri
resourceCollectionId
A string that conforms to a cheqd-supported unique identifier format. For example a UUID: 46e2af9a-2ea0-4815-999d-730a6778227c
resourceId
A string that uniquely identifies the resource, cheqd uses UUIDs. For example a UUID: 0f964a80-5d18-4867-83e3-b47f5a756f02
resourceName
A string that uniquelt names and identifies a resource. This property, along with the resourceType below, can be used to track version changes within a resource.
resourceType
A string that identifies the type of resource. This property, along with the resourceName above, can be used to track version changes within a resource. Not to be confused with media type.
resourceVersion
(Optional) A string that identifies the version of resource. This property is provided by the client and can be any value
alsoKnownAs
(Optional) An array that describes alternative URIs for the resource.
mediaType
A string that identifies the IANA-media type of the resource.
created
A string that identifies the time the resource was created in XML date-time.
updated
(Optional) A string that identifies the time the resource was updated in XML date-time.
checksum
A string that may be used to prove that the resource has not been tampered.
previousVersionId
(Optional) A string that identifies the previous version of the resource.
nextVersionId
(Optional) A string that identifies the next version of the resource.
Let’s take a look at a fully resolved output response for a DID with a Collection and single associated Resource:
Let’s take a look at a fully resolved output response for a DID with a Collection and multiple associated Resources:
Collections are identified by a Collection ID which is a unique identifier of the linked, parent DID. Within the DID Document Metadata of the Collection DIDDoc, the Linked Resource metadata describes Resources within this Collection:
Note that the Linked Resource output above does not show the actual data / schema attributes when displaying all Resources in this Collection. It only shows Resource metadata.
This logic prevents GetResourceCollection requests returning large quantities of data, which may be stored across multiple Resources within a Collection.
In order to fetch the actual data, it is necessary to query the specific Resource, rather than the entire Collection.
For more information about the particulars of requests and responses, please refer to our ADR on Resources on ledger.
As shown in the examples above, there may be previous and next versions of the Resource ID.
Whenever a Resource is updated, a new UUID must be generated. The new Resource references the older version, so the UUID is effectively a version number.
Importantly, the collectionId, resourceName and the resourceType of the Resource must remain the same.
For example, a Resource with the name PassportSchema must always have the same name and resource type to be considered for previous/next version linking.
This could be used, for example, to find the version active at a particular point in time:
Fetching resources using DID resolvers and DID URLs is hugely desirable. Up until this point, we have shown resources identified using path-based syntax.
However, query-based syntax should also be enabled to allow more granular and specific searches within a particular Collection.
To enable combined resolution/dereferencing behavior, cheqd are defining multiple query-based DID URL parameters to fetch resource or associated metadata. If a DID method specification supports these parameters, and if a DID URL using that method includes the parameter with a valid value, then when a resolver calls the associated VDR using that DID URL, the VDR returns the identified digital resource, not the DID document.
IMPORTANT: DID URL queries should be fully qualified so that they uniquely identify a single resource, or single resource version unless expressly specified.
A string or a map that conforms to the rules of which SHOULD directly lead to a location where the resource can be accessed from. For example: dic:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c/resources/0f964a80-5d18-4867-83e3-b47f5a756f02
A string or a map that conforms to the rules of which SHOULD directly lead to a location where the resource can be accessed from. For example: dic:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c/resources/0f964a80-5d18-4867-83e3-b47f5a756f02
Create digital Resources linked to cheqd DIDs on-ledger
"DID-Linked Resources" are identified with a did:cheqd Decentralized Identifier with a Universally Unique Identifier (UUID) that acts as a permanently-accessible link to fetch the resources from the cheqd ledger. We refer to this as the "resource ID". Through the "resource ID" or a set of DID URL query parameters, applications are able to persistently access a digital resource on the cheqd network.
Below are a list of alternatives for creating cheqd DID-Linked Resources.
Create DID-Linked Resource
Create a custom DID-Linked Resource for a schema, Trust Registry or other persistent data file.
Search DID-Linked Resources
Search and query for existing DID-Linked Resources on cheqd.
Understanding DID-Linked Resources
Detailed guide explaining the context and technical composition of DID-Linked Resources on cheqd.
DID Resolution and DID URL Dereferencing
Architecture decision record explaining the different parameters for fetching DID Document data on cheqd, including DID-Linked Resources.
cheqd Cosmos CLI
Cosmos-native CLI for creating transactions on cheqd. Should be used for testing purposes only.
DID Registrar
Simple setup for building cheqd DIDs into existing applications using REST APIs, building into the Universal Registrar.
Veramo SDK Plugin
The Veramo SDK Plugin is an extension of the Veramo SDK, a JavaScript framework for Trusted Data, adding support for cheqd functionality.
Credo
Credo is an SDK which supports the European Architecture and Reference Framework (ARF) standards as well as AnonCreds with full cheqd support for DIDs.
In self-sovereign identity (SSI) ecosystems, “resources” are often required in tandem with W3C Verifiable Credentials, to provide supporting information or additional context to verifiers receiving Verifiable Presentations.
For example, common types of resources that might be required to issue and validate Verifiable Credentials are:
Schemas;
Status lists;
Trust registries;
Visual Representations of Verifiable Credentials;
Documents; or
Logos
Schemas describe the fields and content types in a credential in a machine-readable format. Prominent examples of this include schema.org, Hyperledger Indy schema objects, etc. You can think of them as a template for what is included in a Verifiable Credential.
Below is an example of a schema.org residential address with full URLs:
This might also take the form of evidence schemes, which describe additional information about the processes used to validate the information presented in a Verifiable Credential in common, machine-readable format.
Prominent examples of this include Schema.org, Hyperledger AnonCreds SCHEMA objects, etc.
Status lists allow recipients of a Verifiable Credential exchange to check the status of a credential for validity. Prominent examples of this include the W3C Status List 2021 specification, Hyperledger AnonCreds Revocation, etc.
Trust registries enable recipients of a Verifiable Credential exchange to check that the Decentralized Identifier of the issuer is listed in a trusted registry. This provides a level of assurance in the authenticity of the issuer. Examples of Trust Registries include the ToIP Trust Registry Specification, EBSI Trust Registry API, etc.
Although Verifiable Credentials can be exchanged digitally, in practice most identity wallets want to present “human-friendly” representations. Examples of this include the Overlays Capture Architecture (OCA) specification, Apple Wallet PassKit (".pkpass"), Google Wallet Pass, etc. A resource, using something like Overlay Capture Architecture (OCA) may enable a credential representation to be shown according to the brand guidelines of the issuer, internationalisation (“i18n”) translations, etc.
Figure 1: Overlays Capture Architecture Specification Version 1.0.0
Such visual representations can also be used to quickly communicate information visually during identity exchanges, such as airline mobile boarding passes.
Figure 2: Mobile boarding passes in Apple Wallet showing different visual styles (source: British Airways media centre)
In the example above from British Airways, the pass at the front is for a “Gold” loyalty status member, whereas the pass at the back is for a “standard” loyalty status member. This information can be represented in a Verifiable Credential, of course, but the example here uses the Apple Wallet / Google Wallet formats to overlay a richer display.
While it’s useful to have digital credentials that can be verified cryptographically, the reality is that there are often occasions when a quick “visual check” is done instead. For example, when at an airport, an airline staff member might visually check a mobile boarding pass to direct people to the correct queue they need to join. The mobile boarding pass does get scanned at points like check-in, security, boarding etc., to digitally read the information, other scenarios where this is not done are equally valid. However, most Verifiable Credential formats do not explicitly provide such “human-friendly” forms of showing the data held in a credential.
More broadly, there are other types of resources that might be relevant for companies beyond SSI vendors, that want a way to represent information about themselves in an immutable and trustworthy way.
Many companies require documentation such as Privacy Policies, Data Protection Policies or Terms of Use to be made publicly available. Moreover, Trust over IP (ToIP) recommends making Governance Frameworks available through DID URLs, which would typically be a text file, a Markdown file, PDF etc.
Companies may want to provide authorised image logos to display across different websites, exchanges or block explorers. Examples of this include key-publishing sites like Keybase.io (which is used by Cosmos SDK block explorers such as our own to show logos for validators) and “favicons” (commonly used to set the logo for websites in browser tabs).
The current uses for resources are therefore very broad across the SSI ecosystem, and in addition, for other companies that may want to use DIDs to reference relevant information on ledger. For this reason, it is essential that the SSI community strengthens the way that resources are stored, referenced and retrieved in SSI ecosystems.
In our demo for IIW, we showed an IIW logo as a resource on-ledger, being used within the body of a Verifiable Credential. In the JSON below, you will be able to see the resources being used in both the "@context" and "logo" sections.
By clicking the image below, you will see that this is actually being pulled and resolved from the cheqd ledger:
There are multiple approaches to decentralised identity which rely on centralised infrastructure across different technical layers. Decentralised Identifiers (DIDs): are often stored on ledgers (e.g., cheqd, Hyperledger Indy, distributed storage (e.g., IPFS in Sidetree), or non-ledger distributed systems (e.g., KERI). Yet, DIDs can be stored on traditional centralised-storage endpoints (e.g., did:web, did:git.
The issue of centralisation affects resources providing extra context and information to support Verifiable Credentials. These resources, such as schemas and revocation lists, are often stored and referenced using centralised hosting providers.
Using centralised hosting providers to store resources may have a significant difference in the longevity and authenticity of Verifiable Credentials. For example, a passport (which typically has a 5–10 year validity) issued as a Verifiable Credential anchored to a DID (regardless of whether the DID was on-ledger or not) might stop working if the credential schema, visual presentation format, or other necessary resources were stored off-ledger on traditional centralised storage.
DIDs could be tampered by compromising the hosting provider: DIDs and DID Documents ("DIDDocs") stored at a centralised web endpoint can be compromised and replaced by malicious actors.
Hosting providers could unilaterally cease to host particular clients: Hosting providers could terminate accounts due to factors such as non-payment of fees, violation of Terms of Service, etc.
Single point-of-failure in resiliency: Even for highly-trusted and sophisticated hosting providers who may not present a risk of infrastructure being compromised, a service outage at the hosting provider can make a DID anchored on their systems inaccessible.
Even for highly-trusted and sophisticated hosting providers who may not present a risk of infrastructure being compromised, a service outage at the hosting provider can make a resource anchored on their systems inaccessible.
The high centralisation of cloud providers and history of noteworthy outages clearly demonstrates why we should not host resources on centralised cloud storage in production environments. In Q1 of 2022, the three largest players in the cloud (AWS, Google Cloud, Microsoft Azure) dominated with 65 per cent in nearly all regions (outside of China).
Figure 3: Breakdown of global cloud provider market share (source: CoinTelegraph)
Beyond cloud providers, there are other events that exemplify the issuers relying on larger players. The Facebook outage of 2021 (shown in the graph below) took down apps that used “Login with Facebook” functionality. This highlights the risks of “contagion impact” (e.g., a different Facebook outage took down Spotify, TikTok, Pinterest) of centralised digital systems — even ones run by extremely-capable tech providers.
Figure 4: Graph showing drop in Facebook traffic from their global service outage in 2021 (source: Kentik)
Likewise, with decentralised identity, there has been excellent work to decentralise, with standards that remove the need for centralised intermediaries — notably around Verifiable Credentials and the decentralised trust provided by DID Authentication. Yet, all of this excellent work may be eroded in practice, unless every component of an SSI ecosystem is able to maintain an equivalent level of decentralised trust. Resources are currently an area that has been centralised for the sake of convenience.
"Link rot" happens when over time, URLs become inaccessible, either because the endpoint where the content was stored is no longer active, or the URL format itself changes. The graph below from an analysis by The New York Times of linkrot shows degradation over time of URLs.
Figure 5: Linkrot analysis over 1996-2019 by New York Times (source: Columbia Journalism Review / New York Times)
For this reason, keeping an up-to-date version of the links themselves is crucial. Furthermore, a study of link rot found at least 66.5% of links to sites in the last 9 years are dead. This can have an adverse impact on the digital longevity of Verifiable Credentials if there’s “link rot” in the resources necessary to process the credential. For this reason, projects such as The Internet Archive’s Wayback Machine exist to snapshot digital ephemera before they are lost forever.
Figure 6: Pie chart showing root causes of link rot (source: Ahrefs)
This illustrates that link rot can affect a significant proportion of links in a relatively small amount of time, and once again, looking at how resources are currently stored in SSI ecosystems, if the resource locations are moved and the links are broken, the Verifiable Credentials relying on these resources become unusable. Therefore, resources, once defined, should be architected to be used and referenced indefinitely, without being changed.
Finally, the centralised way that resources are currently stored and managed is not immutable, and as a result, it is liable to tampering. For example, if a hosting provider is compromised, or if malicious actors are working for the company, resources may be changed and previous resource versions may be purged from the central database.
As we move towards a new web infrastructure with Web 3 (and beyond…), and as more projects leverage blockchain and distributed ledgers, it’s important not to port the previous issues of the web, and instead find novel ways to better manage information, with longevity in mind. This is why at cheqd, we have decided to redesign the way resources are captured on the ledger.
Solutions that do currently store schemas on ledger (e.g., Hyperledger Indy) don't have semantic linkage between old and new versions. In this instance, current ledgers allow new versions to be made but don't offer an easy way for client apps to discover linkages as they evolve over time.
We took the following design principles into consideration, along with an explanation of how we addressed them:
Built using existing, familiar DID Core Spec patterns: Wherever possible, our design attempts to utilise existing patterns and behaviours within the W3C DID Core specification (such as the use of DID URLs to identify resources), instead of trying to implement proprietary/custom approaches. We believe that similar designs could be adopted by other DID methods if they choose.
Protection against linkrot for long-term retrieval: Any Resource stored on-ledger is replicated across multiple nodes.
If any individual node or endpoint is down, lookup requests can be sent to any other node on the network.
In a catastrophic scenario where the network itself stops to exist, e.g., companies shutting down, getting acquired etc the on-ledger data can still be restored by digital archivists using ledger snapshots. A practical example of this is how Cosmos Hub makes historical chain archives available which can be restored. While this can be cumbersome, we wanted to design for this as a fail-safe.
Extensible by default: Our objective was to build a flexible design pattern that allowed developers to define and extend their own resource types. Trying to control what kinds of resources could be written to ledger would make the ledger-side logic complex. Instead, we opted for a design where the cheqd ledger acts agnostically to store resources, as long as correctly authorised, as a permanently-accessible endpoint.
Design for DID-spec "dumb" as well as DID-spec "smart" client applications: Many approaches in this space assume that client applications must be adept at parsing DIDDocs and resolving complex inter-DIDDoc relationships. We saw describing resources using DIDDocs as metadata about the resource which could be independently-parsed by "smart" client applications; while also providing a fallback approach for "dumb" client applications. We internally considered this as "What if an identity wallet understood how to parse JSON, but didn't understand the DID Core spec?"
Version controlled: The ability to evolve a resource over time is critical for identity use cases. As described above, examples of this include when identity document schemas change, logos evolve, etc. Current approaches (such as Hyperledger Indy CredDefs) deal with this by creating entirely new, unlinked resources. We designed to make it easy, using existing DID Core specification techniques, so that client applications could query "What was the version of a resource with this name on this date/time?"
Make re-use of resources simple: We liked the concept of Schema.org in the sense that it promotes a common, machine-readable specification. Therefore, our design allows for patterns where the controllers of a DID can reference resources created by other DID owners/controllers, e.g., referencing a pre-existing schema. Taking this line of thought further, it allows for an arbitrary depth of how resources can be nested, as long as they are discoverable/resolvable.
Notalltypes of resources should be stored on a ledger...but can be made discoverable through similar design patterns: Distributed ledgers are great for redundancy, but the cost of this duplication (in terms of storage required by node, block size, transaction finality speeds, etc) can be quite significant. For instance, a distributed ledger is probably not the best storage and retrieval mechanism for a video file (which can run into many GBs/TBs); or even a PDF larger than a few MBs. cheqd network restricts the block size for an individual block to ~200 KB. This can be updated via an on-ledger vote, but the trade-off of asking node operators to provision ever-expanding storage would be not ideal. Our design therefore restricts the file/payload size of on-ledger resources (in our case, ~190 KB - giving enough room for transaction data besides the resource itself), while allowing the same techniques below to be used for describing off-ledger resources. E.g., our first DID on cheqd network references a 7+ MB image accessible via IPFS. We recognise and accept that DID owners/creators may choose to use their own centralised/decentralised storage, and the design patterns described below accommodate that.
Learn more about the technical details on learn how we have architected DID-Linked resources, and how we achieve these design principles.
