Please DM me an e-mail address to send further details to along with a PGP key for encryption, or a Signal link

Done... Using coracle mobile nip-44

Oh, PGP lol I have a key on my proton I'll send it

Hah, mobile app doesn't expose it, damnit I hate PGP and email

no idea, I should look into it

This kind of exists right now

GitHub

GitHub - lnbits/nostr-signing-device: Signing device for Nostr

Signing device for Nostr. Contribute to lnbits/nostr-signing-device development by creating an account on GitHub.

although its based on an esp32 so not very secure I have it working in noStrudel on chome using web serial. But I agree we need something better. If there is a way for web apps to connect to it I would love to add support for it in noStrudel

Could probably use some help getting this ported and supported in device firmware although I'm hoping for even dumber devices than ESP32. https://www.vaughnnugent.com/resources/software/modules/noscrypt

They will with NVault eventually https://www.vaughnnugent.com/resources/software/modules/NVault

I'm an advocate for less browser system integration for less attack surface. I believe there is a good reason Moz doesn't and won't support it.

That is what I mentioned in my post as not a shitty ESP32

localhost websockets

i wouldn't trust mozilla and their can't disable widevine nag as far as i could kick a bowling ball

Yes!

looking forward to testing this thing, it's a definite pain point for nostr

didn’t get the pgp key + email yet though or signal

NIP-04 and the likes work (not that they are good, especially gift wraps) but they have no post compromise security

ya know, i don't even understand what that means as in, they get your key out of the breach? i mean, once you grasp that simple part of it how do you propose to change the nostr protocol so identities aren't tied to public keys? needs a broadcast protocol for identities, so you can roll them over without losing your central identity secret key another protocol, and that protocol has to be integrated into the clients so they refer to this separate protocol to look for current identity

actually, wrong term I meant forward security post compromise security is interesting, but it is not applicable in nostr

yes, these terms are not easy to understand and rarely well explained forward secrecy literally means that you can encrypt a message in a way that could not be predicted by an adversary usually such schemes involve using a seed value to derive a hash based on some temporal value, usually the time alone is sufficient it's my firm opinion that the field of cryptography and signals security have a long way to go in building adequate models to make this understanding accessible too many engineers, not enough teachers (i'm probably more teacher than engineer)

also, i appreciate this point: post compromise security is irrelevant in a system with persistent identities, only forward security matters

yes, the only case it could work with unnecessary complexity is where you use a remote signer, each client maintains state locally, and you remove a client in this case you can also do the following which is easier: rotate the secret used for encryption

post compromise recovery requires key rotation and really should have a context of a connection the point about the stable identity is part of the problem, to do post compromise with nostr you have to add a new form of temporary identity called a conversation... the identity is revealed to participants in the process but it is not the identitity that is maintained during it so, yeah, it depends a lot on client state and that's why all the signals and whatsapps and sessions and suchlike are in a shambles, and i don't think MLS fully solves the problem, it does provide a mechanism for maintaining per-discussion identity but it doesn't deal with the "and then" part of it

the only solution for this relates to relays holding state data, btw and i've been saying this for quite some time, that relays should be able to be trusted to hold state data part of the issue then is really about clients having a deterministic keychain as this is the only way to keep the data across instances without actually explicitly storing it on the client