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>
3.3 KiB
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), 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.