El problema no es la custodia. Es el diseño.

• La decisión que nadie discute
• Lo que NIP-46 y ncryptsec sí resuelven
• Lo que no resuelven
• Por qué las propuestas de rotación no avanzan
• Las consecuencias que ya ocurren
• Lo que deberías hacer hoy
• La pregunta correcta

§La decisión que nadie discute

En Bitcoin, cuando dices ‘tus llaves, tus monedas’ estás describiendo una propiedad. En Nostr, cuando dices ‘tu llave, tu identidad’ estás describiendo algo más profundo: no hay separación entre el actor y el instrumento criptográfico.

Tu npub es tu nombre. Tu nsec es tu única prueba de que eres tú. No hay árbitro, no hay recuperación, no hay ‘olvidé la contraseña’.

Eso es soberanía real. También es un riesgo real que la mayoría ignora.

§Lo que NIP-46 y ncryptsec sí resuelven

NIP-46 (bunker mode / remote signer) es una mejora genuina. Separa la llave del cliente. Cuando te conectas con un URI bunker://, el nsec nunca sale del signer. Una página de phishing no puede robar lo que no ve.

ncryptsec (NIP-49) es igualmente correcto: tu backup empieza con ncryptsec1 y necesita una contraseña para ser útil. Si alguien roba el archivo, no tiene la llave. Tiene un problema de criptografía.

Ambas medidas reducen la superficie de ataque. Ambas son correctas. Ninguna resuelve el problema central.

§Lo que no resuelven

Si esa llave maestra se compromete, no hay nada que hacer.

No porque falten herramientas. Sino porque en el modelo de Nostr actual, la identidad y la llave son el mismo objeto. Comprometer la llave es comprometer la identidad. Punto.

Bitcoin resolvió esto con multisig y timelocks: una clave comprometida no destruye la estructura completa. Nostr tiene propuestas análogas para key rotation, pero llevan más de dos años en draft sin merge.

§Por qué las propuestas de rotación no avanzan

No es un problema técnico. Las propuestas existen y son razonables.

El bloqueo es social: migrar una identidad Nostr a una llave nueva requiere que todos tus seguidores actualicen sus referencias. En la práctica, significa volver a empezar desde cero en términos de seguimiento real.

Nadie quiere pagar ese coste. Los usuarios con audiencia prefieren asumir el riesgo que destruir lo que construyeron. Los desarrolladores no implementan lo que nadie va a usar. El protocolo acepta el riesgo en silencio.

§Las consecuencias que ya ocurren

Cuentas comprometidas que siguen publicando porque el atacante tiene la llave y por tanto tiene la identidad. Clientes que no pueden distinguir entre el dueño legítimo y quien robó la llave. Reputación construida durante años que puede ser destruida o secuestrada en minutos.

Esto no es teórico. Ha pasado. Seguirá pasando mientras la identidad y la llave sean el mismo objeto.

§Lo que deberías hacer hoy

Mientras el problema de fondo no se resuelve a nivel de protocolo:

• Usa NIP-46. Nunca pegues un nsec en un cliente nuevo directamente.
• Tu backup debe ser ncryptsec1, no nsec1 crudo. Si alguien accede al archivo, que sea inútil sin la contraseña.
• Verifica la restauración. Tener el backup no es suficiente: necesitas haber restaurado en frío y verificado que obtienes la misma identidad. Un backup no verificado es un wishful thinking.
• Acepta que hoy, si la llave se compromete, la identidad se compromete. No hay garantía de recuperación. Eso debería cambiar tu cálculo de riesgo en qué dispositivos y qué redes usas.

§La pregunta correcta

No es ‘cómo protejo mi llave’. Es ‘acepto que mi identidad y mi llave son el mismo objeto, y actúo en consecuencia’.

La autocustodia real no es instalar un hardware wallet. Es entender qué controlas y qué no. En Nostr, controlas la llave. No controlas lo que pasa si la pierdes.