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.
Replies (44)
DOPE
Why is everything weed with you?
🤣
Huh???
really? I wanna try it 🔥
I want to try it too. Just exist in my head at the moment.
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?
I don’t think he likes giftwraps
He doesn't 😩
Bote is a messenger based on the I2P network that only allows communication between other users. Also, the email addresses were always long strings of text instead of your standard email.
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
Yeah its more like bote, but could build a bridge to email with nice ux for that
nip10 is ass
I think its fine
⚡⚡⚡⚡⚡
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.
🔥
I missed this, it’s finally becoming a thing? 🥰
yup
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?
just a mail app within nostr for managing async communications (really just a design thing with pinning notes in an inbox and having archival states, etc), but a bridge to email would be cool
Thanks for the explanation. I'm rooting for you!
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.
@Vitor Pamplona
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.
GitHub
Adds key aliases to NIP-17 by vitorpamplona · Pull Request #1306 · nostr-protocol/nips
A simple way to:
Remove the final metadata leak from NIP-17 (the public key of the receiver is on the gift wrap)
Distribute a stream of messages t...
that is also how most non-nostr e2e message encryption specs work, but also with FS
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
@semisol 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.
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.
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
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
message in a bottle(colored glass)/*****)}NA c thru/* t y/).....Will C. ..... _luv/* nostr
