public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* A Public NNCP relay
@ 2021-07-29 0:41 John Goerzen
2021-07-30 5:52 ` Shawn K. Quinn
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: John Goerzen @ 2021-07-29 0:41 UTC (permalink / raw)
To: nncp-devel
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.
* The need
I happen to have a nice colo server, and I run NNCP on it, just
for myself. This is handy, for instance, when away from home: a
laptop can send messages bound for my home system to it, the home
system can dial in and get them, and there's no messy firewall
stuff involved. (I can also run NNCP over tor, but that is a bit
more flaky due to connection timeout expectations over NNCP).
Sometimes if I'm traveling, I would send backups via this system,
knowing that they are at least off my laptop and existing
somewhere else, even if my machine at home is powered down.
This sort of thing would also facilitate using NNCP to exchange
data between friends. Managing ports, etc. for n people gets more
difficult as n increases above 1.
* 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.
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?")
* What about reliability?
Let's say NNCP interest explodes. Clearly the world wouldn't want
a single relay server. I could imagine a situation in which major
relays know about each other and can exchange data with each
other. Of course, we would still be talking UUCP-style source
routing - not automatically rerouting if a relay is down (unless
area-style broadcast is used). But it would permit a fairly
simple via tweak to take other paths if a relay becomes
unreliable.
* Some nice properties of the relay
Thanks to NNCP's design, the relay would be capable of:
- Routing email without having to expose a MTA to nodes at all, or
being able to see the content of messages at all
- Of course, that doesn't apply just to email, but also files and
so forth.
- Thanks to persistent connections, data could be routed pretty
quickly for online hosts.
- It could enable some more interesting things (eg, FTP-like
services over NNCP) for experimentation.
* 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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A Public NNCP relay
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
2 siblings, 0 replies; 4+ messages in thread
From: Shawn K. Quinn @ 2021-07-30 5:52 UTC (permalink / raw)
To: nncp-devel
On 7/28/21 19:41, John Goerzen wrote:
> 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.
I like the idea, and would be quite interested.
> 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.
I've played with Syncthing a bit. The disadvantage of trying to use
Syncthing for this is you need to be running nncp-xfer or nncp-bundle
every so often on the Syncthing directory. There are some good use cases
for Syncthing but this strikes me as a tight fit if not an outright misfit.
I think a better solution is an NNCP node running on the phone itself,
perhaps with some kind of GUI front-end to facilitate doing certain
operations manually.
--
Shawn K. Quinn <skquinn@rushpost•com>
http://www.rantroulette.com
http://www.skqrecordquest.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A Public NNCP relay
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
2 siblings, 0 replies; 4+ messages in thread
From: Sergey Matveev @ 2021-07-30 8:57 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]
Greetings!
*** John Goerzen [2021-07-28 19:41]:
>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.
>Thoughts?
Personally I have no strong opinion about all of that. I assume that all
NNCP users are rather advanced users and all of them have either their
own home server, or VPS or something similar. So hardly can imagine if
public relay would be really useful. But that are only thoughts, no any
confidence in them :-).
Possibly we can use it (also) for sharing of something useful among all
of few NNCP users. But... I do not know what exactly could it be. New
NNCP release tarballs through multicast area? Some kind of
chat/maillist/echo conference -- but there is already that maillist
exists and we have to determine format of the messages and exec-commands
for that tasks (for example simple recfile-formatted UTF-8 plaintext
message with From/Date/Subject lines and exec-command accepting it
through stdin). It is solvable and interesting task of course, but I am
fear that it could lead to creation of yet another class of messaging
system :-)
But anyway I would be glad to help somehow with all of that. I can also
provide my resources two: 100Mbps connection to home server with several
hundred of gigabytes of free diskspace.
>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.
I also use ZFS quotas at home for preventing accidental running out of
disk space :-)
>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?")
At first sight I do not like idea to remove others, possible duplicate,
packets, because there are no delivery guarantees of the first one. I
think it is better to have excess packets, possibly leading to more
transferred traffic, but with higher probability of guaranteed delivery.
>One could also route NNCP messages over UUCP. But then.... why?
Unrelated remark, but that week I successfully transferred hundreds of
packets for several days through the serial COM-port with NNCP, by
running relatively easy setup PPP with link-local IPv6 addresses (no IP
configuration was necessary) and multicast nodes discovery. Writing of
sliding-window protocol with *efficient* guaranteed data delivery is not
trivial task and it is easier to setup PPP+TCP (that are still available
out of box in most BSD systems I believe), that will also work good with
the modems, not only null-modem connection.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A Public NNCP relay
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
2 siblings, 0 replies; 4+ messages in thread
From: Jonathan Lane @ 2021-07-31 12:12 UTC (permalink / raw)
To: nncp-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-07-31 12:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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