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

  1. New Version: Created when name and resourceType are identical to an existing resource

    • Content can be the same or different

    • Creates a linked version in the chain

    • Gets assigned nextVersionId and previousVersionId

  2. New Resource: Created when name OR resourceType differ from existing resources

    • Starts a completely new resource chain

    • No version linking to existing resources

Prerequisites

Before managing resources, ensure you have:

  1. A funded wallet for paying transaction fees

  2. Access to a cheqd network (testnet or mainnet)

  3. 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

  1. Semantic Versioning: Use semantic versioning (major.minor.patch) for clarity

  2. Meaningful Changes: Only create versions for meaningful changes

  3. Version Documentation: Include change logs in your resource content

  4. Chain Navigation: Implement proper chain traversal for your applications

  5. Latest Version Logic: Always check for the latest version in your applications

Content Management

  1. Immutability Awareness: Remember that all versions are permanent and immutable

  2. Storage Efficiency: Be mindful of storage costs when creating frequent versions

  3. Content Validation: Validate content before creating versions

  4. Metadata Consistency: Keep metadata consistent across versions

  5. Breaking Changes: Use major version increments for breaking changes

  6. 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

  1. Chain Length: Long version chains may impact query performance

  2. Batch Operations: Group related version creations when possible

  3. Caching Strategy: Cache frequently accessed versions

  4. Index Management: Maintain indexes of latest versions for quick access

  5. 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

  1. Broken Version Chains: Check that previousVersionId and nextVersionId are properly linked

  2. Accidental New Resources: Verify name and resourceType match exactly for versioning

  3. Missing Previous Version: Ensure previousVersionId points to an existing resource

  4. Permission Denied: Verify signing keys have authority over the collection DID

  5. 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:

Last updated

Was this helpful?