-
Notifications
You must be signed in to change notification settings - Fork 85
Description
Hello folks at App5,
Could you consider adding support for CCC-enabled websites to securely use the wallet's local signer and embedded light client?
Underlying Issue: currently web DApps must rely on remote RPC providers, which prevents web apps from leveraging a user's local node and signer.
Current Pain Points
- Centralization & privacy: DApps fall back to third‑party full node RPCs, this means centralization, security risks and potential metadata leakage.
- Siloed wallets: Native light-client wallets can't serve web DApps, so users don't get self‑sovereignty benefits in-browser.
- Poor UX: users must manually export/import signed payloads or switch apps instead of seamless in-DApp flows.
- Missing features: Advanced protocols like iCKB are technically hard to support in Native Wallets.
- Developer overhead: DApps must implement ad-hoc workarounds or maintain support for multiple non-standard integrations, see CommunityDAO v1.1.
Why this should be prioritized
If implemented correctly, enabling secure, permissioned sharing of the local Signer + Light Client to CCC web DApps would be far more impactful than having the Community release more wallets.
This would provide foundational infrastructure that makes existing native wallets genuinely useful to web DApps, improves decentralization, privacy and security, unlocking advanced protocol support across the ecosystem.
Requested outcome
Please expose a secure, origin-scoped, user-consent driven channel for CCC DApps to:
- Query local light-client state (limited, permissioned RPCs)
- Request local signing (with explicit user approval).
Additionally, please, let's collaborate on a minimal standard that ensure interoperability across CKB Native Wallets.
Love & Peace, Phroi