public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: nncp-devel@lists.cypherpunks.su
Subject: Re: gemtext (was: So I made a thing: nncp-echomail)
Date: Sat, 4 Oct 2025 19:56:05 +0300 [thread overview]
Message-ID: <aOFRzMs8JFq64nGj@stargrave.org> (raw)
In-Reply-To: <CAO-d-4qqZ+QtTbkBG4Gdtvj7WXAZMWFCfWbjKOvHBP+ZbAN+Dw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6961 bytes --]
*** Eugene Medvedev [2025-10-04 16:52]:
>So here it is, an echomail/forum-like system relying
>on NNCP areas for routing [...]
Years ago it was exactly that type of thing I wanted to exist in
practice! I loved FidoNet's echomail and have never felt anything in
Internet had the same feeling (although I have never used Usenet).
Actually all that "area" terms in NNCP exactly referred to FTN world.
>As of today, this is by nature not resistant to sender
>spoofing: NNCP does not yet expose the actual
>sender ID to execs receiving packets from areas.
>Something that can hopefully be fixed, though.
Yeah, that should be fixed easily, as that information actually exists
in packets/NNCP-utilities.
I liked the idea of <msgid>/<filename> links!
------------------------ >8 ------------------------
I just wanted to add my humble opinion about gemtext format. This is not
a critique or suggestion, just an opinion and a thought.
>While I will be the first to criticize Gemtext as a markup format, *(I love my inline italics!)* three important considerations exist:
>1. It is *trivial* to parse.
>2. A lot of open source software already exists to handle it, some of which can be badgered into being a full-fledged echomail editor with a little work.
>3. The prospective audiences of Gemini and NNCP already intersect to a significant degree.
Personally I dislike gemtext very much, because it is *not* human
readable. It is machine-readable format. It suggests you to write long
lines, that are not (conveniently) readable by humans. You have to use
some utility to reformat them to shorter and readable ones. But that
utility must be aware about preformatted text blocks and should not
touch them. So you have to use something more advanced and complex than
ordinary "fmt" utility. And all those "## headings" are not clearly
visible, not very distinctive, compared to:
============
that heading
============
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. And I think that is the most
important capability of text messages. gemtext (or Markdown) are some
kind of the source code, machine readable format, requiring the renderer
to view them *conveniently*.
A while ago I created "SWG" format:
http://www.git.stargrave.org/?p=swg.git;a=blob;f=README
that virtually has no formatting at all. It is just a plain text, so
format as you fish, make it consumable without any additional software.
But we often want to insert links. And we often want to insert links to
images, explicitly marking them as a link to image (even gopher://
protocol can do that, unlike gemtext, where you have to click on every
link to (possible, you can not be 100% sure) an image). So in SWG you
insert "=> URL[ optional text]" or "img URL[ optional text][ => URL-A]"
lines, but end them with LF character (can be inserted in Vim with
Ctrl-V + Enter, as an example). Ordinary text won't have a mix of CR and
CRLF line endings. Ordinary cat/less/more will show those lines as an
ordinary ones. But a machine can easily distinguish them from ordinary
text ones. http://www.git.stargrave.org/?p=swg.git;a=blob;f=FORMAT
That gives more flexible documents, even much more simpler parsing,
ability to insert images (noone forces you to automatically load them,
as you wish). Of course there is no difference between "flowed"
(possible variable width) text and preformatted one -- it is just a
ready to view plaintext "document".
I think gemtext is a better choice than Markdown, that has huge
specification, many features and a full complete 100% assurance that
noone supports them all and your ".md" document will work only if it
uses a tiny subset of the MD/CM. As many people say: there is no such
format as MD, but a huge zoo of partly compatible set of implementations.
And hardly anyone supports CM. That is why all projects, which maillists
I am subscribed, does not even think about MD/CM as a possible choice
for non-trivial (plaintext is enough for trivial one)documentation.
But gemtext can not be used instead of a simple HTML (or even Gopher's
menus!), containing internal links (anchors) and images. But SWG in my
practice is pretty good at that, being much simpler thing. The only
argument I heard about preformatted lines is that they look bad on
smartphones. And because of those things existence we have to bury plain
text formats and use machine readable ones, which require the renderer?
So not an argument for a user of the normal personal computers.
------------------------ >8 ------------------------
By the way, just curious, why you used SHA-256 as a hash? There are so
many much better (cryptographic) hash algorithms appeared for the last
~25 years! SHA-256 is literally the slowest one among any seriously used
nowadays. SHA2-512 is much faster on 64-bit platforms, which are
prevailing for our use-cases. Skein (one of the SHA3 finalists) is much
faster and have considerable higher security margin. BLAKE2 (which is
based on BLAKE -- another SHA3 finalists) is even much more faster than
any of these, also having a great (much higher than SHA2) security
margin. None of them have problems with length-extension attack, which
you have to always remember about when using SHA1/2. Pure SHA3 (Keccak)
may be a bit slower than SHA2, but it has less instructions it uses, it
is simpler to implement, and "leaks" less on side-channel, due to lack
of complex instructions. But both Keccak authors, and NIST itself,
recommends to use SHAKE variant of SHA3 (if you are not forced to use
pure SHA3), which is faster than SHA2, keeping all other advantages too.
Not so much modern CPUs have SHA2 accelerated instructions, but Keccak
is already included in more CPUs, making it even faster than BLAKE2.
SHA2 is still secure (unlike SHA1), but for example BLAKE2 is available
out-of-box in many "standard" libraries (Python added it a long time
ago, as an example), SHA3 is also pretty widespreadly available. In
virtually all modern cryptographic protocols/formats/algorithms where
the hash is used, cryptographers choose either SHAKE (maybe SHA3), or
BLAKE2 in majority of cases if they are not required to use
NIST-approved hashers. I know, I know, that there are still many people
using MD5, ignoring the fact that BLAKE2, especially BLAKE3 or
accelerated Keccak a much more faster (even not mentioning the security),
possibly there are many people using SHA1, but... SHA2 is another thing
that should be replaced, at least because of the worst performance. Just
my humble opinion of course.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
next prev parent reply other threads:[~2025-10-04 16:56 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 ` Sergey Matveev [this message]
2025-10-04 17:51 ` gemtext (was: So I made a thing: nncp-echomail) Eugene Medvedev
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