Looks like innernet relies on third party "Nebula" from "Slack Technologies" (commercialised IRC) which uses 70.199.182.92.
Perhaps the definition of "self-hosted" varies from person to person. The definition I subscribe to for "self-hosted" peer-to-peer is that I have to supply the publicly reachable IP address and run a supernode on it. (I prefer supernodes that only provide IP:port information for peers to directly connect and do not pass any traffic once the peers are connected.) Many of the so-called "peer-to-peer" projects I see today provide the IP address of a server run by a third party as part of their default configuration, with the option that a user could run their own server on their own IP address. (How many users do that.) Under the definition I subscribe to, nothing is for "free". I have to pay for the publicly reachable IP address and run the supernode from that address. Under another person's definition of "self-hosted", a third party might be hosting a necessary server. If they stop providing that service, the "self-hosted" solution no longer works.
Your understanding of how Nebula works is incorrect.
If you checked Nebula's readme you'd see the following:
> Nebula lighthouses allow nodes to find each other, anywhere in the world. A lighthouse is the only node in a Nebula network whose IP should not change. Running a lighthouse requires very few compute resources, and you can easily use the least expensive option from a cloud hosting provider. If you're not sure which provider to use, a number of us have used $5/mo DigitalOcean droplets as lighthouses.
This puts Nebula in a relatively small group of what I would call true self-hosted overlay networks (by the definition of "self-hosted" I subscribe to). Kudos for that.
What drew my attention was the remote IP address in
Anyway, while I would not necessarily choose to run Nebula myself (I prefer smaller overlay networks, for example), it is certainly an exception to the pattern I see in so many other "self-hosted" peer-to-peer projects. I apologise if the comment I submitted implied otherwise.
Note I never suggested innernet "runs on Nebula". The words I used were "innernet relies on Nebula." Of course, that, too, is incorrect. The blog post was just comparing innernet to Nebula. My bad! I am just too cynical about peer-to-peer projects since so many fall into the same patterns I dislike; hence I skimmed where I should have read more closely.
Perhaps the definition of "self-hosted" varies from person to person. The definition I subscribe to for "self-hosted" peer-to-peer is that I have to supply the publicly reachable IP address and run a supernode on it. (I prefer supernodes that only provide IP:port information for peers to directly connect and do not pass any traffic once the peers are connected.) Many of the so-called "peer-to-peer" projects I see today provide the IP address of a server run by a third party as part of their default configuration, with the option that a user could run their own server on their own IP address. (How many users do that.) Under the definition I subscribe to, nothing is for "free". I have to pay for the publicly reachable IP address and run the supernode from that address. Under another person's definition of "self-hosted", a third party might be hosting a necessary server. If they stop providing that service, the "self-hosted" solution no longer works.