public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: Jonathan Lane <tidux@sdf•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Re: A Public NNCP relay
Date: Sat, 31 Jul 2021 12:12:39 +0000 [thread overview]
Message-ID: <20210731121239.j3grg2di22vfc6ne@faeroes.freeshell.org> (raw)
In-Reply-To: <87tukeeysv.fsf@complete.org>
On Wed, Jul 28, 2021 at 07:41:52PM -0500, John Goerzen wrote:
> Hello folks,
>
> I am contemplating setting up an experimental public NNCP relay for people.
> I would like to hear thoughts on this: would anyone be interested, what do
> you think of the plan, etc.
> * Some ideas
>
> I could set up nncp-daemon and nncp-toss and use ZFS "project" quotas to
> limit the size of each spool directory to something reasonable. People that
> want to exchange data via the public relay would just need to send me the
> public bits from their nncp.hjson. Thanks to onion routing, the relay
> server doesn't need to know all the details of every system that may
> participate in the network, just the ones that will talk to it directly.
>
> The relay server could also easily enough operate as a Tor hidden service
> for those for whom that would be beneficial.
This sounds like a great idea. I've run bridge relays for IPFS, CJDNS,
and Syncthing before, and having them placed on a colo with plenty of
bandwidth tends to help the project quite a bit.
> Thanks to the new area support, if bandwidth is plentiful and the data sets
> aren't huge, a person could actually send packets to an area - direct via
> LAN and indirect via relay server - and they would be delivered by whichever
> method gets there first (though often wasting the bandwidth to the relay
> server; I wonder if there is a way to queue up an outbound packet that says
> "send via one of these lists of paths and delete the others once it's
> sent?")
Send them all and drop duplicate packets at the receiving end. Unless
one of those forwarded paths is extremely low bandwidth (geosynch
satellite, dialup, etc.) that should work fine as long as the daemon
tracks what packets it's received.
> * Other alternatives
>
> I've done some experimentation with using Syncthing as a transport for NNCP
> packets (generally with nncp-xfer but nncp-bundle can also work). This is a
> pretty interesting transport, since it is fully distributed already and runs
> on Android phones too. A phone can literally be the carrier between two
> remote sites -- get in range of the local wifi, Syncthing syncs up, NNCP
> sees packets, and boom! Content processed.
>
> I think, though, that Syncthing doesn't really lend itself to untrusted
> members in the mesh, at least not in the way we'd need for NNCP.
>
> One could also route NNCP messages over UUCP. But then.... why?
>
> Thoughts?
>
Don't sell Syncthing on a laptop short as a transfer vehicle. My ride
to work passes through areas of no signal, but I have space to have my
laptop open and be typing away the whole time. Changes pile up in my
local git repositories and in my Syncthing directory, and then when I
get in to the office I can run "git push" and Syncthing takes care of
the non-version-controlled part. Office documents, photo editor files,
media, etc. This is particularly handy if the office firewall blocks
Syncthing from the outside world but not between systems inside it -
I've worked a couple of places like that.
--
tidux@sdf•org
SDF Public Access UNIX System - http://sdf.org
prev parent reply other threads:[~2021-07-31 12:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 0:41 A Public NNCP relay John Goerzen
2021-07-30 5:52 ` Shawn K. Quinn
2021-07-30 8:57 ` Sergey Matveev
2021-07-31 12:12 ` Jonathan Lane [this message]