public inbox for nncp-devel@lists.stargrave.org
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Tarballs availability over IPFS
Date: Fri, 20 Feb 2026 00:22:35 +0300 [thread overview]
Message-ID: <aZd_G1v31YfTnumd@stargrave.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 6906 bytes --]
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>
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
next reply other threads:[~2026-02-19 21:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 21:22 Sergey Matveev [this message]
2026-02-19 23:14 ` Tarballs availability over IPFS John Goerzen
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