Have something to say?
Multikey VerificationMethod support
Currently by my reading of the docs, i’m able to update a DIDDoc with VMs of type: Ed25519VerificationKey2020 EcdsaSecp256k1VerificationKey2019 RsaVerificationKey2018 (source) https://docs.cheqd.io/product/advanced/sdk/did-module#supported-key-types Although the source code seems to indicate: JsonWebKey2020 (key types ECDSA, Ed25519 & RSA are seemingly supported) Ed25519VerificationKey2020 Ed25519VerificationKey2018 (source) https://github.com/cheqd/cheqd-node/blob/2089162a071d1a741696a256457d656fa9457968/x/did/types/diddoc_verification_method.go#L17 It would be nice if it was also possible to push Multikey VM types. Anecdotally, i’ve seen this VM grow in popularity over the years, as it is able to represent a huge range of key types with a single VM type, and is also compact. Similar properties to JsonWebKey2020, but arguably more compact and could be overtaking it in popularity. The support for the VM could be done in the same way as JsonWebKey2020 - limited scope to ed25519, ecdsa & rsa key type support. Supporting multikey VMs in cheqd DID Docs may improve interoperability in systems which prefer Multikey to it’s alternatives (e.g. JsonWebKey2020)
Improve / Understand batching logic
Please create documentation around how multiple resources can be batched together into a single transaction / block. Currently, there is no clear way to achieve this. A diagram showing the logic would be very helpful
Improve revocation registry size
Revocation registries have limited size to a relatively small amount of entries. It would be fantastic to bump the size, and improve the efficiency of how these are stored and indexed on ledger
Fallback Endpoints for DID Resolver / DID Registrar
I wanted to reach out about an operational challenge we’re experiencing with cheqd/did-resolver and cheqd/did-registrar that a fallback mechanism could solve.The Problem: We’re running into issues with testnet accessibility. When your testnet nodes are behind the firewall (blocking p2p connections), our self-hosted node can’t join the network, which breaks our applications that are configured to use our local endpoints.Current Manual Workaround: Testnet nodes go behind firewall → our node can’t sync We manually update deployments to point at official endpoints (grpc.cheqd.network:443, https://rpc.cheqd.network) When firewall is removed → our node can rejoin the network We manually update deployments back to our local endpoints This creates a lot of operational overhead and requires manual intervention every time network accessibility changes.Proposed Solution: Could you add automatic fallback functionality to both projects? Something like: did-resolver: Try our gRPC endpoint first, if connection fails (5xx, or Connection Refused) → automatically fall back to grpc.cheqd.network:443 did-registrar: Try our RPC endpoint first, if connection fails (5xx, or Connection Refused) → automatically fall back to https://rpc.cheqd.network The Flow We’re Envisioning: Try primary endpoint (our node) On connection error → switch to official endpoints When primary comes back online → switch back automatically This would eliminate the need for manual deployment updates every time testnet accessibility changes and make our infrastructure much more resilient to network-level issues.
Compress AnonCreds status lists
From Timo (Animo) Maybe we should update the cheqd anoncreds method to compress the status list (or anoncreds in general)? It's quite inefficient to put it as an array like this: https://resolver.cheqd.net/1.0/identifiers/did:cheqd:mainnet:fdd80fdc-8756-491d-838d-ccd705b2776a/resources/c95a79db-fb74-4b00-a114-faa8ac12d629