public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: Eugene Medvedev <rn3aoh.g@gmail•com>
To: nncp-devel@lists.cypherpunks.su
Subject: Re: gemtext (was: So I made a thing: nncp-echomail)
Date: Sat, 4 Oct 2025 20:51:11 +0300	[thread overview]
Message-ID: <CAO-d-4pRXKK7OuvKPM-yR4PuZXt7bWBEnkLdVc_kbvL4ZtVKEA@mail.gmail.com> (raw)
In-Reply-To: <aOFRzMs8JFq64nGj@stargrave.org>

On Sat, 4 Oct 2025 at 19:58, Sergey Matveev <stargrave@stargrave•org> wrote:

> I liked the idea of <msgid>/<filename> links!

Initially, I actually wanted to send attachments separately.
Further meditation on security eventually disabused me of this
notion. :) 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.

I really don't want to be the only guy writing a mailer. :)

> Personally I dislike gemtext very much, because it is *not* human
> readable.

It certainly has problems, most of them stemming from the fact
that it was explicitly designed to be machine readable as easily
as possible. It's a replacement for HTML, not Markdown, and not
a very good one at that.

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

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? This might even work with the indexer as is,
as long as text messages are then saved into ".txt" instead of
".gmi" (so that they get the text mime type) and the index
links match...

> Both MUAs and FTN message editors generally just show the plain text
> they got from email or netmail message. That plain text is immediately
> can be read/consumed by the human.

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

> By the way, just curious, why you used SHA-256 as a hash?

I am not a cryptographer. :) I needed something that fit those properties:

1. Available in as many language's standard libraries as feasible.
2. Sufficiently collision resistant so that people don't casually try to
   forge messages.
3. Not too long when represented as text, so that the "ReplyTo: " line
   in the header doesn't slide off screen. :)

I don't think performance is a serious consideration:

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.
2. If this project achieves 100+ messages a month anywhere, I'll be
   extremely happy and go buy a lottery ticket or twenty.

SHA-512 was a bit too long (longer filenames, longer everything, and
we get at least two layers - <group>/<msgid>...). SHA-256 seemed just
right, even represented as hex, and then I stumbled on the idea of
using base64 as per RFC4648, so this is what it uses now.

I considered calling nncp-hash instead, since that is probably
guaranteed to exist on the same machine the mailer is running on,
but eventually decided that spawning processes left and right will
introduce more room for error.

It's not too late to pick something else.

--
Eugene Medvedev

  reply	other threads:[~2025-10-04 17:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-04 13:52 So I made a thing: nncp-echomail Eugene Medvedev
2025-10-04 16:56 ` gemtext (was: So I made a thing: nncp-echomail) Sergey Matveev
2025-10-04 17:51   ` Eugene Medvedev [this message]
2025-10-04 18:20     ` Sergey Matveev
2025-10-04 18:39       ` Eugene Medvedev
2025-10-04 19:23         ` Sergey Matveev
2025-10-04 19:34           ` Eugene Medvedev
2025-10-15 20:46   ` Eugene Medvedev
2025-10-26 11:13     ` NNCP_PACKET and NNCP_ORIGIN Sergey Matveev