Welcome to our Feedback Hub

Toggle between the Bug Report, Feature Request or Incident Report board and let us know how we can improve.

Completed

Cheqd Rust Resolver - Crates.io deployment failing

From Glenn (CEO @ Affinidi) One of your engineers (https://github.com/DaevMithran) submitted a PR to integrate Cheqd into our DID Resolver - thank you! Unfortunately we can’t push this to release because the Cheqd code is being sourced from the OWF git repo which hasn’t been published on crates.io and crates.io is failing it because it is pedantic on package names etc. I had a Quick Look at the OWF repo code https://github.com/openwallet-foundation/vcx/tree/main/did_core/did_methods/did_cheqd It is old, out of date and needs some love 😊 I am going to hold the Cheqd implementation as it is breaking our own CICD toolchain (and it is pulling in a rather large git repo). Do you have a preference on the following solutions: Pull the Cheqd DID implementation out of OWF and you publish a standalone Rust Library of the Cheqd resolver. Affinidi can then integrate with this cleanly If you have dev documentation on the gRPC details of resolving Cheqd DID’s, I can whip up a did-cheqd native crate for you (similar to the other DID-methods in the eco-system).

Fraser Edwards 4 months ago

1
πŸ›

Bug Reports

Completed

Ensure Credo and React Native can use the latest cosmjs libraries

We got a security report because the cheqd SDK in Credo depends on two versions of cosmjs libraries. One using recent cosmjs versions for ESM, and one using outdated cosmjs libraries which depends on a really old version of axios with critical vulnerabilities. I want to open this bug report to track the progress of using the latest cosmjs libraries in Credo. I think we will have to update Credo to use ESM, and thus also all projects and libraries depending on Credo, since cosmjs now only supports ESM. I want to check whether we see other approaches besides Credo updating to ESM (I’ll try to prioritize it, but it will take a while to do this).

Timo Glastra 4 months ago

πŸ›

Bug Reports

Backlog

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)

George Mulhearn 4 months ago

1
πŸ’‘

Feature Requests

Completed

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.

cheqd Product Team 6 months ago

πŸ’‘

Feature Requests

Completed

Node validator problem

Output of our systemctl status cheqd-cosmovisor.service: May 14 12:00:51 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","time":"2025-05-14T12:00:51Z","message":"Error executeAllHostChainTWAPQuery module does not own channel capability: source_port: feeabs, source_channel: : channel capability > May 14 12:01:49 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","err":"module does not own channel capability: source_port: feeabs, source_channel: : channel capability not found","time":"2025-05-14T12:01:49Z","message":"SendOsmosisQueryR> May 14 12:01:49 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","err":"module does not own channel capability: source_port: feeabs, source_channel: : channel capability not found","time":"2025-05-14T12:01:49Z","message":"handleOsmosisIbcQ> May 14 12:01:49 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","time":"2025-05-14T12:01:49Z","message":"Error executeAllHostChainTWAPQuery module does not own channel capability: source_port: feeabs, source_channel: : channel capability > May 14 12:02:51 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","err":"module does not own channel capability: source_port: feeabs, source_channel: : channel capability not found","time":"2025-05-14T12:02:51Z","message":"SendOsmosisQueryR> May 14 12:02:51 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","err":"module does not own channel capability: source_port: feeabs, source_channel: : channel capability not found","time":"2025-05-14T12:02:51Z","message":"handleOsmosisIbcQ> May 14 12:02:51 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","time":"2025-05-14T12:02:51Z","message":"Error executeAllHostChainTWAPQuery module does not own channel capability: source_port: feeabs, source_channel: : channel capability > May 14 12:03:47 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","err":"module does not own channel capability: source_port: feeabs, source_channel: : channel capability not found","time":"2025-05-14T12:03:47Z","message":"SendOsmosisQueryR> May 14 12:03:47 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","err":"module does not own channel capability: source_port: feeabs, source_channel: : channel capability not found","time":"2025-05-14T12:03:47Z","message":"handleOsmosisIbcQ> May 14 12:03:47 cheqd-node0-monokee cosmovisor[1172432]: {"level":"error","module":"server","module":"x/feeabs","time":"2025-05-14T12:03:47Z","message":"Error executeAllHostChainTWAPQuery module does not own channel capability: source_port: feeabs, source_channel: : channel capability > Any idea how to fix it? thank you

Roberto Griggio 9 months ago

πŸ›

Bug Reports