Hey, that's interesting. I've never heard about this one-shot ECDH. I was digging a bit and thinking about how apps can respect user privacy more. AFAIK, the one-shot approach generates a new derived key each time, which is great. However, for app-specific data where a long-term relationship is expected and it should be possible to recover data without knowing the previous key used, for example, while jumping between different platforms in a multi platform app, this approach might not be ideal. So, maybe something interesting is that users and apps can generate a stable 'channel' to use for this kind of thing. One initial idea is to use DH where the app exposes a public key, for example, the same one used to sign NIP-89 events. Then, the user, each time the app needs to persist settings or whatever, derives the key using DH and publishes the encrypted data using that key. In this case, the DH secret can be taken as the secret key, and the public key can be derived from it. The only entities capable of knowing where the key comes from are the user and the app. However, this might work but present some limitations. Instead of a pure DH approach, it could be a deterministic KDF. This way, the app itself can have a stable identifier and use it as a salt, so the user can generate a key pair deterministically without requiring the app to maintain a stable public key. I don't know, just rambling here, but I think it's a topic worth exploring.