public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: Sergey Matveev <stargrave@stargrave•org>
Cc: nncp-devel@lists.cypherpunks.ru
Subject: Re: Tarballs availability over IPFS
Date: Thu, 19 Feb 2026 17:14:13 -0600 [thread overview]
Message-ID: <87y0ko72d6.fsf@complete.org> (raw)
In-Reply-To: <aZd_G1v31YfTnumd@stargrave.org> (Sergey Matveev's message of "Fri, 20 Feb 2026 00:22:35 +0300")
Hi Sergey,
Sorry for the slow response here!
I've done some experimentation, and initially it looked like IPv4
connectivity was broken... but as I was digging into it, IPv6
connectivity worked, and then so did IPv4, so I'm puzzled.
I also discovered that a known_hosts file had reverted to a previous
version, and no longer had the record for master.git.stargrave.org.
I fixed that and had a successful sync!
I'm noticing that the direct links to the downloads in the Tarballs.html
page are gone. That does make it more difficult for people, since meta4
software isn't common and opening it up to manually extract a URL isn't
necessarily an easy thing for people. It would probably be good to have
the tar links again.
- John
On Fri, Feb 20 2026, Sergey Matveev wrote:
> Greetings!
>
> www.nncpgo.org is hosted on two servers in Russia: physical one at my
> home (with additional VPS to get IPv6 connectivity) in Moscow region,
> virtual one somewhere in St.Petersburg. Three different ASes involved
> in all that connectivity.
>
> Several years ago some foreign networks started to reject/ban traffic
> to/from Russian networks. Hetzner and other German ones come to mind
> first as an example. Cloudflare and OVH were also known to partially
> block access to their networks too.
>
> Couple of months ago network connectivity problems appeared on Russian's
> side to several big cloud/CDN providers, disrupting overall connectivity
> even more.
>
> Recently I discovered that https://nncp.mirrors.quux.org/ mirror is
> not accessible via any of my links I got. It is hosted on Canadian OVH.
> Sometimes no TCP connection can be made, sometimes it is stuck after
> a several KiBs. At least sometimes I could get small .meta4 files to
> check if that site is updated. Waiting for reply from John, but I doubt
> we got connectivity between our nodes for ssh+rsync-ing the website
> (maybe even email is not exchanged between us?).
>
> I am aware only of Western-located websites capable of hosting free
> software projects (SourceForge, GitHub, similar ones). Because of
> obvious reasons (of being under sanctions) there is no legal possibility
> to use any of those services for hosting the tarballs/website. People
> were suddenly banned (for example on GitHub) even just for visiting the
> sanctioned regions.
>
> Some Russian-based hosting companies still have data-centres at least in
> Europe. Maybe that would be helpful, but I highly doubt, because they
> still use their own ASes with Russian-related IP subnets. Maybe that
> will bypass Russian-located curtain, but not the much earlier appeared
> ones from the opposite sides.
>
> I was thinking about additional alternative paths of getting NNCP
> tarballs. Nearly all of decentralised filesharing solutions or anonymous
> (at least pretending to be so) networks work pretty badly in practice.
>
> For many years I tried from time to time building and using Tor
> (actually it worked fine, no building issues), I2P (with OpenJDK was
> always unusable; i2pd tend to work for a while, but soon any of the
> published resources were not responding), RetroShare (have never
> succeeded in building it), Freenet (tend to ate resources and soon stop
> responding at all), YaCy (same as Freenet or I2P -- unusable because of
> OpenJDK, I guess). GNUnet is only developer friendly and hardly was used
> by any considerable amount of people. Maybe they work better on
> GNU/Linux, but I tried building under FreeBSD solely.
>
> One notable exception was Yggdrasil overlay network. Comparing to its
> predecessor -- cjdns, which tended to segfault occasionally when
> connected Hyperboria network, Yggdrasil is pretty stable and reliable,
> as I can see for several years of its non-heavy usage. NNCP's Metalink4
> .meta4 files contained y-reachable links (y.www.nncpgo.org) a long time
> ago because of that.
>
> I also considered BitTorrent for tarballs distribution. But that will
> anyway need at least an initial connectivity between seeder and a
> leecher, which are in practice will be easily in netsplit locations. And
> frankly I just discovered that one of my computers behind NAT is not
> able to get my own torrent from my own hosted tracker/seeder. Maybe
> because it is BitTorrent v2 torrent and whatever hash-issues with the
> tracker/DHT. Could not investigate that for considerable amount of time.
> Tried three different clients, checked IPv4's NAT port forwarding, IPv6
> firewall rules, still failed. Even BitTorrent, an old known technology
> (although developing from time to time), is not so trivial to make work
> and debug sometimes :-)
>
> I had bad experience with IPFS nearly since its initial creation. Either
> it downloads some binaries during building attempt -- removed immediately
> after that unacceptable behaviour. Or it just does not build for unknown
> reasons. Or it just does not build because its (or its dependencies)
> code contains only *_linux.go files, failing to build under FreeBSD. Or
> it segfaults/panics during ordinary operations. Or it became just stuck
> and unable to share "hello world" file. I checked its progress once per
> couple of years and every time it disappointed me.
>
> Recently I recalled it and decided to examine again. It (kubo, reference
> implementation on Go) builds fine (actually I had to fix the single
> bash-script, because I do not have bash), without downloading something
> without my permission and works without unexpected panics. Currently
> have no claims to its workability. Although its DHT bootstrap nodes are
> located in OVH and DigitalOcean networks, it was able too bootstrap.
>
> So I will try to publish NNCP's tarballs additionally via IPFS. I
> understand that NNCP itself can be used (by cooperation) through
> additional intermediate hops to reach nncp.mirrors.quux.org mirror, but
> all of the (thoughts) written above also applies to my other projects too.
>
> % curl -s http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.meta4 | perl -ne 'print if /(url|<file)/'
> <file name="nncp-8.13.0.tar.xz">
> <url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
> <url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz</url>
> <url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
> <url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
> <url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz</url>
> <file name="nncp-8.13.0.tar.xz.asc">
> <url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.asc</url>
> <file name="nncp-8.13.0.tar.xz.sig">
> <url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.sig</url>
next prev parent reply other threads:[~2026-02-20 12:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 21:22 Tarballs availability over IPFS Sergey Matveev
2026-02-19 23:14 ` John Goerzen [this message]
2026-02-20 16:10 ` Sergey Matveev
2026-02-20 10:47 ` Marek Küthe
2026-02-20 18:08 ` Sergey Matveev
2026-04-17 10:26 ` Sergey Matveev