Maintain Consistent Sender Identity for Email-to-Nostr Conversion #1

New issue

Closed

opened 2024-12-02 13:41:15 +00:00 by dannym · 0 comments

dannym commented

2024-12-02 13:41:15 +00:00

Owner

Currently, the server generates a new nsec for each email-to-letter conversion. This results in different ```npub`` identities for the same email sender.

Proposed Solution:

Implement a Key Derivation Function (KDF) to generate consistent nsec keys for each unique email address. The KDF should:

Use the sender's email address as input
Combine it with a server master nsec as a seed
Always produce the same nsec for the same email address

Benefits:

Maintains consistent sender identity across all Letters
Improves message threading and user experience
Enhances security by making email spoofing detectable (if an email from user@domain.ext appears with an unexpected npub, it's likely fraudulent)

Potential Concerns:

This approach creates a centralization concern, a dependency on a single server's KDF implementation. However, this could be mitigated through Web of Trust:

Even if an email arrives with an unknown/different npub, it could be considered valid if trusted contacts in the user's WoT have verified that email-to-npub mapping
This would allow for multiple email-to-Nostr gateways while maintaining trust through social verification

Currently, the server generates a new ```nsec``` for each email-to-letter conversion. This results in different ```npub`` identities for the same email sender. ### Proposed Solution: Implement a Key Derivation Function (KDF) to generate consistent ```nsec``` keys for each unique email address. The KDF should: - Use the sender's email address as input - Combine it with a server master ```nsec``` as a seed - Always produce the same ```nsec``` for the same email address ### Benefits: - Maintains consistent sender identity across all Letters - Improves message threading and user experience - Enhances security by making email spoofing detectable (if an email from user@domain.ext appears with an unexpected npub, it's likely fraudulent) ### Potential Concerns: This approach creates a **centralization concern**, a dependency on a single server's KDF implementation. However, this could be mitigated through Web of Trust: - Even if an email arrives with an unknown/different npub, it could be considered valid if trusted contacts in the user's WoT have verified that email-to-npub mapping - This would allow for multiple email-to-Nostr gateways while maintaining trust through social verification