Greetings! *** John Goerzen [2021-07-31 21:04]: >One is error handling. Yeah, that thing NNCP is completely lacking. Just logs and retries forever until operator intervene with it. Definitely something has to be done in that direction. I do not think that packet's ordering can be "solved" easily. If we will store some kind of sequence numbers in encrypted packet -- it is unnecessary and unwilling metainformation leak. If we decrypt it and get the plaintext packet, then it can contain some ordering information, but... if it is already processing, then we should process it and store on the disk, removing the encrypted packet, clearing out the spool directory. I met the problem of ordering with extensively used chunked files (most of data I sent is chunked): http://www.nncpgo.org/Chunked.html And "solve" it just by parsing the .nncp.meta file and waiting for all .nncp.chunk* appearance. And only after that they are checksummed and reassembled to the destination packet. >One could request no notifications ever, notifications on >processing with any kind of result, or notifications only for errors. These >notifications would be emailed back (and the address to send them to could >be specified). Also thought about that. But not sure about any kind of feedback error channel, because of the complexity and possible metainformation leakage (watching for the facts of feedbacked information sent back). Currently I assume that NNCP networks are small enough and each time each operator decides himself what to do, possibly manually sending email about invalid/unexpected exec/whatever-packets. >Secondly, reouting. What if we supported, say, "partial source routing?" >A - B - C - D Exactly that use-case is already covered in 7.2.0 release. I just tested it locally with [abcd] nodes to be sure. http://www.nncpgo.org/Release-7_005f2_005f0.html >Finally, the commands for nncp-exec in nncp.hjson. I think it would be >really useful to be able to say "do not pass parameters to this program" (or >maybe pass them as an environment variable instead of on the command line or >something). I'm using wrapper scripts for this purpose right now but just >blocking them entirely could be nice for security. Passing as environment variable (something like NNCP_ARG1, NNCP_ARG2 ..., NNCP_ARGS=2) can complicate scripts forcing them to probably unset those envvars before calling another command. Arguments are "local" for just single command call. I think that using wrappers is just some kind of necessary and completely ok thing to do. Someone probably want to block the stdin entirely -- I do not think that NNCP should cover all possible call-cases: flexible wrappers are for that. >Thanks again for all you do, Sergey! Glad it is useful! -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF