Puse @Dusk , un nuevo monedero, y las instrucciones de Dusk Connect lado a lado, y recién así entendí que lo que han añadido no es “otra piel más de un monedero”, sino la capa de conexión que el dApp llevaba tiempo echando de menos. El antiguo Web Wallet puede hacer transferencias y apostar por separado, pero la aplicación no puede descubrir el monedero, solicitar cuentas, firmar y enviar transacciones mediante una interfaz unificada; los desarrolladores solo pueden adaptarse rodeando cada monedero en concreto.
Lo que hace Dusk Connect se parece mucho a estandarizar esa especie de “pegamento”: el descubrimiento del monedero toma como referencia la idea de EIP-6963; el RPC gestiona las cuentas, firmas, transacciones y solicitudes de red por espacio de nombres; y además prepara pruebas de consistencia para quienes implementan el monedero. El nuevo monedero oficial ya, desde el principio, sigue esta interfaz de provider para cubrir extensiones del navegador, escritorio y móvil; las transferencias públicas y privadas, shield/unshield, staking, cobro de recompensas, DRC-20 y DRC-721 se incluyen en una misma ruta de interacción.
El punto más fácil de que te desvíen los textos promocionales es equiparar “repositorio abierto” directamente con “producto maduro”. Por ahora, la posición oficial sigue siendo developer preview. La clave se guarda localmente; el lado de la extensión usa PBKDF2 y AES-GCM; el lado nativo usa Stronghold y Argon2. Todo eso es una base de seguridad correcta, pero lo que realmente determina la experiencia es la recuperación ante desconexiones, los avisos de permisos, la retroalimentación de transacciones fallidas y la consistencia del estado entre múltiples plataformas.
Esa es también la razón por la que últimamente miré #dusk sin quedarme solo en los términos del protocolo: sin una capa estable de conexión del monedero, por muy bonitos que sean los contratos de privacidad, solo sirven como demostraciones para desarrolladores. $DUSK necesita el siguiente paso no en forma de otra captura de interfaz, sino que un dApp de terceros pueda conectarse de manera realmente transparente. Cuando evalúan si un nuevo monedero sirve, ¿primero miran la tabla de funciones o primero ven cómo se comporta en escenarios de fallo?
Lo que hace Dusk Connect se parece mucho a estandarizar esa especie de “pegamento”: el descubrimiento del monedero toma como referencia la idea de EIP-6963; el RPC gestiona las cuentas, firmas, transacciones y solicitudes de red por espacio de nombres; y además prepara pruebas de consistencia para quienes implementan el monedero. El nuevo monedero oficial ya, desde el principio, sigue esta interfaz de provider para cubrir extensiones del navegador, escritorio y móvil; las transferencias públicas y privadas, shield/unshield, staking, cobro de recompensas, DRC-20 y DRC-721 se incluyen en una misma ruta de interacción.
El punto más fácil de que te desvíen los textos promocionales es equiparar “repositorio abierto” directamente con “producto maduro”. Por ahora, la posición oficial sigue siendo developer preview. La clave se guarda localmente; el lado de la extensión usa PBKDF2 y AES-GCM; el lado nativo usa Stronghold y Argon2. Todo eso es una base de seguridad correcta, pero lo que realmente determina la experiencia es la recuperación ante desconexiones, los avisos de permisos, la retroalimentación de transacciones fallidas y la consistencia del estado entre múltiples plataformas.
Esa es también la razón por la que últimamente miré #dusk sin quedarme solo en los términos del protocolo: sin una capa estable de conexión del monedero, por muy bonitos que sean los contratos de privacidad, solo sirven como demostraciones para desarrolladores. $DUSK necesita el siguiente paso no en forma de otra captura de interfaz, sino que un dApp de terceros pueda conectarse de manera realmente transparente. Cuando evalúan si un nuevo monedero sirve, ¿primero miran la tabla de funciones o primero ven cómo se comporta en escenarios de fallo?
