Tunneling NNCP over other transports


NNCP has built-in support for running over TCP, with nncp-daemon and nncp-call/caller. NNCP’s own use cases page talks about various use cases for NNCP. Some of them, such as the no link page, cover use of nncp-xfer; others, such as the one-way broadcasting page go over nncp-bundle.

Here I build on all of these tools (daemon, call, xfer, and bundle) to show how they can be used to build even more communication methods.

The tools

The NNCP commands we’ll be using are:

Normally listens on a TCP port, but can also interact over stdin/stdout. We can use this, for instance, over ssh.
nncp-call / nncp-caller
Normally connects to a nncp-daemon on a TCP port, but can also use a program that can interact on stdin/stdout.
Reads and writes from a filesystem tree. Often used with USB sticks, but can also be used with various kinds of mountable/syncable directories and cloud storages.
Reads and writes streaming, tar-type archives. These need only a unidirectional pipe and can run over all sorts of transports, from FTP to UUCP.

The transports

Here are some things that can act as transports for NNCP.

Based on nncp-daemon/call


You can easily tunnel the nncp-daemon/call traffic over ssh. For instance, you could use this in the addrs part of the neighbor configuration:

addrs: {
  ssh: "|ssh remote.host nncp-daemon -ucspi"

This recipe is, in fact, even in the addrs documentation for NNCP. It of course requires configuration of public keys and authorized_hosts files. Now, you can use nncp-call/caller like usual.


You can talk between two NNCP instances on the same box, but running as different users, over sudo. See my NNCP with sudo documentation for details.


Yggdrasil is a mesh network with a lot of compelling features. NNCP has built-in Yggdrasil support, or you can use the standalone Yggdrasil node software. See my page NNCP over Yggdrasil for more details.


Tor is known for its efforts to preserve anonymity. It also makes it easy to run a server without having to muck with firewalls; that’s called a “hidden service”. You could establish a hidden service that connects to nncp-daemon, then use the Tor SOCKS proxy to access it. Your addrs section might look like this:

addrs: {
  tor: "|nc -X 5 -x akii45bolkchh5ulheaqip7amvy53ctt3crihzgzn3dgsk4jzj6ofuad.onion 5400"

This particular example comes from the quux.org NNCP public relay documentation. Assuming your local Tor is listening on port 9050, it connects to the given hidden service on port 5400.


socat is a very interesting multi-tool that can pipe data from commands to/from things like sockets, SSL, proxies, UDP, and so forth. It can be used with nncp-call and nncp-daemon.


My lorapipe and xbnet projects both facilitate sending data over long-distance, low-bandwidth radios. The xbnet documentation, in particular, covers use of socat with radios, as well as UUCP and PPP.

Based on nncp-xfer

nncp-xfer copies packets to/from a directory tree. These commands are most useful for things that can be mounted (including FUSE mounting).

Cloud Storage (AWS S3, WebDAV, Nextcloud, Owncloud, SFTP, FTP, etc)

There are various FUSE mountable tools for these different types of storages. One in particular is rclone, which has an extensive list of storage backends. If you can mount it in some way, you can likely use it as a relay point for nncp-xfer.

nncp-xfer -mkdir will create any needed directories in a hierarchy. That may be all you need to routinely do.

Using rclone in its syncing mode may be considerably more complicated, since it is a unidirectional sync.

Additional packages to investigate include: sshfs, davfs2, s3fs, curlftpfs

Bi-directional Syncing Storage (Dropbox, Nextcloud, Owncloud, Syncthing, etc)

These options aim to keep a local directory in sync with a remote. They are a bidirectional sync, so should work well with nncp-xfer. Basically, nncp-xfer on a given machine can move packets to/from the shared hierarchy as appropriate, but won’t touch files that aren’t relevant to it, so the process should be quite safe.

Syncthing, in particular, could make a great match for NNCP. Since it is fully-distributed, serverless, and even runs on phones, it can be an interesting transport mechanism. I have a blog article about using Syncthing with NNCP.

Based on nncp-bundle

nncp-bundle emits a tar-style stream which can be piped across transports, stored in queue directories or services, etc. Small bundles could conceivably be encoded and sent by email even (with procmail recipes to decode and process on the receiving end). nncp-bundle is suitable for use with tape drives, other streaming transport, or anything that you can pipe to.


NNCP’s PPP page covers basic setup of running an IP stack over a serial line.


Perhaps you have a noisy serial line or something else that is a challenge to keep clean. UUCP could still run over it – yes, you can tunnel NNCP over UUCP! All you need to do is use uux. Something like this (untested) ought to do the trick:

nncp-bundle -tx -delete node2 | uux - 'node2!nncp-bundle' -rx -check

You can omit the -delete until you have tested this and found it to be working well.


Of course, nncp bundles are just files that can be sent across all sorts of links using ZModem or similar.

IPFS, DAT, and other distributed tools

Since a bundle is just a file, it could be distributed using IPFS or something similar. However, I haven’t had the time to thoroughly explore this option.

Even More!

NNCP’s Use Cases page has even more ideas!

We’re going to cover two different sudo situations:

Usenet, of course, originally ran over UUCP in quite a few cases. Since NNCP is quite similar to UUCP – in fact, you can map UUCP commands to NNCP ones – it is quite possible, and not all that hard, to run Usenet over NNCP. In fact, in a number of ways, it works better than Usenet over UUCP!

This page describes some basic concepts of NNCP.

NNCP lets you securely send files, or request remote execution, between systems. It uses asynchronous communication, so the source and destination need never be online simultaneously. NNCP can route requests via intermediate devices – other NNCP nodes, USB sticks, tapes, radios, phones, cloud services, whatever – leading to a network that is highly resilient and flexible. NNCP makes it much easier to communicate with devices that lack Internet connectivity, or have poor Internet.