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