Greetings!

*** John Goerzen [2022-03-09 16:46]:
>A: originates the packet, nothing to ack
>B: acks to A
>C: I'm not sure.  Does it ack to B or to A?
>D: Also not sure.  Does it ack to C or to A?

* When nncp-file is finished on A-node, then spool-of-A/B/tx/ contains
  the packet PKT-AB to B-node.
* B-node receives PKT-AB and places it to spool-of-B/A/rx/PKT-AB
* nncp-ack on B-node generates ACK packet to A-node for PKT-AB
* B-node tosses PKT-AB and generates spool-of-B/C/tx/PKT-BC packet
* C-node receives it and places to spool-of-C/B/rx/PKT-BC
* nncp-ack on C-node acknowledges B-node about PKT-BC. It knows nothing
  about A-node. nncp-ack looks only on spool/NODE/rx/* packets and ACKs
  the NODE
* C-node tosses PKT-BC, generates PKT-CD
* D-node receives PKT-CD, acknowledges C-node
* Although spool-of-D/C/rx/PKT-CD is an inbound-queue of node-C, but
  PKT-CD has A-node as the sender

So yeah, currently A-node gets acknowledgement only about PKT-AB
delivery (even not about its tossing).

>My understanding of the packet format - and this may be incorrect - is
>that in the specific case I outlined, every node - B, C, and D will have
>A as the sender in the header of the packet they process, since A
>generates every layer of encryption along the way.

Correct. nncp-pkt can be used to view various packet's headers to see
who is the actual sender.

>However, I think that's not necessarily the case.  If, say, B's neigh
>block for D says: via: ["C"]
>then A could just say: A$ nncp-file -via B foo.txt D:

Also correct. Exactly that case I just used now to check the packets and
behaviour.

>However, maybe nncp-ack is ignoring what's in the packet header and just
>going by which rx directory it's in?

Correct.

I think that nncp-ack can generate an additional ACK packet if received
encrypted packet's sender differs from the node it was get from and if
its type is not "transitional" (so current node is the "final" destination).
D-node sees that PKT-CD's sender is A-node, it is in C-node's rx-queue,
it is not transitional, so it can acknowledge A-node.

But there is complication one have to think about: nncp-ack optionally
takes "-via" and "-node", that are fine when we generate only single
packet. nncp-ack -all do not use "-via" and takes its from the
configuration file. Currently "-node ... -via ..." will be applied to
C-node's ACK packet, but not way to override via for A-node. Actually we
do not know if C-node's rx/ contains packets from A-node. Probably
nncp-ack should check all rx/ directories, parse all headers and so on.

Another complication is that when A-node sends its packet to D-node,
then its tx/ queues has only the packet PKT-AB, but no knowledge about
all intermediate ones and the final PKT-CD. So even if D-node will
acknowledge A-node about PKT-CD, then nncp-toss on A-node just does not
have anything to remove. All of that is solvable somehow of course,
nncp-toss can simply even touch files in some/dir/with/received/ACKs and
external scripts will just check if the required packet is acknowledged.
For example I nncp-file something and wait in cron-ed scripts about
PKT-CD packet's acknowledgement. But currently there is no easy way to
know that PKT-CD's packet identifier, or even PKT-AB's one. One can
parse -debug logging output (that is recfile-format) to find the
packet's hash, but that is not too convenient of course.

And let's not forget that those ACKs only about the delivery, not about
successful tossing. If somebody wishes that kind of ACK, then currently
the only way is to create custom programs/scripts, call them through
nncp-exec, and those scripts must call another nncp-exec that will send
some higher-level (toss) acknowledgement. nncp-toss could send it
automatically if corresponding exec-handler will return successful
return code. But that leads immediately to the desire of sending of NAK
packet, probably containing at least the return code itself and probably
the stderr of the failed exec-handler.

NNCP is a long time not a too Unix-way thing, that actually replaces
gpg/zstd/tar(sometimes)/split and other things that could be used as
external pipes/utilities. So all that ACK/NAKs generated during the toss
of exec-handlers are pretty ok too and I am not against them. But
currently I do not have much ideas and readiness of that kind of
features implementation.

My TODO file have remarks about basically total lack of error handling
(and toss-NAKs can help with that), lack of integration tests (today
only the very first one appeared related to nncp-rm, but I think it
won't work anywhere outside FreeBSD or BSD systems at all :-)), area's
authorization subject and some other issues. So there are many things
needed to be done.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF