*** 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 / 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