Subject: A Public NNCP relay

From: John Goerzen <[email-masked]>
Date: Wed, 28 Jul 2021 19:41:52 -0500

Hello folks,

I am contemplating setting up an experimental public NNCP relay 
for people.  I would like to hear thoughts on this: would anyone 
be interested, what do you think of the plan, etc.

* The need

I happen to have a nice colo server, and I run NNCP on it, just 
for myself.  This is handy, for instance, when away from home: a 
laptop can send messages bound for my home system to it, the home 
system can dial in and get them, and there's no messy firewall 
stuff involved.  (I can also run NNCP over tor, but that is a bit 
more flaky due to connection timeout expectations over NNCP). 
Sometimes if I'm traveling, I would send backups via this system, 
knowing that they are at least off my laptop and existing 
somewhere else, even if my machine at home is powered down.

This sort of thing would also facilitate using NNCP to exchange 
data between friends.  Managing ports, etc. for n people gets more 
difficult as n increases above 1.

* Some ideas

I could set up nncp-daemon and nncp-toss and use ZFS "project" 
quotas to limit the size of each spool directory to something 
reasonable.  People that want to exchange data via the public 
relay would just need to send me the public bits from their 
nncp.hjson.  Thanks to onion routing, the relay server doesn't 
need to know all the details of every system that may participate 
in the network, just the ones that will talk to it directly.

The relay server could also easily enough operate as a Tor hidden 
service for those for whom that would be beneficial.

Thanks to the new area support, if bandwidth is plentiful and the 
data sets aren't huge, a person could actually send packets to an 
area - direct via LAN and indirect via relay server - and they 
would be delivered by whichever method gets there first (though 
often wasting the bandwidth to the relay server; I wonder if there 
is a way to queue up an outbound packet that says "send via one of 
these lists of paths and delete the others once it's sent?")

* What about reliability?

Let's say NNCP interest explodes.  Clearly the world wouldn't want 
a single relay server.  I could imagine a situation in which major 
relays know about each other and can exchange data with each 
other.  Of course, we would still be talking UUCP-style source 
routing - not automatically rerouting if a relay is down (unless 
area-style broadcast is used).  But it would permit a fairly 
simple via tweak to take other paths if a relay becomes 
unreliable.

* Some nice properties of the relay

Thanks to NNCP's design, the relay would be capable of:

- Routing email without having to expose a MTA to nodes at all, or 
  being able to see the content of messages at all

- Of course, that doesn't apply just to email, but also files and 
  so forth.

- Thanks to persistent connections, data could be routed pretty 
  quickly for online hosts.

- It could enable some more interesting things (eg, FTP-like 
  services over NNCP) for experimentation.

* Other alternatives

I've done some experimentation with using Syncthing as a transport 
for NNCP packets (generally with nncp-xfer but nncp-bundle can 
also work).  This is a pretty interesting transport, since it is 
fully distributed already and runs on Android phones too.  A phone 
can literally be the carrier between two remote sites -- get in 
range of the local wifi, Syncthing syncs up, NNCP sees packets, 
and boom!  Content processed.

I think, though, that Syncthing doesn't really lend itself to 
untrusted members in the mesh, at least not in the way we'd need 
for NNCP.

One could also route NNCP messages over UUCP.  But then.... why?

Thoughts?