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

docs: unified smolmail

Browse source
This commit is contained in:
randogoth 2026-09-30 08:47:11 +03:00
parent bd9bcf1076
commit 864daa0bad
8 changed files with 12 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

6
SPEC.md
View file

@ -1,6 +1,6 @@
<!-- SPDX-License-Identifier: CC-BY-SA-4.0 -->
# Smol Mail Protocol, version 1.2
# smolmail Protocol, version 1.2
A minimalist, decentralised, end-to-end encrypted mail protocol.
@ -375,7 +375,7 @@ RNS facts cited below were read from Reticulum 1.5.4. Constants in that stack ar
### 13.1 Server destination
A server holds one **Reticulum identity**, persisted, separate from every Smol Mail identity in §2 and never used as one. RNS writes its private key unencrypted, so the file MUST be protected as any long-term server key is: mode 0600, backed up by the operator, never transmitted.
A server holds one **Reticulum identity**, persisted, separate from every smolmail identity in §2 and never used as one. RNS writes its private key unencrypted, so the file MUST be protected as any long-term server key is: mode 0600, backed up by the operator, never transmitted.
```
RNS.Destination(identity, IN, SINGLE, "smolmail", "server")
@ -471,7 +471,7 @@ A mailbox reachable over both transports has one queue, and §6.1 requires a rec
The per-IP connection and `SEND` limits of §10 have no analogue. Reticulum gives a server no stable handle on an initiator that does not identify itself, and that is the point: a sender is absent from the wire format by construction (§5.2), and a transport that reintroduced a durable sender identifier would undo it.
- A server MUST NOT require Reticulum link identification for any operation. It proves a Reticulum identity rather than a Smol Mail one, and a durable one is exactly the handle this section says a server must not have.
- A server MUST NOT require Reticulum link identification for any operation. It proves a Reticulum identity rather than a smolmail one, and a durable one is exactly the handle this section says a server must not have.
- A server SHOULD limit requests and bytes per link, and cap concurrent links. Reticulum enforces neither.
- A server SHOULD keep a global `SEND` ceiling in place of the per-peer one.
- The per-accept-token `SEND` limit of §10 is unchanged and becomes the main defence. It never needed a peer identity: a token is issued by the mailbox owner (§5.8), which is exactly the handle this transport still has.