💾 Archived View for gemini.complete.org › tunneling-nncp-over-other-transports captured on 2024-08-31 at 12:06:13. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-07-09)
-=-=-=-=-=-=-
NNCP[1] has built-in support for running over TCP, with nncp-daemon and nncp-call/caller. NNCP's own use cases[2] page talks about various use cases for NNCP. Some of them, such as the no link[3] page, cover use of nncp-xfer; others, such as the one-way broadcasting[4] page go over nncp-bundle.
2: https://nncp.mirrors.quux.org/Use-cases.html
3: https://nncp.mirrors.quux.org/UsecaseNoLink.html
4: https://nncp.mirrors.quux.org/UsecaseBroadcast.html
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 NNCP commands[5] we'll be using are:
5: https://nncp.mirrors.quux.org/Commands.html
nncp-daemon : 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.
nncp-xfer : 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.
nncp-bundle : 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.
Here are some things that can act as transports for NNCP.
You can easily tunnel the nncp-daemon/call traffic over ssh. For instance, you could use this in the addrs[6] part of the neighbor configuration:
6: https://nncp.mirrors.quux.org/CfgNeigh.html
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[7] documentation for details.
Yggdrasil[8] 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[9] for more details.
Tor[10] 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:
10: https://www.torproject.org/
addrs: {
tor: "|nc -X 5 -x 127.0.0.1:9050 akii45bolkchh5ulheaqip7amvy53ctt3crihzgzn3dgsk4jzj6ofuad.onion 5400"
}
This particular example comes from the quux.org NNCP public relay[11] documentation. Assuming your local Tor is listening on port 9050, it connects to the given hidden service on port 5400.
11: /quux-org-nncp-public-relay/
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.
The gensio[12] library/program can be used to create a reliable pipe underneath nncp-call/nncp-daemon over things like unreliable serial links. Its `relpkt` mode will do just the trick here. See my Using gensio and ser2net[13] page for more details.
12: https://github.com/cminyard/gensio
13: /using-gensio-and-ser2net/
My lorapipe[14] and xbnet[15] projects both facilitate sending data over long-distance, low-bandwidth radios. The xbnet documentation[16], in particular, covers use of socat with radios, as well as UUCP and PPP.
14: https://github.com/jgoerzen/lorapipe
15: https://github.com/jgoerzen/xbnet
16: https://github.com/jgoerzen/xbnet/blob/master/doc/xbnet.1.md
nncp-xfer[17] copies packets to/from a directory tree. These commands are most useful for things that can be mounted (including FUSE mounting).
17: https://nncp.mirrors.quux.org/nncp_002dxfer.html
There are various FUSE mountable tools for these different types of storages. One in particular is rclone[18], 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
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[20], 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[21] about using Syncthing with NNCP.
nncp-bundle[22] 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.
22: https://nncp.mirrors.quux.org/nncp_002dbundle.html
NNCP's PPP[23] page covers basic setup of running an IP stack over a serial line.
23: https://nncp.mirrors.quux.org/PPP.html
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.
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.
NNCP's Use Cases[24] page has even more ideas!
24: https://nncp.mirrors.quux.org/Use-cases.html
--------------------------------------------------------------------------------
25: /using-gensio-and-ser2net/
gensio[26] and the related ser2net[27] are generic tools for communication.
26: https://github.com/cminyard/gensio
27: https://github.com/cminyard/ser2net
28: /building-an-asynchronous-internet-optional-instant-messaging-system/
I loaded up this title with buzzwords. The basic idea is that IM systems shouldn't have to only use the Internet. Why not let them be carried across LoRa radios, USB sticks, local Wifi networks, and yes, the Internet? I'll first discuss how, and then why.
This page describes some basic concepts of NNCP[30].
We're going to cover two different sudo situations:
Usenet[33], of course, originally ran over UUCP[34] in quite a few cases. Since NNCP[35] is quite similar to UUCP -- in fact, you can map UUCP commands to NNCP ones[36] -- 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!
36: https://nncp.mirrors.quux.org/Comparison.html
NNCP lets you securely send files, or request remote execution, between systems. It uses asynchronous communication[38], 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.
38: /asynchronous-communication/
(c) 2022-2024 John Goerzen