public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: Rafael Diniz <rafael@riseup•net>
Cc: nncp-devel@lists.cypherpunks.su
Subject: Re: Greetings
Date: Thu, 12 Mar 2026 20:13:17 -0500 [thread overview]
Message-ID: <87ldfwcz0y.fsf@complete.org> (raw)
In-Reply-To: <f6c9e621-353c-4794-86a9-3c800557fd7a@riseup.net> (Rafael Diniz's message of "Thu, 12 Mar 2026 23:30:43 +0000")
Hi Rafael,
Wow! This is right in line with many of my interests. That looks like
a fascinating project.
Sergey can chime in on your patch.
I have a few thoughts in case it is helpful.
I don't know how you're using UUCP, but since it was built in an era of
slow, error-prone, half-duplex links, it is probably ideally suited to
HF radio. nncp-daemon assumes a low-latency, error-free link, so may be
hard to adapt to HF conditions. You may find that a convenient option
would be to use nncp-bundle to generate a file (essentially a tar file)
containing NNCP packets for a given destination. You can then transport
that over UUCP to the remote, and inject it to NNCP using nncp-bundle
there.
You could also use nncp-bundle without a UUCP wrapper, as you alluded
to. nncp-bundle -rx will simply drop packets not destined for the local
node, so you can certainly broadcast bundles to everyone. A problem
arises, though, that this doesn't permit retransmit requests if parts of
it aren't received correctly. My approach at
https://www.complete.org/dead-usb-drives-are-fine-building-a-reliable-sneakernet/
may help you work around that by using end-to-end ACK packets.
If you do use nncp-daemon and nncp-call(er), you will want to set the
NNCPDEADLINE environment variable, as well as the maxonlinetime and
onlinedeadline to high values.
Along those lines, nncp-daemon and nncp-call(er) support a -ucspi
option, which means they communicate over stdin/stdout. If you have a
generic wrapper for your TNC software, that may be useful. You might
also use TCP over AX.25 over KISS, but the high packet overhead of that
at HF speeds would likely be unfavorable.
I see you are aware of various regulations on use of encryption on
amateur radio bands. Unfortunately, since encryption is prohibited on
amateur radio bands in the US, NNCP won't ever run over ham radio here.
If your target countries permit it, then that's great!
- John
On Thu, Mar 12 2026, Rafael Diniz wrote:
> Hello all,
>
> I'm Rafael Diniz (PU2UIT/CR7BYQ), working at Rhizomatica [1]. We've been using
> UUCP for almost a decade in our HF networks, and we always knew the time to move
> to NNCP would come.
>
> We'd like to have at least a working test network up this year (hopefully). I'm
> still studying NNCP, understanding on how to provide NNCP to the communities
> that use HERMES [2], that are UUCP-based. There are always questions about
> security, but one huge advantage to me is bundle broadcast (using fountain codes
> [3]), together with our modem [4].
>
> I did a very early draft (without broadcast support, without many things,
> untested, ai generated) on how we could connect NNCP to a VARA-compatible modem
> (like our Mercury modem), just to start the conversation:
> https://github.com/Rhizomatica/nncp/pull/1
>
> (I want to get out of github asap, but for now, that is where I placed the code)
>
> I have some test setups with radio on dummy loads in my table, and over the air
> also, stations some hundreds of kilometers apart, which I can do tests. My focus
> will be the Mercury modem in the next weeks, in order to stabilize the
> over-the-air protocol and connectivity to standard VARA [5] (Mercury is
> compatible VARA client tcp interface) clients, but I want to fire up already the
> NNCP torch inside our project.
>
> NNCP GO!
>
> Cheers,
> Rafael
>
> [1] https://www.rhizomatica.org/
> [2] https://hermes.radio/
> [3] https://github.com/Rhizomatica/hermes-broadcast
> [4] https://github.com/Rhizomatica/mercury
> [5] https://rosmodem.wordpress.com/
next prev parent reply other threads:[~2026-03-13 1:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 23:30 Greetings Rafael Diniz
2026-03-13 1:13 ` John Goerzen [this message]
2026-03-13 1:51 ` Greetings Rafael Diniz
2026-03-13 2:25 ` Greetings John Goerzen
2026-03-13 10:58 ` Greetings Rafael Diniz
2026-03-15 8:23 ` HF modem support Sergey Matveev
2026-03-16 2:13 ` Rafael Diniz
2026-03-17 23:53 ` Rafael Diniz
2026-03-18 0:32 ` Rafael Diniz
2026-03-18 10:45 ` Sergey Matveev
2026-03-18 12:52 ` Rafael Diniz
2026-03-18 10:42 ` Sergey Matveev
2026-03-18 12:56 ` Rafael Diniz
2026-03-18 10:26 ` Sergey Matveev