public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: Rafael Diniz <rafael@riseup•net>
To: John Goerzen <jgoerzen@complete•org>
Cc: nncp-devel@lists.cypherpunks.su
Subject: Re: Greetings
Date: Fri, 13 Mar 2026 01:51:15 +0000 [thread overview]
Message-ID: <cbf10783-34ba-40a8-a45c-255aa02e224d@riseup.net> (raw)
In-Reply-To: <87ldfwcz0y.fsf@complete.org>
[-- Attachment #1.1: Type: text/plain, Size: 4831 bytes --]
Hi John! Nice to talk to you!
I'll comment inline.
On 3/13/26 1:13 AM, John Goerzen wrote:
> 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.
In HF we don't have low-latency, but the modem guarantees an error-free
link. Need to dive in the timeouts.
> 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.
Your website is pretty cool, thanks a lot, I know it for quite some time.
Using RaptorQ (hermes-broadcast), no need of per-(modem)-packet ACK,
fountain codes take care, stations can just ask the broadcast to keep
going till the receive the bundle. This is the part of the system with
clearer view for me. The async NNCP ACKs could be useful for informing
the gateway which stuff arrived to each station.
> 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.
Perfect - these are the details I needed to know, to start testing.
> 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 already use a wrapper [1] for the UUCP<->HF Modem connection now. For
NNCP, I wanted something more elegant, with proper support.
> 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!
We don't use amateur radio bands in HERMES project.
This is not really meant for amateur radio use, at least until this
encryption prohibition holds.
[1] https://github.com/Rhizomatica/hermes-net/tree/main/uucpd
- Rafael
> - 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/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2026-03-13 1:51 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 ` Greetings John Goerzen
2026-03-13 1:51 ` Rafael Diniz [this message]
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