spec.txt (1817B) - raw
1 Nanomail ideas 2 ============== 3 4 A lighter-weight email replacement 5 6 Deliberitly limited in scope for personal, text-based communication 7 8 Server runs on port 1999 9 10 Strucure of a message 11 --------------------- 12 13 nanomail messages look a lot like email, but without the 50 years of annoying junk 14 15 mail messages have a fixed set of exactly 4 headers: 16 17 Signature: abcdef123 18 From: sally@example.com 19 To: bob@gmail.com 20 Subject: My Email 21 22 Followed by an empty newline, then the body of the email. 23 24 Header values cannoy contain newline characters. 25 26 Email addresses must be of the format: 27 28 [some-text]@[valid URI] 29 30 The body consists of gemtext-formatted text. See the Gemini specification. 31 32 => https://gemini.circumlunar.space/docs/specification.gmi 33 34 Signatures are (....?) Something along the lines of HTTP signatures https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12#section-2.1.3 35 36 Sending mail 37 ------------ 38 39 Like SMTP 40 41 No multiple recipients here. Think like physical mail 42 43 Client request: 44 45 SEND 46 Signature: abcdef123 47 From: sally@example.com 48 To: bob@gmail.com 49 Subject: My Email 50 51 Hello bob. Thanks for reading my email. 52 53 gmail.com then makes a request to the nanomail server at example.com (if it doesnt have the key already): 54 55 GETKEY sally 56 57 Which fetches the public keyy and validates the signature. 58 59 If key validation works, server will respond OK, else some error code 60 61 status CODES: 62 63 20 OK 64 40 INVALID REQUEST 65 41 USER DNE 66 51 SIGNATURE INVALID 67 68 etc 69 70 Pulling mail (client-server) 71 --------------------------- 72 73 Like POP 74 75 FETCH sally [signature] 76 77 Returns messages if there are any. Each request returns a message, or DONE 78 79 Handling spam 80 ------------- 81 82 no one will use this, so no worries about spam. If they do, consider a server 83 allowlist or blocklist (like how fediverse handles these things)