Talk without code is just talk Just published the in-progress code for nvelope-core library on github. It is raw and a work in progress. https://github.com/StevenDay83/nvelope-core #nvelope #nostrmail

Some examples of nVelope profiles in the wild (published on wss://relay.damus.io) Recipient Profile: nVelope Public Key: Blinded envelope: Decrypted Message: #nostrmail #nvelope

When you view Nostr as a general purpose API, the possibilities are endless. The trade off is the additional logic has to be layered on. What other protocol or system lets you post arbitrary text data?

How nVelope's nostr mail will handle privacy and security with Blinded Envelopes: Blinded Envelopes Blinded Envelopes are the only method to send Direct and Special Direct messages to recipients. Blinded Envelopes provide the following functions: Encryption: All Blinded Envelopes are encrypted using the recipients public key. This ensures that the contents of Direct and Special Direct message contents are not read by anyone except the holder of the certificate private key. The contents in the Blinded Envelope will be encoded in Base64 for compactness and compatibility purposes. Privacy: Blinded Envelopes are "Blind" because these events can and should be signed by a random Nostr keypair. Only the sender will know which event was signed and only the recipient will be able to process through any listed Blinded Envelopes to find the one intended for them. This ensures that no metadata, such as sender and receiver are leaked when writing the event to a relay, which is publicly accessible. This also prevents any nsec key leaks from further compromising any prior communications. Proof of Work: Proof of work, mentioned earlier will only be applied to the Blinded Envelope level. The underlying event containing Direct or Special Direct Message data will not require any POW constraints. The sender would need to process the Blinded Envelope event with the an event ID that satisfies the recipient POW requirements. There are tradeoffs to using Blinded Envelopes that will place some burden on Nostr-Mail clients. All metadata is hidden and there is no way to determine whether a message is for a certain recipient without attempting to decrypt the message. This means that a Nostr-Mail client could spend more time trying to process messages if there are a high amount of Blinded Envelopes on a relay. Attackers can generate throw away events that will increase the amount of messages a client would need to process. To counter this, a POW Global Filter would always be recommended as a hurdle to any would-be attackers from generating millions of events instantly. #nostrmail #nvelope

On components of a nostr-mail profile and proof of work as a filtering mechanism: Nostr-Mail profile Just as Nostr users may have a Nostr profile (Kind 0) to provide information such as a avatar picture, reference name, etc, a Nostr-Mail profile extends this to Nostr-Mail specific data for interacting with the protocol.A Nostr-Mail profile is composed of the following: Public Certificate: This is the "public key" used by sends to encrypt messages intended for the user. A corresponding Private Certificate is stored safely by the user to decrypt emails sent to them. Recipient Policy: This is the policy the Nostr-Mail user has defined for which Nostr are allowed to send messages to the recipient as well as other constraints like Proof-of-Work minimums. Global Filter: Proof of Work minimum for all senders. This is designed to reduce the burden of a recipient's Nostr-Mail client in which messages to attempt to process.

Thanks for the reminder. Should be all set!

Excerpt from Nostr-Mail white paper Problem Current methods of direct communication with Nostr are either opt-in open, such as with social media (Kind 1) use cases, or using previous designed Direct Message NIPs that leak metadata and exposes communications in the event of a nsec key leak. Kind 1 posts and Direct Messages have legitimate use cases and there is a gap in Nostr for secure messaging in an email format. Current email technology (SMTP mail) is currently in a very centralized state where a handful of operators control the vast majority of accounts (i.e. Gmail, Microsoft, etc). Many email operators require some form of KYC to combat spam and identify users. Setting up a self-hosted email server runs into many pitfalls of security and unreliability. Spam and malicious emails are a constant threat since SMTP is designed to allow impersonation, despite multiple additions to combat these problems.

Removing the middle men platforms and making the platform you! #nostrmail #nvelope

Why recreate something “boring” like email on Nostr? DMs are great for quick exchanges. DMs manage a single conversation vs separate threads. Good luck really trying to search DMs for info over a long period of time. They have their place and are great. Email represents a more “personal media” vs social media approach. “Boring” is fine if it can be safe, secure, and user owned.

The original layout of the email-over-nostr protocol. Some things are changing out of practicality. Worth the read and always open to feedback and suggestions.

The best way to fix email is to dump the existing system. One way to do this is to use Nostr and make long form non-DM communication over Nostr. No centralized email platforms, just cryptography, proof of work, and the decentralization of the Nostr network. nVelope will be that email client that will balance secure, private, personal communication with an intuitive UX. More to come.