Elements of a #nostrmail client i am planning in Damus Mail:
- encrypted, private, no metadata (giftwraps)
- threaded (nip10)
- titled threads (subject tag)
- to,cc,etc (sent to the npub’s inbox relays)
- replaceable event that refer to the “state” of a given thread: is it archived, labels, etc. archived threads don’t appear in inbox
This should be a solid foundation for a nostr mail client, and it could also provide an interface to nip17 dms as well.
TY Will for being you 🌹
👀
Will it be interoperable with traditional email? That could be huge
I’m just focusing on a good nostr mail experience but I’m sure someone could make a bridge, although i imagine it would be janky bridge email
👏 👏 👏 👏 👏
But could non-nostr mail users still communicate, or will it be more like Bote?
You can always communicate via bridges. Its on open network. What is Bote?
nostr:nprofile1qqs99d9qw67th0wr5xh05de4s9k0wjvnkxudkgptq8yg83vtulad30gpzpmhxue69uhkummnw3ezumrpdejqz9thwden5te0dp5hxapwdehhxarj9ekxzmnyqyv8wumn8ghj7un9d3shjtnwdaehw6r9wfjjucm0d5eechmk we need to upgrade Nostr Plebs email 😂
I don’t think he likes giftwraps
He doesn't 😩
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
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
Yeah that’s true. I still want mail on nostr though
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.
Im slowly catching up to nip17 and giftwrap stuff so pardon if this idea has already been discussed and is bad.
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.
This is a lot different than what i was thinking of, i wasn’t trying to solve the metadata leak
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.
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.
It's a DM-specific solution to what nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3xamnwvaz7tmhda6zuat50phjummwv5hsx7c9z9 was trying to do with decoupling encryption and identity: https://github.com/nostr-protocol/nips/pull/1647
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)
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
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.
that is also how most non-nostr e2e message encryption specs work, but also with FS
⚡⚡⚡⚡⚡
This is the way William.
Awesome !!! Definitely down for this !!!
Sounds sick!
This was something I was planning on doing last year but kids and other commitments.
One thing I also thought about for a nostr mail protocol was:
- Nostr mail “profile” event that has a separate public key
- layers of trust for receiving mail
- proof of work used to prevent spam with a global minimum and potentially higher pow for “strangers”
I wrote a whole concept on this and best of luck on putting something together.
🔥
Pardon my ignorance, but I don't get it. Is this going to interact with SMTP? Or is it just a mail system for within nostr?
Sir William..always ahead 🫂
Does it overcome the privacy problems I have heard nostr itself still has?
giftwraps solve a lot of privacy problems yeah
