randogoth/smolmail
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: cleaner and more consistent text

Browse source
This commit is contained in:
randogoth 2026-09-29 22:30:01 +03:00
parent e4b429b390
commit 9677ea7c5c
4 changed files with 133 additions and 212 deletions
Download patch file Download diff file Expand all files Collapse all files

60
FAQ.md
View file

@ -1,67 +1,31 @@
# FAQ
Answers to questions that come up but aren't spelled out elsewhere.
Answers to questions that come up but are not 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.
Adding a contact through a `smol://` link is safe to get wrong. The worst case is that you add the wrong person, and 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.
Trusting a mail server carries more. Once you trust a server, it is allowed to act on your behalf: register your address, hand you your mail, delete it. A server therefore has to reach you through a channel you actually control, such as someone telling you in person, a message from someone you already know, or a company handing you the address directly. A clickable link is not such a channel. If server trust worked via links, anyone could send you one that quietly switches which server you trust, and you would 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.
Adding a server is a manual, deliberate step. It is 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.
It does, kept separate as an optional annex ([WS.md](WS.md)) rather than built into the core protocol.
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).
The core protocol talks over a plain, minimal connection with nothing attached: no certificates, no expiry dates, nothing to configure. A WebSocket is needed only because browsers cannot open that kind of connection directly, and because some networks pass only the traffic websites use. Baking WebSocket support into the core would mean baking in everything that comes with it, web certificates and browser security rules, none of which the mail protocol needs, and none of which takes part in how it decides what to trust. Trust is still 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.
The WebSocket support is instead a small side process that sits beside a mail server and passes the same data through unchanged. It holds no keys and does not need to understand mail. It is a pipe, not a participant, and a server that does not run it remains 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.
This mirrors the delivery method over the Reticulum network (SPEC.md §13): an alternate way to reach a mailbox, kept outside the core 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.
Because you have not approved that person yet. That is 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.
A mail server cannot see who is sending you mail, only that something arrived. Without a way to tell someone you know apart from a stranger or spam, anyone who knew your address could flood your mailbox. Mail from anyone you have not approved therefore goes to 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.
To fix this for someone, approve them. The reference client's `accept` command does this in one step, and replying to them has the same effect. From then on their mail goes to your main mailbox, and withdrawing your approval with `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.
There is no way to skip this for a first message, and that is the point. Your server can tell approved senders apart from everyone else without ever learning who any of them are, and that is what keeps your mailbox both usable and private.