From e4b429b390e5dcf311276223db3bb673b68d69da Mon Sep 17 00:00:00 2001 From: randogoth Date: Tue, 29 Sep 2026 20:55:33 +0300 Subject: [PATCH] badges --- README.md | 42 ++++++++++++------------------------------ 1 file changed, 12 insertions(+), 30 deletions(-) diff --git a/README.md b/README.md index e761671..653611d 100644 --- a/README.md +++ b/README.md @@ -1,19 +1,21 @@ -# Smol Mail +# smol mail [![AI-DECLARATION: auto](https://img.shields.io/badge/%E4%B7%BC%20AI--DECLARATION-auto-ede9fe?labelColor=ede9fe)](https://ai-declaration.md) [![License: CC BY-SA 4.0](https://img.shields.io/badge/License-CC%20BY--SA%204.0-lightgrey.svg)](https://creativecommons.org/licenses/by-sa/4.0/) -[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0) +[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0) ![Powered by Mistral](https://img.shields.io/badge/Powered_by-Mistral_AI-FA520F?logo=mistral-ai&logoColor=white) -A minimalist, decentralized, end-to-end encrypted mail protocol. +A minimalist, decentral, end-to-end encrypted mail protocol. -Email should be simple again. Inspired by [Spartan](spartan://spartan.mozz.us/), [Misfin](gemini://misfin.org/), and [LXMF](https://github.com/markqvist/lxmf). Smol Mail reduces electronic correspondence to its essentials: an address, a key and a message. One keypair per user, five operations, one binary message format. No sprawling infrastructure, no proprietary accounts, no advertising, no tracking. Anyone can run a server, anyone can write a client, and only the intended recipient can read a message. +Online correspondence reduced to an address, a key and a message. -A server learns which mailbox a message is for, how big it is and when it arrived. Not the sender, not the subject, not the content. - -- **Minimal** — five operations, four primitives, no extensibility mechanisms. -- **Private** — messages are sealed and signed; senders are absent from the wire format. -- **Decentralized** — independent servers, no federation, no directories. -- **Portable** — identity is a keypair, not an account. +- Five operations, four primitives, zero extensibility mechanisms. +- One 32bit master key as the only identity. +- No certificates, no CAs, no expiry. One round trip and the server's key pin are the entire trust model. +- A fresh key seals every message: untraceable, unforgeable, and safe by construction. +- Anti-spam without censorship: quotas and tokens do the filtering; servers never see a word. +- Clients talk directly to the recipient's server +- Registration is bound to one server by proof-of-possession. +- Couble-signed certificate chains move a username to a new key, and old keys keep receiving until every contact catches up. ## Identity @@ -32,30 +34,10 @@ smol://alice@example.org/mfrggzdfmztwq2lknnwg23tpo… self-certifying, carries The short form is typeable. The long form carries the key itself, so an address shared by QR code, contact file or link needs no trust in any server at all. Either way, changing servers never changes an identity. -Keys learned from a server are pinned on first use. Later changes need a rotation certificate signed by both the old and the new key, or explicit confirmation. - -Recipients learn only the sender's key, never a name: a first contact arrives as a bare fingerprint until its address is known. A client may carry its full `smol://` address in a signed `Reply-To` field so first contacts can be answered; receivers bind it only when its key matches the message's signer (SPEC.md §5.7). - -## A mailbox nobody else can fill - -A server cannot see senders, so it cannot tell wanted mail from a flood, and without help anyone who knows an address could fill a mailbox to its quota. - -An **accept token** fixes that without telling the server anything. It is a 32-byte secret you derive per correspondent, hand to them inside a sealed reply, and upload to your own server. Their messages carry a MAC over it; your server matches the MAC and puts those messages in your mailbox proper. Everything else — a first contact, a stranger, a flood — goes to a small **requests** tier with a short retention, which your client shows separately. Accepting someone is one command, or just replying to them; withdrawing the token puts them back in requests. - -Your server learns from this how many correspondents you have accepted and which token a message matched, so a token is a stable pseudonym. It still never learns who is behind one (SPEC.md §5.8, §9). - ## Cryptography Ed25519 · X25519 · ChaCha20-Poly1305 · SHA-256. Four established primitives, no novel cryptography, nothing else anywhere in the protocol. Transport is TCP with a Noise handshake — no certificates, no CA, no expiry. -## What is not protected - -Traffic analysis, delivery timing, mailbox size, and whether a user has an account on a given server. Run a server as a Tor onion service for metadata resistance; the transport needs no changes for it. - -There is no forward secrecy on the recipient side: a seized recipient key decrypts ciphertext recorded while it was valid. Messages are signed, so they carry non-repudiation rather than deniability. - -Version 1.1 excludes attachments, group messaging, federation, anonymous routing, multi-device synchronisation and key revocation. - ## Reference server [smolmaild.py](smolmaild.py) is a complete server in one file. It declares its own dependencies inline, so there is nothing to install: