nips
nips copied to clipboard
nostr-protocol
Create NIP for mail events
I write this NIP for creating a new kind of structure direct message as i was suggested in the issue #83 . I make this proposal for discuss the best way of doing this structured events
yes, thats why i thought would be more appropieta to specify a structure or soemthing. the idea is that chat apps dond show mail events and mail apps dont show chat events. Also devs could imagine new structures that dont fit on these.
we already have a subject tag, why not simply add that tag to a kind-4 but encrypted like the content, then you decrypt both, you don't need the structure and clients that don't support the encrypted subject will ignore as it's not needed
The problem is that chat apps will show mail messages and the mail clients wills how chat mssages. I feel that they are not the same, but if it is what i should do i will do it.
The problem is that chat apps will show mail messages and the mail clients wills how chat mssages. I feel that they are not the same, but if it is what i should do i will do it.
why are they not the same? what's the difference other than the UI abstraction?
for me these messages has not the same context, i dont want to receive on my gmail small messages as good morning, how are you etc. For that u use whatsapp or signal. A mail is used in other context, more polites maybe. For me is more than just a UI asbtraction, is a way of comunication, if they were the same people would just use gmail as a message app.
Another option will be have keys for chat apps and keys for mail apps, maybe it a bit annoying for users idk. What do u think?
for me these messages has not the same context, i dont want to receive on my gmail small messages as good morning, how are you etc. For that u use whatsapp or signal. A mail is used in other context, more polites maybe. For me is more than just a UI asbtraction, is a way of comunication, if they were the same people would just use gmail as a message app.
what prevents anyone from sending you events in this format but like it was a chat? the format doesn't change anything if it doesn't impose a structure, you can also receive a bunch of these saying hello sir
Ofc the format didnt change anything, that the reason i ask for an extension of the nip 5. For setting the intention of the messages. People can send small mail for saying hello sir but they dont use to, the prefer other ways, thats the idea. Dont make a mess of messages with different scopes.
The main difference is not the structre, is the intention and the scope of the message, it is not a tech dif, is a language context diff.
kind-4 already goes out of the way and makes it a direct communication avenue, it's exactly what you want. the intention is irrelevant if sending a kind-4 or kind-44 if the rest in unchanged, but that's just my perspective, feel free to use a different kind for that, but the key points of nostr is interoperability, so you can levarage existing apps that already talk the same language, if you're creating a new kind just for yourself, you can, but what would be the reason for anyone else to use your different format if they can already talk to each other?
Sure, i understand your point and see the advantages of it. We can let this pr open for a week to see more peolpe opinions and then we can close it.
I make some updates on the nip, i think now is different from the dm, cuz it has more functionalities (set category, mark if read, etc) If someone want to add something will be helpful.
Im also valuing using shared secrets #59. The idea would be have a shared secret or group chat as mail thread, but maybe a user will have a lot of keys to manage.
something I've always wanted is a more general nip04 that has encrypted tags and maybe even encrypted kinds. you could even retain queryability by hashing the shared secret into the tag value: {kinds: [444], #k: sha256(shared_secret, 7)} that way you could create reactions to dms, etc.
Maybe add email-specific metadata (subject, for example) as a tag, then your email client will only show messages containing that?
That was mi initial idea with issue #83, I propose to set a few tags for specifying some kind of encrypted messages. I explained the idea bad :(
something I've always wanted is a more general nip04 that has encrypted tags and maybe even encrypted kinds. you could even retain queryability by hashing the shared secret into the tag value: {kinds: [444], #k: sha256(shared_secret, 7)} that way you could create reactions to dms, etc.
even more general:
{kinds:[444], #g: [sha256(shared_secret + "kind" + 4), sha256(shared_secret + "p" + "pubkey")]}
but this doesn't work because it is eqivalent to [REQ,"",{#p: pubkey}, {kinds: [4]}], which is an OR query and not what we want. It would be nice if we had a way to do AND in generic tag queries.
EDIT: nm I dont think this works, because there is more than one way to query a pubkey. maybe it does somehow, but would have to think a lot more on how this would work.
waiting for @Semisol to take this idea https://github.com/nostr-protocol/nips/pull/84#issuecomment-1332799070 and make it work
@arejula27 if it helps I had implemented an SMTP to Nostr Gateway using NIP-04: https://github.com/Cameri/smtp-nostr-gateway
In my implementation the event's content field somewhat follows the DATA format of RFC 821:
From: sender@domain
To: pubkey@domain
Subject: hallo
SBF was a fraud
I think you could consider keeping content the same way as in the RFC instead of wrapping it inside JSON.
I think I will be implement the client as kind 4, cuz every one looks agree with that. @Cameri the pubkey on the content is redundant, there is a reason for it or just following the format? Do you think is convenient?
I think I will be implement the client as kind 4, cuz every one looks agree with that. @Cameri the pubkey on the content is redundant, there is a reason for it or just following the format? Do you think is convenient?
I was following the DATA command as in the RFC. It's not redundant since the To: field can contain a petname and more than one recipient.