Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why build this blog, or anything, on IPFS?

teetotality.blog

Post reply on HN
Print view View original

141–150 of 156 posts

Re: Why build this blog, or anything, on IPFS?

#141

Post by davidgerard »

skybrian wrote: post #100
tetrisgm wrote: post #41

Disclaimer: I run the unofficial IPFS Discord and Matrix (found at https://permaweb.io/discord and /matrix) and have helped organize IPFS Meetups in SF. We also run an IPFS gateway and have built a groups app on top of IPFS and Textile. I generally agree with the conclusion, but there's a few downsides that aren't conveyed here. Let's look at the proposed upsides: 1) Ownership, control, censorship: That's partly corr…

I'm wondering if IPFS might be better thought of as a common data-publishing protocol that might be used to push content to any number of CDN's? So, you could publish content to IPFS and tell your favorite CDN to pick it up, and you pay them to keep it active. But IPFS isn't limited to one CDN, so you could always pick another one. And your users could also go through a different CDN. Or some people who really want t…

> I'm wondering if IPFS might be better thought of as a common data-publishing protocol that might be used to push content to any number of CDN's?

Think of the bits that work properly as "the web of BitTorrent magnet: links" and you'll have a reasonably accurate picture.

Re: Why build this blog, or anything, on IPFS?

#142

Post by davidgerard »

sneak wrote: post #48
jude- wrote: post #47

If you replace the word "IPFS" with "BitTorrent," this article is still true. Similarly, if you replace "IPFS" with "BitTorrent" in most of the comments here, the comments are still true. If you understand how BitTorrent works -- including its strengths and limitations -- you'll understand how IPFS works.

Minor nit: BitTorrent does not allow one to maintain a persistent URI to changing/updated data, as IPNS does.

I'm seeing others here point out that IPNS basically doesn't work - so it doesn't really either, in practice.

Re: Why build this blog, or anything, on IPFS?

#143

Post by imtringued »

I once thought about building an app based on IPFS but the problem is the lack of decentralized consensus. Only the Blockchain has cracked that problem and it is incredibly inefficient. The IPFS app would still require a central server and if that is the case then it would be better to just have some sort of public database backup with encrypted user data so that anyone can host their own fork and each fork can talk with each other through a standardized protocol. It would be a federated system like E-Mail.

Re: Why build this blog, or anything, on IPFS?

#144

Post by mmurthy »

StavrosK wrote: post #56
Sargos wrote: post #44

Earlier quoted context omitted.

I consider IPNS fundamentally broken and have stopped using it. ENS is better in almost every way and is extremely reliable so it's not that big of deal.

How can I register an ENS domain/id? I've found very little practical info on a cursory search.

I created a service to make it easy to buy and configure ENS domains in one step. Hope it helps! www.namestack.io.

Re: Why build this blog, or anything, on IPFS?

#145

Post by StavrosK »

mmurthy wrote: post #144
StavrosK wrote: post #56

Earlier quoted context omitted.

How can I register an ENS domain/id? I've found very little practical info on a cursory search.

I created a service to make it easy to buy and configure ENS domains in one step. Hope it helps! www.namestack.io.

That's helpful, thank you. Unfortunately it looks like .eth domains have already been squatted to hell.

Re: Why build this blog, or anything, on IPFS?

#146

Post by netfl0 »

thenewnewguy wrote: post #23
slacka wrote: post #19

Earlier quoted context omitted.

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.

I’d be a bit more precise. The blog is hosted by cloudflare. IPFS hosts all the versions of the blog, none of which are canonical.

Re: Why build this blog, or anything, on IPFS?

#147

Post by nullstyle »

lidel wrote: post #140
nullstyle wrote: post #120

Earlier quoted context omitted.

Hi! Thanks for taking the time to respond and correct my outdated info. Unfortunately, It seems your info is also outdated: I just installed 0.10.2 for Mac and it's by default using (600,900) for the low and high watermarks and routing type is set to dht rather than dhtclient. Since I've got you here, I'd be happy to give a little feedback: The constellation of websites for the protocol labs projects, their different…

> I just installed 0.10.2 for Mac and it's by default using (600,900) for the low and high watermarks and routing type is set to dht rather than dhtclient. (600,900) watermarks suggest you had an old config (ipfs-desktop will respect pre-existing config and won't override values). Just change watermarks manually to (50,300) and restart. If you run daemon via ipfs-desktop the routing preference from config file is ign…

Thanks for the heads up. I didn't realize I had left the old config in place.

Re: Why build this blog, or anything, on IPFS?

#148

Post by fiatjaf »

I once fell for this talk about "content-addressing".

You know what? Saying stuff is addressed by their content doesn't change the fact that the internet is "location-addressed" and you still have to know where peers that have the data you want are and connect to them.

And what is the solution for that? A DHT!

Turns out DHTs have terrible incentive structure and don't seem to be working well.

Downloading content on IPFS is the _most slow experience ever_ and for some reason I don't understand downloading is even slower. Even if you are in the same LAN of another machine that has the content you need it will still take hours to download some small file you would do in seconds with `scp`.

Now even if you know which peer has the content you want and tell IPFS to connect to it directly and the connection is established and the is being (slowly) downloaded... IPFS will drop the connection and the download will stop.

Re: Why build this blog, or anything, on IPFS?

#149

Post by fulldecent2 »

The long-term solution for web is:

- Use more static HTML - Since your assets are versioned and static, start calculating hashes for everything you publish - When you link to something, include the URL and the integrity ...

In the immediate future this will fix broken links. Things that are important will be cached and accessible via content addressing. In the long-term future this will fix other problems like linking to a page and then it being changed to something you don't endorse.

Re: Why build this blog, or anything, on IPFS?

#150

Post by kordlessagain »

kalmi10 wrote: post #35
kordlessagain wrote: post #31

Earlier quoted context omitted.

IPFS isn't designed for private communications. It's designed for highly decentralized publishing of content. Safe, in this context, means the data is safe to "be".

I understand that no one is going to tamper with the data. Everybody (who is running a full node) is gonna get what they ask for, but then they are gonna go and announce it to the world that they have it, and that worries me privacy-wise.

> that worries me privacy-wise

This should be addressed by the client, not the server. The server's function is to serve the data, not serve data and pretend it doesn't know who it gave it to.

Post reply on HN