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:

1. Testnet nodes go behind firewall → our node can’t sync

2. We manually update deployments to point at official endpoints (grpc.cheqd.network:443, https://rpc.cheqd.network)

3. When firewall is removed → our node can rejoin the network

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

1. Try primary endpoint (our node)

2. On connection error → switch to official endpoints

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