Definitely. Alias is for increasing privacy, so we need strong guarantees.
The current plan for increasing privacy:
1️⃣ Open-source, so you can verify the code
2️⃣ Emails are stored as Private DMs, so encrypted
3️⃣ Your data is stored on nostr, so you can anytime move
I see 2 biggest problems now:
1️⃣ Smtp receives the emails in plain text
2️⃣ If your private key is compromised, your email history is compromised
The 2️⃣nd is a general nostr problem, so probably we get to use a solution, or I will think about one, if the base is ready.
The 1️⃣st seems kind of the toughest on the trust side, because you have to trust the smtp server relaying your mails onto nostr. As the rest is already happening behind private messaging/data storage on nostr.
I want to solve first the 1️⃣st problem.
Until that, if I release, source code can be verified, and smtp code will be small, so easy to verify.
Also I don't plan to read/associate or scan emails. This means spam filtering has to be solved on the user side, as usual on nostr. And because smtp code will be small, it will be easy for you to verify that no reading or so happening there.
But I want to minimize the trust further, but not yet know how. Maybe somehow I shall host the smtp servers for the users, therefore, they always control how their emails are relayed.
Crusty 👨💻
npub1ry…e5a5f
2024-07-25 18:36:10
in reply to nevent1q…2t6s
Author Public Key
npub1ry5wud2c748rzexcr5nvxhsj8sj5htsjsd2dwcta0lvx94cdng4s8e5a5fPublished at
2024-07-25 18:36:10Event JSON
{
"id": "0c3b311e1cb3835d2a3f319b4f51e5896d10f73e1bc5c4420ac41ec35d035746",
"pubkey": "1928ee3558f54e3164d81d26c35e123c254bae128354d7617d7fd862d70d9a2b",
"created_at": 1721925370,
"kind": 1,
"tags": [
[
"e",
"8bcfc7c27d34309f0355b16495cef95d8e46e88b72e4f77c9a1d842b6a93c2e0",
"",
"root"
],
[
"e",
"09ec426583e0379d561f36206088031dc65cdf900964939f73a86e2060139b63"
],
[
"e",
"ec9fc3798ee8b15645f70c666c53d0ab9f8728a5ffd670528fcf015cfc4cc2fc",
"",
"reply"
],
[
"p",
"1928ee3558f54e3164d81d26c35e123c254bae128354d7617d7fd862d70d9a2b"
],
[
"p",
"726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11"
]
],
"content": "Definitely. Alias is for increasing privacy, so we need strong guarantees.\n\nThe current plan for increasing privacy:\n1️⃣ Open-source, so you can verify the code\n2️⃣ Emails are stored as Private DMs, so encrypted\n3️⃣ Your data is stored on nostr, so you can anytime move\n\nI see 2 biggest problems now:\n1️⃣ Smtp receives the emails in plain text\n2️⃣ If your private key is compromised, your email history is compromised\n\nThe 2️⃣nd is a general nostr problem, so probably we get to use a solution, or I will think about one, if the base is ready.\n\nThe 1️⃣st seems kind of the toughest on the trust side, because you have to trust the smtp server relaying your mails onto nostr. As the rest is already happening behind private messaging/data storage on nostr.\n\nI want to solve first the 1️⃣st problem.\n\nUntil that, if I release, source code can be verified, and smtp code will be small, so easy to verify.\n\nAlso I don't plan to read/associate or scan emails. This means spam filtering has to be solved on the user side, as usual on nostr. And because smtp code will be small, it will be easy for you to verify that no reading or so happening there.\n\nBut I want to minimize the trust further, but not yet know how. Maybe somehow I shall host the smtp servers for the users, therefore, they always control how their emails are relayed.",
"sig": "b434f051b3e8f10c35142ae27b6c2a8eb8cfeae0ee13af4380e62bd9d3123f537f29cdf0e8dafac9e2c6781123932f56e8c8581e3671f79ddbab53e65bc1ba52"
}