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