Manage a DID-Linked Resource
This guide demonstrates how to manage DID-Linked Resources using the cheqd SDK. Unlike traditional "updating," DID-Linked Resources are immutable - managing them means creating new versions that form a double-linked list of resource history.
Understanding Resource Versioning
Key Concepts
DID-Linked Resources are immutable. When you "update" a resource, you're actually creating a new version with the same name and resource type. Each version in the chain contains:
nextVersionId- Points to the newer version (if it exists)previousVersionId- Points to the older version (if it exists)
Version Creation Rules
New Version: Created when
nameandresourceTypeare identical to an existing resourceContent can be the same or different
Creates a linked version in the chain
Gets assigned
nextVersionIdandpreviousVersionId
New Resource: Created when
nameORresourceTypediffer from existing resourcesStarts a completely new resource chain
No version linking to existing resources
Prerequisites
Before managing resources, ensure you have:
Created a DID-Linked Resource to version
A funded wallet for paying transaction fees
Access to a cheqd network (testnet or mainnet)
The private keys associated with the DID's authentication methods
SDK Initialization
First, initialize the SDK with the required modules:
Basic SDK Setup
Advanced SDK Setup with Multiple Modules
Resource Versioning Examples
Example 1: Create New Version of JSON Schema
This example creates a new version of an existing JSON Schema resource:
Example 2: Create New Version with Same Content (Timestamp Update)
This example shows creating a new version even when content hasn't changed:
Example 3: Create New Resource (Different Name/Type)
This example shows creating a completely new resource rather than a version:
Example 4: Create Version with Different Resource Type
This example shows what happens when you change the resource type:
Example 5: Complex Version Chain Navigation
This example shows how to navigate and understand a version chain:
Complete Working Example
Here's a complete example for creating a resource version:
Version Chain Management
Understanding the Double-Linked List
Each resource version maintains links to form a double-linked list:
Version Navigation Patterns
Alternative: Using DID Resolver for Version Navigation
Note: Version navigation patterns can also be implemented using the DID resolver instead of the SDK. The DID resolver may offer better performance for intensive version traversal operations since SDK queries can be rate-limited by RPC/REST API requests.
The DID resolver provides dereferencing capabilities that allow direct resolution of DID URLs pointing to specific resources. This leverages the DID URL dereferencing specification to resolve resource references efficiently. For more details on DID resolution and dereferencing, see the DID Resolver setup guide.
Performance Considerations
SDK Queries: Direct SDK queries may be subject to RPC/REST API rate limiting
DID Resolver: May provide better performance for intensive version navigation
Batch Operations: Consider resolver for operations requiring many sequential queries
Caching: Implement caching strategies regardless of method chosen
Best Practices
Version Management Strategy
Semantic Versioning: Use semantic versioning (major.minor.patch) for clarity
Meaningful Changes: Only create versions for meaningful changes
Version Documentation: Include change logs in your resource content
Chain Navigation: Implement proper chain traversal for your applications
Latest Version Logic: Always check for the latest version in your applications
Content Management
Immutability Awareness: Remember that all versions are permanent and immutable
Storage Efficiency: Be mindful of storage costs when creating frequent versions
Content Validation: Validate content before creating versions
Metadata Consistency: Keep metadata consistent across versions
Breaking Changes: Use major version increments for breaking changes
Fixed Pricing by Content Type: Resource creation costs vary based on content type (JSON, image, default). Use the appropriate fee generator functions (
generateCreateResourceJsonFees,generateCreateResourceImageFees,generateCreateResourceDefaultFees) or delegate fee calculation to the broadcasting functions, which will automatically set fees based on the resource's media type.
Query Performance Considerations
Chain Length: Long version chains may impact query performance
Batch Operations: Group related version creations when possible
Caching Strategy: Cache frequently accessed versions
Index Management: Maintain indexes of latest versions for quick access
Pruning Strategy: Plan for archival of very old versions if needed
Error Handling and Validation
Version Chain Validation
Version chains are automatically maintained by the cheqd ledger and should always be consistent. Here's an example showing what a healthy version chain looks like:
Resource Creation Validation
Troubleshooting
Common Issues
Broken Version Chains: Check that previousVersionId and nextVersionId are properly linked
Accidental New Resources: Verify name and resourceType match exactly for versioning
Missing Previous Version: Ensure previousVersionId points to an existing resource
Permission Denied: Verify signing keys have authority over the collection DID
Fee Calculation Errors: Use appropriate fee methods for your resource media type
Version Chain Recovery
Next Steps
After managing resources, you can:
Implement automated version management workflows
Build version-aware applications that always use latest resources
Getting Help
If you encounter issues:
Check the cheqd SDK GitHub repository for updates
Review the test files for examples
Consult the cheqd documentation for comprehensive guides
Join the cheqd Community Discord for support
Last updated
Was this helpful?