════════════════════════════════════════════════════════════════════════════════
 Node 1  ·  2400 baud  ·  40 msgs in 6 areas  ·  sysop randogoth
════════════════════════════════════════════════════════════════════════════════
════════════════════════════════════════════════════════════════════════════════
 Msg  : smolmail-implementations                     Area : MINIMAL
 From : randogoth                                    Date : 11 Oct 2026
 Subj : The Address Is the Pin Keys : smolmail, rust, reticulum
 Msg  : smolmail-implementations
 Area : MINIMAL
 From : randogoth
 Date : 11 Oct 2026
 Subj : The Address Is the Pin
 Keys : smolmail, rust, reticulum
════════════════════════════════════════════════════════════════════════════════

The smolmail intro 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, 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 · fumi

--- RANDOGOTH BBS
 * Origin: randogoth.com (1:1/1)
────────────────────────────────────────────────────────────────────────────────
 [I]ndex   [K]eywords   [F]eed   Main [M]enu   
Command: