Why build this blog, or anything, on IPFS?
teetotality.blog
Why build this blog, or anything, on IPFS?
1–10 of 156 posts
Re: Why build this blog, or anything, on IPFS?
#2I've seen hugely varying IPFS latency. `time curl -o- https://teetotality.blog/posts/how-this-blog-was-made/` took > 20 seconds, for example, yet https://ipfs.io/ipns/teetotality.blog/ returned in under a second.
I'd be really interested in a "what to do and what not do" wrt IPFS to avoid those 20s (or completely non-functioning) URLs.
Re: Why build this blog, or anything, on IPFS?
#3> 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 solution that doesn't involve third party, please suggest.
I think I will have to wait until my ISP implements IPv6. That could take another decade :/
Re: Why build this blog, or anything, on IPFS?
#4I've seen hugely varying IPFS latency. `time curl -o- https://teetotality.blog/posts/how-this-blog-was-made/` took > 20 seconds, for example, yet https://ipfs.io/ipns/teetotality.blog/ returned in under a second. I'd be really interested in a "what to do and what not do" wrt IPFS to avoid those 20s (or completely non-functioning) URLs.
You're not really using IPFS here. The gateway that responds to the requests over at teetotality.blog is the one that actually communicates with IPFS, then forwarding the content to you.
The traditional web works with the concept of timeouts set by the owner. So if you request some content, and it's unable to find it within X seconds, the request gets cancelled.
IPFS (the network, not gateways) works differently, as the use case is different. Basically, there is no "requests". You simply put in a "ask" in the DHT about who has this content. If someone finds someone who provides the same content, then it tells you about it.
IPFS in itself doesn't have any timeouts, as the model is different. The use case is basically "I need this content, no matter how long time it takes and from who".
So, the difference between DNS addresses responding with different times, comes up to the maintainer of the gateway. Sometimes it's more connected to other nodes (like probably ipfs.io's gateways are) and sometimes they employ a longer cache for content (cloudflare's gateway have a long cache) and it makes the resolution time faster/slower.
Re: Why build this blog, or anything, on IPFS?
#5> 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…
Networks such as cjdns and secure scuttlebutt can help you overcome this problem, but introduces new ones (or introduces different models that are not already widely deployed)
- [0] https://github.com/cjdelisle/cjdns/
- [1] https://scuttlebutt.nz/
Re: Why build this blog, or anything, on IPFS?
#6> 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…
Your ISP implementing IPv6 won't be enough: One can't reach it from the outside, as long as not "everybody" else has IPv6.
Re: Why build this blog, or anything, on IPFS?
#7It's pieces like these that remind me why good writing skills are important, and one shouldn't stray from the basics unless they're fully aware of the trade-offs. For this article, it would be: write a better hook, and make sure to include a rudimentary thesis statement, because I wasn't able to deduce what you were trying to persuade me of, within the first few paragraphs.
With a title like "Why build this blog -- or anything -- on IPFS?" You were trying to persuade me, right?
I had to read through what is essentially every single cooking recipe on the web, before I got to the actual filling. I.e a whole lotta aimless wandering and musing, that is only tangenitally related to the topic at hand, before giving me what the title promised. Similarily to cooking blogs, this page is 2/3 filler, and 1/3 actually giving me what the title promised "So……why IPFS?"
> 1. Ownership, control, censorship
The author goes on to chastise Medium's censorhsip practices, but not too long ago he mentioned self-hosted Wordpress and staticly-generated Github pages. Wordpress and Github pages get over these hurdles and are easier to setup than IPFS.
> 2. Resilience
Suffice to say, the point of this pargraph was "DNS and HTTP unrobust, webservers fail under unforseen circumstances." Ok, well how does IPFS do things differently? You never explained how IPFS works, much less how it gets over any of the aforementioned issues you outlined.
> 3. Elegance
> But I will say that content addressing strikes me, and many software people who come across it, as obviously superior to host-based addressing along certain dimensions.
Never touched upon or elaborated.
> Plus, it's super cool. You should try it!
Atleast you have a call to action. Otherwise, this post fails to even come close to making me interested in IPFS.
Re: Why build this blog, or anything, on IPFS?
#8ISPs 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.
Re: Why build this blog, or anything, on IPFS?
#9ISPs 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.
Re: Why build this blog, or anything, on IPFS?
#10> 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…
Your ISP implementing IPv6 won't be enough: One can't reach it from the outside, as long as not "everybody" else has IPv6.
Right. Couple of decades in that case.