public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* NNCP road warrior
@ 2022-01-06 20:54 John Goerzen
  2022-01-08  0:57 ` Jonathan Lane
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: John Goerzen @ 2022-01-06 20:54 UTC (permalink / raw)
  To: nncp-devel

So I have been reflecting on the recent conversations about two
different routes and such, and thought "can we solve this problem at a
different layer?"

I've been looking into two options that would be very interesting here.

One is Yggdrasil network, https://yggdrasil-network.github.io/ .  This
is an overlay network atop the public Internet, that is fully end-to-end
encrypted all the time.  More particularly, the entire global network is
an auto-healing mesh, so if you take your laptop from home to work, it
will find a new path online (or re-establish a link with the same peer)
and your IP address remains the same.  IP addresses are v6 only and are
derived from the node's public key, so each person gets basically a
globally-routable static IP, plus also a /64 subnet if you like.  You
can also run Yggdrasil in an entirely closed network by simply never
connecting any of the nodes to a public peer on the main network (though
the moment one node is connected to the main network, they all are
reachable there via mesh routing)

Tinc vpn https://tinc-vpn.org/ is another option.  While it came along
long before Yggdrasil, I think of it as sort of a private-only
alternative.  Like Yggdrasil, it has mesh routing so you can reach any
of your nodes via any others so long as there is a path somewhere,
somehow.  Unlike Yggdrasil, it's aimed more at traditional VPN uses and
lets you specify your own IP ranges, routing between networks, etc.

A sort of third option is Tor.  I've tried this for awhile, and operate
a couple of nncp-daemons as a Tor onion service.  This achieves the
portability I'm looking for, but is slow.  EXTREMELY slow.  So slow, in
fact, that NNCP seems to have a 10-second timeout on connect that often
gets triggered.

Here's my idea...  for, say, sending things out from my laptop: I can
have the default addr for the destination (say, lan) be hardcoded to an
IP that is only reachable on the lan.  Then, when I am traveling, I can
optionally manually trigger a call to a different address -- its tinc or
Yggdrasil one -- if I am at a place with good enough Internet service,
etc.  I think that should all work reasonably well.  Of course, if I
don't care about sending 10GB backups over tethered 4G, I could just
always use the tinc or Yggdrasil IP instead.

This doesn't resolve EVERY use case -- for instance, if my home box is
down and I still want to get backups out by sending some stuff via
something else -- but it does help, I think.

John

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-01-14  8:03 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-06 20:54 NNCP road warrior John Goerzen
2022-01-08  0:57 ` Jonathan Lane
2022-01-08 11:26   ` Sergey Matveev
2022-01-08 21:00     ` Jonathan Lane
2022-01-12 21:40   ` John Goerzen
2022-01-08  7:17 ` Koushik Roy
2022-01-12 22:07   ` John Goerzen
2022-01-08 11:12 ` Sergey Matveev
2022-01-12 22:13   ` John Goerzen
2022-01-14  8:03     ` Sergey Matveev