Wordpress is unlike github pages or medium. In theory a LAMP server could run on everyone's home router, and they 'd publish their blog there. With commercial interest , network configurations would change to accomodate that, and people wouldn't lose their content when any service decides to shutdown. It's scary how much of the web is being lost , i would wager most links to nonocorporate sites > 10 years old barely work (has anyone studied the link rot?).
Why build this blog, or anything, on IPFS?
21–30 of 156 posts
Re: Why build this blog, or anything, on IPFS?
#22ISPs have made it really expensive to get a static IP. I maintained a commercial connection for way to many years because I would remote into my home systems.
That's not ISPs' doing, it's the natural outcome of IP address exhaustion. BTW, there are ways to "remote into" your home systems even if you don't have a static IP. You can even make it work if your home systems aren't directly accessible due to NAT.
Zerotier is an awesome tool for this.
Re: Why build this blog, or anything, on IPFS?
#23Earlier quoted context omitted.
>This blog is “built” on cloudflare apparently. You can read more about why that is here: http://teetotality.blog/posts/how-this-blog-was-made/
I found that too as the article linked raised more questions that it answered. I was like "how can I be reading this if it's not using DNS?" And from the link this explanation: > It updates a dnslink pointer at Cloudflare, which allows Cloudflare's DNS to direct teetotality.blog HTTP traffic to the correct IPFS hash address via their IPFS Gateway. So even though you've (probably) reached this page through a regular o…
The blog is hosted on IPFS. To allow normal web browsers without IPFS support to view the website they use Cloudflare's IPFS gateway, which is a service that serves content from IPFS over normal HTTP.
Re: Why build this blog, or anything, on IPFS?
#24> even go super old-school and run a web server at home. It's not as if we're short on options in 2020. Though it's old school, it's incredibly difficult to run server at home now at least in India. The network I connect to is behind a NAT which is behind another NAT. At least that's what I saw when I tried to host my blog on Raspberry PI at home over a year ago. Ultimately I gave up on that endeavor. If anyone has s…
You can always use https://ngrok.com and other similar "tunneling" solutions. It works like a charm:
Re: Why build this blog, or anything, on IPFS?
#25> even go super old-school and run a web server at home. It's not as if we're short on options in 2020. Though it's old school, it's incredibly difficult to run server at home now at least in India. The network I connect to is behind a NAT which is behind another NAT. At least that's what I saw when I tried to host my blog on Raspberry PI at home over a year ago. Ultimately I gave up on that endeavor. If anyone has s…
I ran my vlog on RasPi and did everything in a static generated way. I configured Cloudflare to cache everything for 30 days. Finally I have a cache warming script that requests each static file after I purge the cache (could be better by only purging and warming changed files, like via a Makefile). With this approach, a tunnel with a public port and IP could run minimally during the purge/warm cycle and then be shut down.
I solicit feedback via email rather than having public comments, and upcoming authenticated areas are done via Auth0 tokens.
Re: Why build this blog, or anything, on IPFS?
#26Last I checked a lot of the consensus were that the Dat project was more mature than IPFS and that it had some advantages over IPFS (such as not using as much resources to run).
How is it now? Is it more mature? Even though I actually even sub to their newsletter I haven't really been keeping up to date if they have made any major releases.
Not to be a downer on IPFS at all, btw. I'm very glad that both it and Dat exist. IPFS has always seemed like a much larger undertaking and it is cool thst they are trying to push the dweb even further. We need that just as much as we need Dat, which with its inclusion in the Beaker browser for example really serves as a super cool demo of what dweb can give us in the future.
Re: Why build this blog, or anything, on IPFS?
#27ISPs have made it really expensive to get a static IP. I maintained a commercial connection for way to many years because I would remote into my home systems.
As long as it is not behind NAT, most DNS providers would let you easily change it via an API call.
Re: Why build this blog, or anything, on IPFS?
#28> From a certain perspective, the internet and the web as we know them (including fundamental technologies such as DNS, TCP/IP, HTTP, SMTP, and even Javascript) are flawed in fundamental ways. Leaving the technicalities aside, how do these flaws manifest? It is hard to stop bad actors from doing bad things: sending too many emails, stealing sensitive data, flooding websites with traffic, spreading false facts and bifurcating the shared reality that allowed for a democratic global order.
I would argue that this is even more of a problem with decentralized services because there is no one to define (or police for) spam or bad content.
Re: Why build this blog, or anything, on IPFS?
#29IPFS still has a long way to go until it is useable in my opinion. The default configuration for the desktop client will gladly keep open 1000+ peer connections and will happily degrade your usual internet experience.
In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482
It's a shame if you ask me.
Re: Why build this blog, or anything, on IPFS?
#30The thing I worry about with IPFS is privacy. If you use IPFS directly (as intended, not via a public gateway), and you visit a site, then you are automatically going to be seeding (like a torrent) the visited content, and thus you will be announcing/broadcasting the fact to the world that you (your node/your IP) have visited it. My current understanding is that this cannot really be avoided, since one needs to be able to find the nodes that have the content for any given hash.