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 <noreply@anthropic.com>

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.