#dusk $DUSK @Dusk
Recientemente, al preparar material para el proyecto, tengo un hábito bastante tonto: no miro primero en <a>Twitter</a> ni cuento primero a los socios; directamente busco en la documentación los “escenarios de fallo”.
Porque cuando todo va bien, cualquiera parece un experto. Lo que realmente revela la madurez del producto suele ser lo que ocurre después de que el usuario se equivoca, se corta la red o la transacción se queda atascada: cómo el sistema te sostiene.
Tomemos el caso @Dusk . Al revisar sus materiales de desarrollo, lo que más se nota es esto: desde el lado de ingeniería, la densidad de información no es baja. Pero si cambias la perspectiva de “cómo se integra desde el punto de vista del desarrollador” a “cómo vive un usuario normal todo el proceso completo”, los detalles ya no son tan abundantes.
Me fijo especialmente en estas cosas:
① Billetera: después de un fallo de conexión, si existe una ruta de diagnóstico clara; cómo se maneja por separado cambiar de dispositivo, cambiar de red y volver a autorizar;
② Cuenta: qué permisos hay exactamente, si la autorización se puede desglosar y qué estados se pueden revocar de forma proactiva;
③ Transacción: qué significan por separado “Pendiente”, “fallida” y “timeout”; si el usuario debe esperar, reintentar o volver a iniciar el envío;
④ Entre cadenas: qué pasa cuando el activo queda atascado en un estado intermedio, y por dónde se ve la ruta de fondos después del fallo;
⑤ Privacidad: qué datos de la transacción son visibles y cuáles no; y cómo confirma el usuario exactamente qué ha divulgado;
⑥ Recuperación: si desaparece la caché del navegador, si se cambia el dispositivo o si la billetera falla, si el usuario tiene una ruta de auto-rescate clara.
Estas cosas quizá no parezcan nada “sexy”, pero explican mejor si el producto entró realmente en una etapa de uso real, más que otra ficha/afiche de colaboración con el ecosistema.
Incluso le haría una tabla de observación bastante simple:
Completitud del tutorial de desarrollo: alta
Legibilidad de la API: relativamente alta
Cobertura de escenarios de excepción: media y tirando a débil
Guía de recuperación para usuarios: por observar
Explicación de permisos: por observar
Tratamiento de fallos entre cadenas: por observar
Capacidad de autoservicio para usuarios comunes: por validar
Por supuesto, esto no significa que la ruta técnica de Dusk tenga problemas. Al contrario: cuanto más se involucra privacidad, RWA, cumplimiento y activos on-chain, menos se puede mirar solo si “se puede ejecutar”. También hay que ver si “se puede gestionar cuando salen problemas”.
Lo que de verdad me hace subir la valoración no es que la documentación de repente agregue decenas de páginas, sino que un día me di cuenta de esto: incluso las esquinas menos atractivas de escribir—como las transacciones fallidas, las autorizaciones incorrectas o los atascos de activos—alguien las explica con seriedad.
Recientemente, al preparar material para el proyecto, tengo un hábito bastante tonto: no miro primero en <a>Twitter</a> ni cuento primero a los socios; directamente busco en la documentación los “escenarios de fallo”.
Porque cuando todo va bien, cualquiera parece un experto. Lo que realmente revela la madurez del producto suele ser lo que ocurre después de que el usuario se equivoca, se corta la red o la transacción se queda atascada: cómo el sistema te sostiene.
Tomemos el caso @Dusk . Al revisar sus materiales de desarrollo, lo que más se nota es esto: desde el lado de ingeniería, la densidad de información no es baja. Pero si cambias la perspectiva de “cómo se integra desde el punto de vista del desarrollador” a “cómo vive un usuario normal todo el proceso completo”, los detalles ya no son tan abundantes.
Me fijo especialmente en estas cosas:
① Billetera: después de un fallo de conexión, si existe una ruta de diagnóstico clara; cómo se maneja por separado cambiar de dispositivo, cambiar de red y volver a autorizar;
② Cuenta: qué permisos hay exactamente, si la autorización se puede desglosar y qué estados se pueden revocar de forma proactiva;
③ Transacción: qué significan por separado “Pendiente”, “fallida” y “timeout”; si el usuario debe esperar, reintentar o volver a iniciar el envío;
④ Entre cadenas: qué pasa cuando el activo queda atascado en un estado intermedio, y por dónde se ve la ruta de fondos después del fallo;
⑤ Privacidad: qué datos de la transacción son visibles y cuáles no; y cómo confirma el usuario exactamente qué ha divulgado;
⑥ Recuperación: si desaparece la caché del navegador, si se cambia el dispositivo o si la billetera falla, si el usuario tiene una ruta de auto-rescate clara.
Estas cosas quizá no parezcan nada “sexy”, pero explican mejor si el producto entró realmente en una etapa de uso real, más que otra ficha/afiche de colaboración con el ecosistema.
Incluso le haría una tabla de observación bastante simple:
Completitud del tutorial de desarrollo: alta
Legibilidad de la API: relativamente alta
Cobertura de escenarios de excepción: media y tirando a débil
Guía de recuperación para usuarios: por observar
Explicación de permisos: por observar
Tratamiento de fallos entre cadenas: por observar
Capacidad de autoservicio para usuarios comunes: por validar
Por supuesto, esto no significa que la ruta técnica de Dusk tenga problemas. Al contrario: cuanto más se involucra privacidad, RWA, cumplimiento y activos on-chain, menos se puede mirar solo si “se puede ejecutar”. También hay que ver si “se puede gestionar cuando salen problemas”.
Lo que de verdad me hace subir la valoración no es que la documentación de repente agregue decenas de páginas, sino que un día me di cuenta de esto: incluso las esquinas menos atractivas de escribir—como las transacciones fallidas, las autorizaciones incorrectas o los atascos de activos—alguien las explica con seriedad.