Anoche, un amigo me mostró en el teléfono dos aplicaciones que necesitaban su cartera.
Lo que le molestaba no era conectarla.
Era que cada app parecía entender
la cartera de manera diferente.
Eso me hizo mirar Dusk Connect con más cuidado.
Dusk Connect permite que un dApp descubra proveedores de cartera compatibles, que el usuario elija uno, solicite acceso y reaccione a cambios en la cartera activa, el perfil, la autorización o la red.
Al principio, lo vi como infraestructura normal de carteras.
Luego noté la consecuencia más interesante. El dApp puede depender de una interfaz de conexión sin hacer que
una implementación específica de cartera forme parte de su arquitectura.
Eso importa porque las integraciones tienden a convertirse en dependencias. Una vez que la
lógica de la aplicación asume el comportamiento de un proveedor en particular, reemplazar ese proveedor puede implicar tocar
no solo el código de conexión.
Dusk Connect mueve esa dependencia hacia afuera.
El compromiso es que la abstracción no elimina el estado de la cartera.
Un proveedor puede cambiar, pero la aplicación aún tiene que entender cuándo cambia una cuenta, cuándo se revoca
la autorización o cuándo cambia la red. En otras palabras, la mecánica de conexión puede abstraerse, pero el estado de la aplicación no.
Creo que ese es el verdadero valor arquitectónico aquí.
El objetivo no es simplemente hacer que haya más carteras compatibles con un dApp de Dusk.
Es evitar que la propia implementación de la cartera se convierta en una dependencia oculta dentro de la aplicación.
En serio, eso cambia la forma en que pienso sobre la infraestructura de carteras. Una buena abstracción no es ocultarlo todo.
Es aislar lo que puede cambiar sin ocultar lo que la aplicación aún debe controlar.
Para los desarrolladores que construyen sobre @Dusk la pregunta se vuelve:
¿Qué supuestos sobre la cartera pertenecen dentro de la aplicación y cuáles deberían permanecer fuera
de su arquitectura? 🧩
#Web3 #Blockchain #DeFi #dusk $DUSK $ETH @Dusk
Lo que le molestaba no era conectarla.
Era que cada app parecía entender
la cartera de manera diferente.
Eso me hizo mirar Dusk Connect con más cuidado.
Dusk Connect permite que un dApp descubra proveedores de cartera compatibles, que el usuario elija uno, solicite acceso y reaccione a cambios en la cartera activa, el perfil, la autorización o la red.
Al principio, lo vi como infraestructura normal de carteras.
Luego noté la consecuencia más interesante. El dApp puede depender de una interfaz de conexión sin hacer que
una implementación específica de cartera forme parte de su arquitectura.
Eso importa porque las integraciones tienden a convertirse en dependencias. Una vez que la
lógica de la aplicación asume el comportamiento de un proveedor en particular, reemplazar ese proveedor puede implicar tocar
no solo el código de conexión.
Dusk Connect mueve esa dependencia hacia afuera.
El compromiso es que la abstracción no elimina el estado de la cartera.
Un proveedor puede cambiar, pero la aplicación aún tiene que entender cuándo cambia una cuenta, cuándo se revoca
la autorización o cuándo cambia la red. En otras palabras, la mecánica de conexión puede abstraerse, pero el estado de la aplicación no.
Creo que ese es el verdadero valor arquitectónico aquí.
El objetivo no es simplemente hacer que haya más carteras compatibles con un dApp de Dusk.
Es evitar que la propia implementación de la cartera se convierta en una dependencia oculta dentro de la aplicación.
En serio, eso cambia la forma en que pienso sobre la infraestructura de carteras. Una buena abstracción no es ocultarlo todo.
Es aislar lo que puede cambiar sin ocultar lo que la aplicación aún debe controlar.
Para los desarrolladores que construyen sobre @Dusk la pregunta se vuelve:
¿Qué supuestos sobre la cartera pertenecen dentro de la aplicación y cuáles deberían permanecer fuera
de su arquitectura? 🧩
#Web3 #Blockchain #DeFi #dusk $DUSK $ETH @Dusk