Nostr Web Client

yeah because they don’t do fuck shit in terms of privacy

leaked your nsec accidentally? all your emails are public still

show me an encryption spec with forward secrecy or the best option is to provide a revocable link to view the email

I mean this is the same issue if someone gets your email password and downloads your mail? On nostr you just get a new key and update your nostr address, you could have the inbox relay(s) disable the account (prevent future auths from the key), maybe we could spec that.

I mean i think this is already better than current email where noone expects any privacy or message security at all, obviously would prefer forward secrecy if a spec for that existed and isnt crazy complicated. Maybe there could be an upgrade path eventually

Reply to this note

Please Login to reply.

Discussion

semisol 1y ago 💬 2

Except email accounts can have 2FA, they do not share the same credentials as your social media account and that one random app you signed up for, and there are other protections that Nostr does not and cannot offer by design

jb55 1y ago

Yeah that’s true. I still want mail on nostr though

jb55 1y ago 💬 3

Random thought: what if each device you use creates a device key, you then update a key list that you publish from your root key. Then giftwraps could send to each key on that list instead. nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

If your root nsec leaks then your messages aren’t compromised? and you would never be copying around these keys so maybe they could be more resistant to people pasting them somewhere and leaking them.

You have issues with needing to send many giftwraps though… but maybe not an issue once inbox relays are more widely used.

jb55 1y ago

Im slowly catching up to nip17 and giftwrap stuff so pardon if this idea has already been discussed and is bad.

Vitor Pamplona 1y ago 💬 2

It's very clear to me that people do not want device keys. They want to reply in all chat-supporting clients.

Simplest version is with key aliases below, but managing keys them across multiple apps/devices is quite complicated. Lots of race conditions.

Key rotation is solved though. You can just reencrypt all wraps you received by yourself, without participation of each peer, which you cannot do with nip04 and other encryptipn mechanisms.

https://github.com/nostr-protocol/nips/pull/1306

jb55 1y ago

This is a lot different than what i was thinking of, i wasn’t trying to solve the metadata leak

Vitor Pamplona 1y ago 💬 2

Agree. The PR as proposed is just for metadata (I was trying to keep it simple) but we could change it to do the encryption as well, solving both issues at the same time.

jb55 1y ago 💬 2

This is cool in the sense you can have a mode where you have to establish a link before you can start communicating, this is something nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj tried to do awhile back but this appears to achieve the same thing? Just send a giftwrap of key aliases to the user to let them know how to contact you. Neat.

Vitor Pamplona 1y ago

It's a DM-specific solution to what nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 was trying to do with decoupling encryption and identity: https://github.com/nostr-protocol/nips/pull/1647

Vitor Pamplona 1y ago 💬 1

Maybe there is a broader way to do all nostr encryptions via aliases, but I don't see it yet (a use-case-agnostic scheme gets too complicated too quickly)

jb55 1y ago

One thing at a time i guess, i can at least wrap my head around and design around the more focused usecase of alias keys in nip17

We should definitely be moving toward device keys across the board

jb55 1y ago

Also resending this alias list would be the similar thing on signal: “user changed their safety number”

If your root npub leaked and the attacker tried changing the keys, you would see this.

semisol 1y ago

that is also how most non-nostr e2e message encryption specs work, but also with FS