*** Eugene Medvedev [2025-10-04 20:51]:
>Initially, I actually wanted to send attachments separately.
>Further meditation on security eventually disabused me of this
>notion. :)

I also think that it will complicate things.

>I also considered using CBOR as the envelope format,
>but then realized it probably breaks the "implement in bash on a
>potato if you have to" constraint.

And again my humble opinion, that it is better to stick with MessagePack
or maybe Netstrings (http://cr.yp.to/proto/netstrings.txt). But you
already introduced separate index of attachments, that is also simple
and does not require binary encoder.

>Gemtext holy wars have been raging in the smol web since its
>inception. :)

Seems so. I am the person who dislike the whole technical side of gemini
ecosystem. But I am still glad people trying to use *relatively* (oh
that gemini:// TLS requirement!) simple solutions for communicating with
each other.

>Still, I feel it was the best available alternative for this
>particular application. I could potentially introduce a header
>field specifying that the rest of the body is to be rendered
>as plain text?

Well, it is your decision. I am afraid that those tiny steps could lead
to reimplementation of the MIME. The most hard thing is to stop at good
point of features and development :-)

>...But what about the cyrillic N? ;)

Actually I have never experienced problems with it, or seen someone has.
But I get in FidoNet when it was already declining, at the beginning of
2000s, with much mature software :-)

>1. Available in as many language's standard libraries as feasible.

If BLAKE2 is not so widely available (Go's crypto library does not have
it, for example, but golang.org/x/crypto had for a long time), then
SHA3/SHAKE in my opinion is much better choice. Just recently I
discovered that even BusyBox has "sha3" utility (but not SHAKE :-().

>2. Sufficiently collision resistant so that people don't casually try to
>forge messages.

That applies to all cryptographic hashes of course, except for found to
be broken and weak ones (MD5 and SHA1).

>3. Not too long when represented as text, so that the "ReplyTo: " line
>in the header doesn't slide off screen. :)

256-bits are enough, no doubts.

>1. Hash is only necessarily computed when receiving mail. There's
>hardly any reason to ever do it again. The average length of a
>message is not likely to ever exceed ~10 Kb, too.

Agreed. It is not so critical in all those use-cases.

>2. If this project achieves 100+ messages a month anywhere, I'll be
>extremely happy and go buy a lottery ticket or twenty.

Being the free software developer myself, understand you :-)

>SHA-512 was a bit too long (longer filenames, longer everything, and
>we get at least two layers - <group>/<msgid>...).

You can safely shorten its output, as often done in practice. ZFS does
that (one example immediately remembered). You get faster speeds on most
computers people use, but still can use only 256-bits of its output. I
also won't use full 512-bit output.

>SHA-256 seemed just right

Like BLAKE2b-256, BLAKE2s, SHA3-256, SHAKE128, or SHA2-512/2 :-)
But SHA3 is available in most (all?) libraries already. Nearly all
(completely all?) modern protocols which require NIST-approved hashes,
moved from SHA2 (to SHAKE or SHA3). If NIST is not required, then BLAKE2
is very popular choice too, that is why it was added to Python's hashlib.

>using base64 as per RFC4648, so this is what it uses now.

Yeah, that is convenient decision. In most cases I prefer exactly that
base64url too. In NNCP I choose Base32 because it looks nicer and still
is relatively short enough, but only because it is visible on file
system (however base64url is safe to use too).

-- 
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A