public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* A few other features?
@ 2021-08-01  2:04 John Goerzen
  2021-08-03 10:57 ` Sergey Matveev
  0 siblings, 1 reply; 4+ messages in thread
From: John Goerzen @ 2021-08-01  2:04 UTC (permalink / raw)
  To: nncp-devel

Hi,

These are brainstorms that are somewhat forward-looking....

In thinking about NNCP -- I also happen to have purchased some old 
books on UUCP and am researching the old UUCPNet -- it occurs to 
me that there are three areas where there may be useful 
improvements.

One is error handling.  Right now, if a packet arrives at a node 
and toss can't deal with it, it basically retries forever.  I 
exploit this behavior heavily with my nncp-exec processing; 
sometimes I need to process packets in order, and of course there 
is no guarantee for ordering in nncp-exec.  However, I can check 
if I'm ready for a certain sequence number or whatnot, and just 
exit nonzero if not, and it'll try again when hopefully the 
prerequisite has been processed.  Very nice.

However, sometimes it's not quite as nice; maybe a file is sent to 
a host that's configured to disallow from the sender, or a command 
is run that's not defined, etc.  uux had the -z option, which 
indicates what should happen on error.  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).  I'm not entirely sure what the right idea here is, 
but maybe there is some way to keep the currect behavior (which is 
quite useful) as a default and offer an alternative to just fail 
(perhaps with a notification) if selected by the user (or forced 
in nncp.hjson on the recipient side).

Secondly, reouting.  What if we supported, say, "partial source 
routing?"

Say we have a network like this:

A - B - C - D

A wants to send something to D.

Of course, it could say -via B,C

But what if B's nncp.hjson defines D as "via C".  Could A just say 
-via B?  B could unwrap the packet, see that it got a destination 
for D, look that up, see it's got to go via C, re-wrap it in an 
onion for C and queue it up for C.

I'm not entirely sure yet if this is actually useful but my gut 
tells me it may be if we scale up.

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.

Thanks again for all you do, Sergey!

- John

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-08-04 11:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-01  2:04 A few other features? John Goerzen
2021-08-03 10:57 ` Sergey Matveev
2021-08-03 20:22   ` John Goerzen
2021-08-04  8:19     ` Sergey Matveev