public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Re: Thoughts on flexible mesh-routing of NNCP packets
Date: Mon, 01 Feb 2021 00:21:30 -0600 [thread overview]
Message-ID: <87zh0omhp1.fsf@complete.org> (raw)
In-Reply-To: <YBaSWK/CuA14s16A@stargrave.org>
On Sun, Jan 31 2021, Sergey Matveev wrote:
> Greetings!
>
> *** John Goerzen [2021-01-31 01:03]:
>>First I want to make sure I understand how the onion routing in
>>NNCP works,
>>because I think it's somewhat different than Tor (not trying to
>>preserve the
>>anonymity of the sender). Is this description correct?
>
> Yes, it is not intended to preserve identity of the sender. But
> it tries
> to preserve the whole transmission path knowledge for
> intermediate and
> target points.
That makes perfect sense (and is fine by me). Thanks for the
confirmation.
>>Permissions in UUCP are based on what the neighbor can do, not
>>what the
>>source can do, if I remember correctly.
>
> I do not remember too, but seems you are right. NNCP is
> different there.
Yes, and that's good!
>>If that is correct, that would imply that it would be difficult
>>to, say,
>>bypass node2 on the way to node5 -- though it would be
>>(theoretically) easy
>>enough to send from node1 to node1.5 and then on to node2.
>
> Yes, it complicates some things. However actual path can be
> extended in
> reality: node2 can have "node3: via:node2.5" option that will
> send
> transitient packet additionally through node2.5, without node1's
> knowledge. That was just a remark, that "full" path is not so
> "hardcoded" in the packets :-)
That is very interesting. I hadn't realized that!
Which reminds me - when you get back a file from nncp-freq, or any
other event that sends something back, I'm assuming it uses the
via path (if any) defined on the system that's sending back the
response?
>>https://verbnetworks.com/research/store-forward-networks/
>>planted the idea in
>>my head: why not use Syncthing for this?
>
> First of all: do not forget that initially NNCP, with all that
> transition/via packets were developed only for offline data
> transmission, without online/network protocols in mind. So idea
> of
> transition packets/nodes was not about relying between network
> nodes,
> for example because of NAT between them. It is really better to
> use some
> kind of network shared directories in that case: FTP, NFS, 9p,
> rsync and
> all that kind of things.
Interesting. This seems like a perfect fit for Syncthing. It is
sort of like a distributed FTP or NFS.
> I have never used Syncthing and only heard of its name. Seems it
> is
> really some kind of very good tool for nncp-xfer! If you can
> "share"
Yes, I have been using it for some years now and am quite pleased
with it.
> only some part of directory hierarchy (directories you are
> "interested"
> in), if file renames (renaming of temporary file to "normal"
> fully
> written packet) are atomic/fast and even deletions will
> propagate, even
> you can setup relay nodes as you wish, then I see nothing
> against
> Syncthing. It is even written on Go, that is good.
Yes to all of these.
Only part of the directory hierarchy:
https://docs.syncthing.net/users/ignoring.html#ignoring-files
Renames are fast:
https://docs.syncthing.net/users/faq.html#is-synchronization-fast
Can set up relay nodes as you wish:
https://docs.syncthing.net/users/introducer.html
So I wouldn't suggest anybody just rip out nncp-call(er) and go to
Syncthing entirely; nncp-call and the daemon are quite useful and
more efficient than Syncthing would be in fixed topology cases, or
situations with a non-TCP transport.
But the nncp-xfer file format is *perfect* for this. A "leaf"
node can use the .stignore file (which also can have "include"
lines) to register its interest in just certain packets (perhaps
anything going to or from it). Relay nodes could carry the whole
thing. And when nncp-xfer imports packets, the deletion out of
the Syncthing tree would propagate. I hope to have the time to
set up and test this all tomorrow.
One particularly interesting use for this - Syncthing can to local
LAN discovery. Syncthing also runs on Android. So it is entirely
possible to use Syncthing as a NNCP "bridge" between two
disconnected networks, syncing up work whenever it connects to a
local LAN.
Of course, one could probably make nncp work in Termux on Android
also.
> https://verbnetworks.com/research/store-forward-networks/ --
> previously
> I have read documents about DTNs, but never known that software
> like
> ion-dtn exists! Some time I thought about creating fully
> DTN-protocol
> (like in RFC) capable implementation. Must look at it closer.
Same here.
> Syncthing is another thing I should also try :-). However
> personally
> have no tasks for it.
I saw your other message about issues with your patched Go
cryptography layer. I have been using Syncthing's debs for a long
time without issue, and I'm not a Go programmer so probably can't
help there, but Syncthing makes a very nice alternative to things
like Dropbox, or even Nextcloud, since it can be run entirely
serverless and disconnected.
> That article also mentions CJDNS (that has a much better working
> Yggdrasil continuation remake), DAT, IPFS, ZeroNet, TahoeLAFS.
> Below is
> completely my opinion and experience with all of them:
Thanks for this!
>
> * DAT -- JavaScript, npm... no, thanks. However I like the idea
Being an append-only log has me somewhat concerned. It seems to
be something like a "public Syncthing, but unidirectional." IPFS
seems to be catching on more than DAT at the moment.
> Many years ago I was very interested in all that stuff:
> anonymity,
> privacy, and so on, so on, so on. I am still interested, but
> VERY
> disappointed with the fact that hardly any of most of that kind
> of
> software works :-).
I keep trying to do my part around the edges, but yes, lack of
time is always an issue for me as well.
> But I will look closer at Syncthing, ION(-DTN). Thanks for
> sharing that
> information and thoughts!. And I still remember about
> asynchronous
> checksumming, checksumming during packets receiving and other
> issues,
> that are pretty high-priority tasks for NNCP!
And thank you, again, for NNCP. Unlike many of these other
things, it's fairly simple, well-documented, and secure and
private by default.
Heck, a person could even use Google Drive for the packets, if one
wanted.
- John
next prev parent reply other threads:[~2021-02-01 6:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-31 7:03 Thoughts on flexible mesh-routing of NNCP packets John Goerzen
2021-01-31 11:19 ` Sergey Matveev
2021-02-01 6:21 ` John Goerzen [this message]
2021-02-01 8:39 ` Sergey Matveev
2021-01-31 15:16 ` Sergey Matveev