Yes, this is a bug, I agree this is a poor design.

Any good ideas on how I could improve/change this without dropping support for a secure enclave?

If a user logs out of the browser / hardware wallet / extension / enclave, then the put would still fail, because the keys shouldn't be exposed in-memory in the web app if possible.

But if a put is able to "keep" a user logged in on the browser/wallet/extension/enclave, couldn't that be used as a security exploit/vulnerability?

If you think if something, please let me know. It is causing some other race conditions I'd like to address too.

I think the issue is that we have seperate user.auth and user.get steps, i.e. the state is carried a global variable. My preference would be that
user.auth(pair) returns (via callback) the user context, and that this user context is used on get and put operations rather than a global context which implicitly assumes a certain model - that there is a single logged in user, rather than operation happen within the context of a pair that can be used to sign things ....

If its too late for that change, then I guess heavy documentation would be useful, but since basic documentation is missing, Im not sure that is possible :-(

As a race of course, this makes for horendous debugging if you don't realize what is happening.

Note - I've worked around this bug ... so its not a requirement for me, but couple odd behavior and poor documentation and you've got a high likelyhood of other people going down the rathole of trying to debug.

It would also be superhelpful if putJS existed - like put but with Javascript callback semantics so that it could be put into a waterfall or each. I've monkeypatched Gun to add Javascript semantics to some functions, but can't figure out how to do it on put because I can't figure out the class of the context returned by the "get" .