Could tie it to something like a biometric. That and storing it on a write-only device would keep it from being shared too wide. The trickiss to tie it to a true multi-factor and not just something you have (if unencrypted) or something you know (if ASCII armored).
I’ll address the second objection first regarding the phone or browser. You’re always going to rely on some technology for the solutions that use cryptography, you just can’t do those calculations long-hand realistically. That said, look up frameworks like CTAP that allow a potentially untrusted user terminal, like a browser, to interact with a trusted hardware token. Those hardware tokens can be made fairly tamper-proof, see FIPS authorized Yubikeys, such that the phone is pretty much removed from the attestation process. Yes these can still be stolen, but they make hardware keys that are fingerprint authenticated and the biometric stays on the device. Doesn’t get much more self-sovereign than that.
The existence of a trusted credential provider is a challenge. Fully self-sovereign credentials need to either be trust on first use or validated against a larger system everyone participates in. Even if we had some system of birth certificates tied to a distributed ledger, we would have to trust the third party recording that certificate in the first place, be it a hospital, doctor, or state entity. These trust and proof systems don’t create the trust, they just allow us to extend that trust from one claimant to a verifier. Whether you place that trust in the state, an individual, or an independent third party is up to you.
Did you muck with Logseq at all? That’s my preferred note taking app and it checks a lot of your boxes, the biggest miss probably being the Electron app part. That said, I’ve never noticed any slow downs.
But this is great to have options and a larger ecosystem. I’ll have to check it out.