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

feat: add smolmail-implementations devlog post

Browse source
This commit is contained in:
randogoth 2026-10-11 16:35:05 +03:00
parent a873ef23ea
commit f14a11791d
1 changed files with 22 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

22
randogoth.com/content/smolmail-implementations.md Normal file
View file

@ -0,0 +1,22 @@
Title: The Address Is the Pin
Date: 2026-10-11 16:35
Category: MINIMAL
Slug: smolmail-implementations
Summary: Post 2 of 4 in the smolmail series. bunshin and fumi, a real Rust server and client, talking to the Python reference in both directions, over a second transport that needs no key to pin at all.
Tags: smolmail, rust, reticulum
The [smolmail intro](https://randogoth.com/smolmail.html) said the reference implementation would not stay the only one for long. It did not. There is a real server now, a real client, and a second transport that needs no key at all.
**bunshin** is the server. It started as a TCP implementation of the protocol and picked up a second carrier along the way: the [Reticulum Network Stack](https://reticulum.network/), a mesh networking layer built for radio links rather than the internet. Run `bunshin serve --rns` and the same mailbox answers on both carriers at once, one database, one identity. The addressing is the detail I like best. On TCP you pin a server's Noise static key once, out of band, the way you would memorize a fingerprint. On the mesh carrier there is nothing to pin, because the destination hash you dial *is* the key. The address and the identity are the same sixty-four bytes.
**fumi** is the client, and the part of it that matters more is underneath the client: `fumi-core`, a library with no argument parsing, logging globals, or keyfile conventions, meant to be linked directly. Anything that wants a GUI on top of *smolmail*, a desktop app or a phone app, builds on this instead of reimplementing the protocol. It is already true: everything coming in the next post sits on *fumi-core*.
The thing upstream promised and nobody had actually tried yet was a mailbox that does not care which carrier a message arrived on. Send over TCP, fetch over the mesh, same inbox. Getting there took a server-pin rule that sounds overcautious until you think about why it exists: the default port inherits whatever key a bare hostname was already pinned to, but any other port starts from trust-on-first-use, never falling back to its sibling's key. A lying DNS record can only ever cost you a wrong dial hint, never a wrong pin.
I will take the small honest moment here instead of skipping it. *bunshin*'s original rate limiter used a fixed window, the kind that quietly admits almost double the configured rate right across a window boundary. The *smolmail* reference audit flagged exactly that as a production-readiness gap a few days ago. *bunshin*'s rate limiter is a sliding window now, and a TCP connection cap went in alongside it. The finding did not sit in a report, it became a fix in the next repo over.
Two implementations now, neither of them the one that proved the spec was coherent in the first place, both of them talking to it anyway, in both directions, over whichever carrier is actually reachable. That is a better test of a protocol than the reference ever could be on its own.
## Repository
[bunshin](https://code.randogoth.com/randogoth/bunshin) · [fumi](https://code.randogoth.com/randogoth/fumi)