quux.org NNCP public relay

Introduction to NNCP

According to the NNCP documentation, NNCP is intended to help build up small size ad-hoc friend-to-friend (F2F) statically routed darknet delay-tolerant networks for fire-and-forget secure reliable files, file requests, Internet Email and commands transmission. All packets are integrity checked, end-to-end Encrypted, explicitly authenticated by known participants public keys. Onion encryption is applied to relayed packets. Each node acts both as a client and server, can use push and poll behaviour model. Also there is multicasting area support.

If you’re not already familiar with NNCP, I highly recommend you read the NNCP Concepts page before proceeding.

The NNCP homepage is http://www.nncpgo.org. A mirror using TLS and Let’s Encrypt is at https://nncp.mirrors.quux.org.

Introduction to the Quux Public Relay

The quux.org Public Relay hopes to facilitate several use cases:

  1. You wish to exchange NNCP packets between devices that have an Internet connection, but lack a stable IP or the ability to accept incoming connections. In this case, you can route your packets via quux to achieve easy communication without having to resort to VPNs and such.

  2. You wish to exchange NNCP packets with friends known to you. By using a relay with stable Internet access, you simplify the task in a similar way as with case 1.

  3. You want to help build a larger NNCP network, including peers unknown to you. By offloading the connectivity and routing to quux, this task is simplified for everyone. NNCP has also not been used much in this way, but has compelling advantages over other tools such as UUCP, so we are hoping to learn from this effort how NNCP might work in a more public way.

Experimental Nature of this Relay

This relay is experimental and, while it is hosted on dedicated hardware at a datacenter, it is done as a best-effort basis. Thankfully NNCP offers may other ways to exchange packets in the event quux is unavailable.

No guarantee about correctness of operation, longevity, or uptime of this system is available.

The relay is maintained by John Goerzen.

How it works

NNCP allows you to route packets via intermediate machines on their way to their destination. Because all the packets are encrypted and use onion routing, quux is unable to access the data traversing it.

NNCP packets are routed using the via configuration or command-line option. You can specify a complete path to reach a destination. Alternatively, you can simply route packets leaving your network via quux, and quux will handle the proper routing at the next step to get them to their destination.

quux is fundamentally a normal NNCP installation that happens to be willing to peer with the public, and runs a few scripts to help maintain nodelists and such.

Preparing NNCP

See Getting Started with NNCP to get NNCP installed and configured. If you’ve already done that, move on to the next section.

Joining the quux NNCP relay

To join, please send an email to jgoerzen AT complete dot org requesting addition. I will need certain information from you:

  • The preferred nodename for your system. Note that you can use whatever nodename you like locally, since they are just aliases for NNCP ids. This is to help others in the nodelist.

  • If your system is permanently online on the Internet, reachable at a known hostname/port, and you wish this to be published in the nodelist, let me know. This is completely optional; it is assumed most systems will not be reachable in this way. However, if we have ones that are, then the relay server can also establish outbound connections to you.

  • If the host will not communicate directly with quux, the via path used to reach it.

  • The self section FROM WITHIN THE neigh BLOCK of your nncp.hjson. It should look like this:

    neigh: {
  self: {
    # You should give public keys below to your neighbours
    id: RKOLY...KAMXQ
    exchpub: 2NZKH...CMI7A
    signpub: EXD7M...YAOFA
    noisepub: MIXYN...BGNDQ
  }
}

Upon receiving your request, you will be added to the server configuration and the public nodelist.

Here is a template you can cut and paste and edit to provide it:

I'm requesting to join the quux NNCP relay.

Preferred nodename:

Hostname/port to publish, if any:

via path, if any:

Local Setup

Configuration

Add these lines to the neigh section of your nncp.hjson:

    quux: {
      id: SXNADKNYBOU6VPDVZHZZGHPJXDDZTDWDT4YAQ5TJHBA6FTNUHTCA
      exchpub: 7L4GZ4LKXZREZFSBKCBX4CGUTLYKUHR4KNQ3O6NPJGGM6C5YGAPQ
      signpub: HS2Q2DNZWWCFY4V2UGYYJZFU4UPTUBFOTFYBY25QNOKDNG2OBKDQ
      noisepub: C7JASCAKJDRQNWNBOUX6WGFN4U7KC3NFU472IW43NJIBUB3V3EZQ

      addrs: {
        internet: "nncp.quux.org:5400"
      }
      incoming: "/tmp" # (or more appropriate path); may be omitted after testing
    }

Then, if running NNCP services as a daemon, restart your daemons and verify things have loaded appropriately.

Testing

Once you receive confirmation that your node has been added to the server, you can test your configuration by requesting this file from the remote:

nncp-freq quux:README.txt

Now, you’ll need to use nncp-call to call to quux; for instance:

nncp-call -progress -onlinedeadline 10 quux

You should see a packet flowing out. Now wait about 2 minutes, and call again:

nncp-call -progress -onlinedeadline 10 quux

You should see a packet received. Now, run the tosser:

nncp-toss -progress

And the packet should be decrypted and processed.

See the NNCP workflow page for more details on how this works.

So now, you should have a copy of README.txt in the directory you labeled as incoming in your configuration. At this point, if you no longer wish to be able to receive freqs or files from quux, you may delete or comment out the incoming line in your configuration. However, you probably will want to be able to freq files from quux; read on.

Other files available for freqing

The README.txt file you freq’d from quux above will indicate other files available. quux also makes available NNCP releases via its full NNCP mirror.

Expectations

Treat quux and your fellow humans kindly.

quux does not have visibility into the packets that traverse the node, but nevertheless, if we become aware of harassment, unethical behavior, excessive storage use, or illegal activities using the quux node, appropriate action will be taken.

We ask at this time that you keep routine packet sizes beneath 100MB. Please do not in any circumstances cause more than 1GB to be stored on quux. quux is hosted on enterprise SSDs which can’t handle multi-TB packets!

quux implements an automatic cleanup of packets that have remained on the system for a certain number of days without being picked up.

Privacy

Your data is as private as NNCP makes it, which is pretty good. NNCP’s encryption should prevent quux from seeing your data. Some metadata about packet sizes and flow may be visible to quux. For more details, consult the NNCP documentation.

Submitted data, including your name, email address, public host keys, and hostname/port, will be made available to all other present or future members of this relay server and may be published elsewhere on the Internet from time to time.

Always remember the experimental nature of quux and that any kind of guarantee cannot be provided.

Removal

If you wish to be removed from the relay server, email jgoerzen@complete.org with your request.

Advanced topic: The Nodelist

Part of the fun of this relay is discovering other peers around the world.

To that end, every peer on this relay is mentioned in the nodelist.

Download the latest nodelist with:

nncp-freq quux:nodelist.tar.gz

Upon unpacking, you will find a directory called nodelist/for-use with nncp.hjson fragments corresponding to the nodes in the system.

You can use a script such as this to emit a more cohesive nncp.hjson blurb:

rm MYNODE    # Delete your own node; that will be processed under "self"
for FILE in *; do
   echo "$FILE: {"
   cat "$FILE"
   echo 'via: ["quux"]'
   echo '}'
   # Here you could add lines about incoming dirs, via path
done

Then, if you have two ready-made nncp.hsjon segments – the bit before this part of the neigh section, this part, and then the end, you could form the complete nncp.hjson like so (assuming the above script is in cat-nodelist):

cat nncp.hjson.pre > nncp.hjson
cat-nodelist >> nncp.hjson
cat nncp.hjson.post >> nncp.hjson

Advanced topic: Access via Tor

As an advanced option, you may access the quux.org NNCP system via a tor hidden service. To do so, add this to your addrs section for quux:

tor: "|nc -X 5 -x 127.0.0.1:9050 akii45bolkchh5ulheaqip7amvy53ctt3crihzgzn3dgsk4jzj6ofuad.onion 5400"

This assumes that the tor SOCKS5 proxy is running on port 9050 on localhost, and that you have netcat installed. You may need to installl netcat and tor if you don’t have them installed already.

Advanced topic: Access via Yggdrasil

As covered in NNCP over Yggdrasil, NNCP can run over Yggdrasil in a couple of different ways. This page will not cover NNCP-Yggdrasil configuration. If you want to talk to the quux.org public relay over Yggdrasil, you may need this:

  • Public key: 1af69f4d1a40c4c37e6b559b022f26af4409ea62b852fbe62a919b93f9022672
  • IP address: [203:5096:b2e:5bf3:b3c8:194a:a64f:dd0d]
  • Port: 5400

For More Information

This page describes some basic concepts of NNCP.

This page describes the basic installation and configuration of NNCP.

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.

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!

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.

These sites are hosted on the complete.org server. Some are hosted with resources donated to non-profit organizations.

This page gives you references to software by John Goerzen.

Complete.Org is a personal project managed since 1994 by John Goerzen.