Greetings!

*** John Goerzen [2025-10-07 08:31]:
>Very true.  I often have wrapped it in frames, with a leading u64 length
>indicator.  Somewhat annoying, but it has generally been OK for me to
>put the large payload, whatever it is, outside of the MessagePack and in
>a frame.

Like I do with NNCP, where there are some raw data of non-32bit length
outside XDR structures. But that is an unfortunate hack, workaround for
codec/format limitations.

>> in advance) and does not force deterministic encoding (but in practice I
>> won't be surprised that most implementations have strict behaviour),
>> that was not perfect for embedded systems. So I just have not found good
>> enough existing format. MessagePack won't be a problem for NNCP use-cases,
>> but cryptographic messages (KEKS/CM) are already defined and Go
>> implementation covers a big subset of them.
>
>Can you send me a pointer to this definition and Go implementation?  I
>haven't been able to dig it up.

What definition? About KEKS and comparison with other codecs?
http://www.keks.cypherpunks.su/
Draft/dirty-but-working Go implementation of its cryptographic messages
is in Git: http://www.git.cypherpunks.su/?p=keks.git;a=tree;f=go

>I'm curious what other items are on your TODO list?

Well, I am ashamed of sharing it and maybe some important (for other
people) issues were missed by me unintentionally. There is a will to
make integration tests (cfgdir was created exactly at least for them).
To think about authorisation in areas. Route printer. Errors
refactoring. Something related to downloads resuming (I even do not
remember the details).

>> NNCP get much attention (mainly by your, John, work) when my interest
>> was already declining :-). I even have not updated FreeBSD's port for a
>> long time. Recently I tried to update it, but it has some port-ecosystem
>> related issues that I am not too enthusiastic to debug and fix.
>
>Totally understandable.  Maybe this will finally get me to learn Go :-)

That weekend port was updated: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289697

>FWIW, I process around a thousand packets a day using NNCP for backups
>(every ZFS dataset on every machine, every hour).  It is fantastic and
>Just Works!

Glad to hear that :-)

>There are a number of libraries for dealing with the old Windows .ini
>format.  Python and Rust have one named configparser, for instance.
>Most of these have support for both reading and writing.  It's a
>reasonable format, better than all the YAML ones :-)

YAML is the worst by all means, in my opinion. .ini is good for very
simple cases indeed, but TOML, also being very widely supported, not bad
comparing to it. Actually I moved NNCP's YAML configuration to TOML
once, but then I saw how it looks with more complex nested structures,
like NNCP has, it was not even committed.

>Just a comment - a different config file format doesn't necessarily mean
>the other things have to change.  Though maybe it is the other changes
>that would drive the different config file format.

Yeah, actually exactly the other changes (like using (unfortunately
huge) Classic McEliece keys) some kind of forces to use non-single-file
configuration (keeping BaseXXX-encoded >1MiB key for each node is bad).

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