From 1a269448f23309a4dc9f11239c598ec43c196aef Mon Sep 17 00:00:00 2001 From: randogoth Date: Tue, 29 Sep 2026 17:53:36 +0300 Subject: [PATCH] docs: add FAQ Collects answers to questions that aren't spelled out in SPEC.md, README.md or WS.md, written for a general audience rather than implementers. Co-Authored-By: Claude Sonnet 5 --- FAQ.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 FAQ.md diff --git a/FAQ.md b/FAQ.md new file mode 100644 index 0000000..8a3aa4e --- /dev/null +++ b/FAQ.md @@ -0,0 +1,67 @@ +# FAQ + +Answers to questions that come up but aren't spelled out elsewhere. + +## Why can't I just click a link to add a mail server, the way I can add a contact? + +Adding a contact via a `smol://` link is safe to get wrong: worst case, you +add the wrong person, but nobody can intercept your messages because of it. + +Trusting a mail server is a bigger deal. Once you trust a server, it's +allowed to act on your behalf — register your address, hand you your mail, +delete it. Because of that, a server has to be trusted through some channel +you actually control — someone telling you in person, a message from +someone you already know, a company handing you the address directly — not +a link that could show up in an email or a random webpage. If server trust +worked via clickable links, anyone could send you a link that quietly +switches which server you trust, and you'd have no way to tell. + +So adding a server is a manual, deliberate step, on purpose — never a link +you can be tricked into clicking. + +## Why does Smol Mail not have native WebSocket support? + +It does — but kept separate, as an optional add-on ([WS.md](WS.md)), not +built into the core mail protocol. That's deliberate. + +The core protocol talks over a plain, minimal connection with nothing extra +attached: no certificates, no expiry dates, nothing to configure. A +WebSocket is only needed because web browsers can't open that kind of plain +connection directly, and some networks only allow the kind of traffic +websites use. Baking WebSocket support into the core would mean baking in +everything that comes with it — web certificates, browser security rules — +none of which the mail protocol actually needs, and none of which is part +of how it decides what to trust (that's still just the server's key, exactly +as without WebSocket). + +So instead, the WebSocket support is a small side process that sits next to +a mail server and simply passes the same data through unchanged. It doesn't +hold any keys and doesn't need to understand mail at all — it's a pipe, not +a participant. A server that doesn't run it is still perfectly usable by +every other client. + +This mirrors how the separate delivery method over the Reticulum network +works too: an alternate way to reach a mailbox, kept outside the core +protocol so the core stays simple regardless of how people connect to it. + +## Why do new smolmails always end up in my Requests folder? + +Because you haven't approved that person yet — that's what the Requests +folder is for. + +A mail server can't see who's sending you mail, only that something +arrived. Without some way to tell "someone I know" apart from "a stranger +or spam," anyone who knew your address could flood your mailbox. So by +default, mail from anyone you haven't approved goes into a separate, +smaller Requests folder with limited retention, instead of your main +mailbox. + +To fix this for someone, approve them — the reference client's `accept` +command does this in one step, or simply replying to them has the same +effect. From then on, their mail goes straight to your main mailbox; +withdrawing your approval (`block`) sends them back to Requests. + +This is on purpose and there's no way to skip it for a first message: your +server can tell approved senders apart from everyone else without ever +learning who any of them actually are, which is what keeps your mailbox +both usable and private.