public inbox for nncp-devel@lists.cypherpunks.ru Atom feed
* NNCP discussion on comp.mail.uucp @ 2021-01-04 5:50 John Goerzen 2021-01-04 8:36 ` Sergey Matveev 0 siblings, 1 reply; 5+ messages in thread From: John Goerzen @ 2021-01-04 5:50 UTC (permalink / raw) To: nncp-devel Hi folks, Just thought I'd point you to this thread I started on comp.mail.uucp: https://groups.google.com/g/comp.mail.uucp/c/E1iFGMkULiU There's some interest there (despite it being a mostly dead newsgroup). - John ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NNCP discussion on comp.mail.uucp 2021-01-04 5:50 NNCP discussion on comp.mail.uucp John Goerzen @ 2021-01-04 8:36 ` Sergey Matveev 2021-01-04 17:46 ` John Goerzen 0 siblings, 1 reply; 5+ messages in thread From: Sergey Matveev @ 2021-01-04 8:36 UTC (permalink / raw) To: nncp-devel [-- Attachment #1: Type: text/plain, Size: 1439 bytes --] *** John Goerzen [2021-01-03 23:50]: >Just thought I'd point you to this thread I started on comp.mail.uucp: Cool! I am subscribed to that group, but receiving only digests, that just lacks nearly everything, except for the subjects. And because I am subscribe using "+subscribe@googlegroups" method (no Google Account), I have got no way to change that digest mode to ordinary one and participate in discussion. The main difference between UUCP and NNCP, in my opinion, except for (current) lack of explicit ability to use serial lines, is that NNCP is a friend-to-friend/darknet network, where each (well, with minor exceptions of course) participant (on the packet's path) has to be explicitly known and added to the list of known neighbours. While UUCP is a greynet, where even "anonymous" (unauthenticated, unidentified) peers can work. And no, of course there are no plans for making NNCP opennet, by automatic fetching of peer's public key via DNS, because... well, it will simply destroy and ruin the whole network and its resources because of no trust and control of communicating peers. F2F (darknet) self-governed networks (FidoNet as an example of global scale world-wide completely decentralized one) are more complicated to administer and support, but they are immune to Sybil attacks. -- 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] 5+ messages in thread
* Re: NNCP discussion on comp.mail.uucp 2021-01-04 8:36 ` Sergey Matveev @ 2021-01-04 17:46 ` John Goerzen 2021-01-05 15:07 ` Sergey Matveev 0 siblings, 1 reply; 5+ messages in thread From: John Goerzen @ 2021-01-04 17:46 UTC (permalink / raw) To: Sergey Matveev; +Cc: nncp-devel On Mon, Jan 04 2021, Sergey Matveev wrote: > *** John Goerzen [2021-01-03 23:50]: >>Just thought I'd point you to this thread I started on >>comp.mail.uucp: > > And no, of course there are no plans for making NNCP opennet, by > automatic fetching of peer's public key via DNS, because... > well, it > will simply destroy and ruin the whole network and its resources > because > of no trust and control of communicating peers. F2F (darknet) > self-governed networks (FidoNet as an example of global scale > world-wide > completely decentralized one) are more complicated to administer > and > support, but they are immune to Sybil attacks. That suits me perfectly. I think that since UUCPNET has been dead for more than two decades now, the only remaining UUCP networks are the small friend-to-friend kind anyhow. BTW, I have another post on the topic of ZFS and non-ZFS backups over NNCP: https://changelog.complete.org/archives/10186-more-topics-on-store-and-forward-possibly-airgapped-zfs-and-non-zfs-backups-with-nncp Also it occurred to me that one feature I miss from UUCP that would be great in NNCP would be automatic tossing. With UUCP, the system can start up the tosser (uuxqt) immediately after hangup on a call with uucico. I think it would be great to, after receiving packets, have the various NNCP programs (nncp-xfer, nncp-bundle, nncp-daemon, nncp-call[er]) have an option to start a toss, possibly limited to that one node. In the case of the networkable ones, the logic would probably be "after receiving at least one packet from the remote, and the number of packets the remote has for us has dropped to zero, run a toss". This would actually often permit rapid response to freqs and similar since the toss could often be accomplished in less than the onlinedeadline. And it would be one less process to run or cron. UUCP also had automatic calling (queue something and it initiates a call) but that one is both more complex and less useful (since it can be easily scripted). - John ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NNCP discussion on comp.mail.uucp 2021-01-04 17:46 ` John Goerzen @ 2021-01-05 15:07 ` Sergey Matveev 2021-01-05 16:01 ` John Goerzen 0 siblings, 1 reply; 5+ messages in thread From: Sergey Matveev @ 2021-01-05 15:07 UTC (permalink / raw) To: nncp-devel [-- Attachment #1: Type: text/plain, Size: 1659 bytes --] *** John Goerzen [2021-01-04 11:46]: >I think that since UUCPNET has been dead for more >than two decades now, the only remaining UUCP networks are the small >friend-to-friend kind anyhow. Seems so indeed. >NNCP automatic tossing. >also had automatic calling Both of these looks like easy to add. >BTW, I have another post on the topic of ZFS and non-ZFS backups over NNCP: >https://changelog.complete.org/archives/10186-more-topics-on-store-and-forward-possibly-airgapped-zfs-and-non-zfs-backups-with-nncp Here I just want to add trivial comments for https://floss.social/@jgoerzen/105499269925205743 * Protection against Silent Data Corruption. Just want to mention that automatic self-healing (data correction) is performed also on a setup with just single disk. "Data" blocks, by default has just single copy and obviously they can not be repaired without redundancy. But metadata blocks ("inodes", dataset/zvol descriptions, block pointers, and so on) by default has copies=2 and physically they have two copies on the disk. Very important metadata blocks (meta object set (MOS), überblock) has copies=3. So metadata has (by default) redundancy and can be repaired by reading the copy from another part of the disk * Built-in #compression with fast algorithms. Compression (at least the most simple rle one) should be enabled also because sparse (zero-filled) blocks won't be allocated at all. If no compression is enabled, then sparse files will be allocated and written to the disk -- 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] 5+ messages in thread
* Re: NNCP discussion on comp.mail.uucp 2021-01-05 15:07 ` Sergey Matveev @ 2021-01-05 16:01 ` John Goerzen 0 siblings, 0 replies; 5+ messages in thread From: John Goerzen @ 2021-01-05 16:01 UTC (permalink / raw) To: Sergey Matveev; +Cc: nncp-devel On Tue, Jan 05 2021, Sergey Matveev wrote: >>NNCP automatic tossing. >>also had automatic calling > > Both of these looks like easy to add. Sweet! > Here I just want to add trivial comments for > https://floss.social/@jgoerzen/105499269925205743 > > * Protection against Silent Data Corruption. Just want to > mention that > automatic self-healing (data correction) is performed also on > a setup > with just single disk. "Data" blocks, by default has just > single copy > and obviously they can not be repaired without redundancy. But > metadata > blocks ("inodes", dataset/zvol descriptions, block pointers, > and so on) > by default has copies=2 and physically they have two copies on > the > disk. Very important metadata blocks (meta object set (MOS), > überblock) has copies=3. So metadata has (by default) > redundancy and > can be repaired by reading the copy from another part of the > disk Very true indeed. > * Built-in #compression with fast algorithms. Compression (at > least the > most simple rle one) should be enabled also because sparse > (zero-filled) blocks won't be allocated at all. If no > compression is > enabled, then sparse files will be allocated and written to > the disk I did mention this one in the thread. I personally use lz4 on all my zpools but I'm happy to see that zstd has been integrated now as well! Should have better compression ratios AND better performance. - John ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-05 16:03 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-04 5:50 NNCP discussion on comp.mail.uucp John Goerzen 2021-01-04 8:36 ` Sergey Matveev 2021-01-04 17:46 ` John Goerzen 2021-01-05 15:07 ` Sergey Matveev 2021-01-05 16:01 ` John Goerzen