public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Re: Thoughts on flexible mesh-routing of NNCP packets
Date: Sun, 31 Jan 2021 14:19:40 +0300 [thread overview]
Message-ID: <YBaSWK/CuA14s16A@stargrave.org> (raw)
In-Reply-To: <878s89oae8.fsf@complete.org>
[-- Attachment #1: Type: text/plain, Size: 9171 bytes --]
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.
>In this example, node1 is wanting to send a packet to node5 via
>intermediaries. [...]
Everything in your example is correct!
>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.
>The other thing that follows from this is that if node3 were compromised, the
>worst it can do is fail to relay packets. [...]
Yep, also everything is true.
>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 :-)
>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.
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"
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.
Initially I though just about using rsync to share nncp-xfer-compatible
directory with some remote servers. And I planned to create
Noise-encrypted link to run rsync-protocol inside. But I discovered that
rsync protocol just has no specification at all -- it is just coded in
the software. So I created "sync protocol" for its "replacement", trying
to make as few roundtrips as possible (however it is still uses TCP).
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.
Syncthing is another thing I should also try :-). However personally
have no tasks for it.
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:
* DAT -- JavaScript, npm... no, thanks. However I like the idea
* ZeroNet -- Python, that is not fast and from year to year is becoming
more burdensome to use it with all that PyPI infrastructure permanent
regression (rsync ability to mirror it was removed and replaced with
constantly badly working bandersnatch and constantly unavailable CDN;
then they removed pip search; then they removed Py27; then many
packages removed Py35 support; and still nearly none of packages uses
checksums and strict version for their dependencies, basically leading
to completely undeterministic builds that hardly ever can be done
without manual interventions). Also ZeroNet, as I remember, requires
to use the browser with JavaScript. However idea is good
* TahoeLAFS -- just for simple file sharing it is just too heavy, too
slow and hard to manage. It is for other kind of tasks, that I
personally have ever met. But I very like idea of that project
* IPFS -- like the idea, but... literally for several years I tried to
setup and use it once per half-year/year and it worked ONLY once. I
tried it only on FreeBSD. Some attempts just can not build it, because
of hard-coded-Linux specific stuff. Some attempts *without* any
questions and precautions downloaded some binaries from the Internet,
silently trying to run them. That is *completely* unacceptable
behaviour, so all next times I tried IPFS -- I deeply check every step
of building/installation. And when I got it build... it just either
segfaults or consumes *all* available RAM, leading system to swap. So
literally I have seen it working (able to run at least for a day, not
segfault and being able to transfer files) many years ago when the
project was very young
* CJDNS -- I very like the idea and its simple protocol, doing exactly
what is should do, without any kind of additional and sometimes
harmful and unneeded stuff like anonymization, built-in
cryptocurrencies, DNS alternative and so on. Anonymization requirement
greatly complicates all the things and basically it hardly can be
achieved without efficiency regression. I have nothing against
anonymity, privacy, but not everyone and not every tasks want them.
There are many tasks requiring *efficient* overlays, *efficient*
"mesh" networking. And CJDNS was just that kind of needed creation! It
worked pretty good when using with own nodes. But when I connected to
Hyperboria, it segfaults randomly possibly once per day, possibly
after ten minutes. So it was not workable when connected to
Hyperboria, possibly because of various used software versions in it.
Do not know. Yggdrasil project, that is written for replacement and
written on Go -- was working very stable (however only with "own"
nodes, no any kind of global Hyperboria-network)! And it is one of few
projects I can recommend to use. However seems it could be interesting
to NNCP only as an overlay transport, probably when both nodes behind
the NAT for example
* GNUnet -- coolest thing from academic point of view (the ideal
creation for cypherpunk-world!), but never actually usable in practice
(tried many years ago last time)
* Freenet, I2P, YaCy -- I have *never* seen really workable software
written on Java. No offence to any kind of developers, but I literally
see, that after several days/weeks of working, all of that software
just consumes more and more RAM and become "completely" unresponsive.
I assume that when there are many "objects" in their databases
(Freenet, YaCy), they starts to "lag" so heavily, that completely
unresponsive to nearly all commands. I tried I2P C++ implementation --
it worked much better, but... without any known reasons, it just
becomes unresponsive to the locally running eepsites: traffic seems
relaying, but locally "hosted" eepsites just stops answering. i2pd was
usable only when restarted possibly once per half and hour
I know that all of that seems pretty strange. Many people uses those
projects. But, most of them do not use FreeBSD and most of people uses
proprietary Java JVMs. So possibly most of that projects just do not run
good on FreeBSD, because of small (or lack) of testing on it, and Java
sucks probably because of OpenJDK (I heard about that many times). But
summary is: there are many projects with interesting and good ideas, but
only Tor works really perfectly good and probably Yggdrasil (I hope
mainly because of Go). But I assume that Tor has several times more
founding that all of other projects together.
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 :-).
So, being the software developer, I just must stop whimpering and
complaining and do the job myself. But... lack of time, damned lack of
time. That is why people just have to used proprietary and far from
ideal solutions because other ones just do not work in practice, or just
much more expensive to run and use. Software development is very
expensive thing. And portable software, as I can see with my FreeBSD
experience, is hard to do right.
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!
--
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 --]
next prev parent reply other threads:[~2021-01-31 11:19 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 [this message]
2021-02-01 6:21 ` John Goerzen
2021-02-01 8:39 ` Sergey Matveev
2021-01-31 15:16 ` Sergey Matveev