Greetings!

*** Koushik Roy [2021-12-09 20:13]:
>Right now it doesn't seem possible to have two different paths when one
>includes a "via" block.

But it can be overriden per every nncp-* command invocation via "-via" option.

>Would it be possible to add support for
>distinguishing between a direct connection to a neighbor node and a
>relay connection to the node?

Problem here is that process of encryption packet creation is
independent and asynchronous to the process of transmitting those
packets. "Routing" information is applied before creating the
encrypted packet: so "via" works when nncp-file/exec/freq are called.
And they do not know anything about the transport will be used further.
So I honestly do not see how those "abstractions" (packet transfer and
packet creation) can be joined together.

Well, of course there can be some kind of hackish way to do that, for
example instead of invoking the "nncp-file ...", you call "nncp-file
-via `my-dynamic-routing.sh DST` ...", where "my-dynamic-routing.sh"
script will ping/curl/whatever the DST host to determine its
availability and return the route path. But... that DST can be
temporarily down. You can leave the LAN after 5 seconds after
my-dynamic-routing.sh was invoked. I think it won't be satisfactory.

Subject of dynamic routing was asked not the first time, but still I
just have not thought about it much, because even in your simple case (I
have exactly the same at home too and I just use "Baz" all the time) it
is not obvious to express what behaviour I want, because of that
asynchronous and independent nncp-* invocation and transport processes.

Currently I assume that multicast can be used in the case you described.
I did not check it and can not tell is it stupid idea, but I believe
that you can create multicast area and subscribe Foo, Bar, Baz on it.
Then you send file/exec/whatever to that area. When you are on LAN, then
both Bar and Baz receives it. After a while Bar will receive the same
multicasted packet from Baz, but will delete it, because it was already
seen after processing the packet got directly from Foo. When you are on
WAN, then packet to Bar is queued, but packet to Baz is sent (and Bar
receives it). When you are back at LAN, then you send previously queued
packet to Bar, that is deleted on it, because it was seen from the Baz.
Of course that doubles the real amount of traffic and disk consumption
on some nodes, so hardly it is helpful :-), but it can deliver packets
directly to Bar faster.

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