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| http://www.nncpgo.org/download/nncp-8.13.0.tar.xz https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz https://www.nncpgo.org/download/nncp-8.13.0.tar.xz http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.asc https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.asc http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.sig https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.sig -- Sergey Matveev (http://www.stargrave.org/) LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A