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

Decentralized Web Primer

gitbook.com

Post reply on HN
Print view View original

71–80 of 97 posts

Re: Decentralized Web Primer

#71

Post by exyi »

harperlee wrote: post #68

Decentralization is frequently sold as a means against censorship: if we use a decentralized system such as IPFS, we don't need to have a DNS hierarchy to serve content, so it is no longer viable to block a particular domain. But as long as we have ISPs and a common communications architecture, if we start using a content-addressable system, doesn't that help censorship? As a censor, I jump from having to censor all…

I think that IPFS is a mesh network, node-to-node communication is encrypted, so ISP can't ban certain blocks.

Re: Decentralized Web Primer

#72

Post by Asdfbla »

harperlee wrote: post #68

Decentralization is frequently sold as a means against censorship: if we use a decentralized system such as IPFS, we don't need to have a DNS hierarchy to serve content, so it is no longer viable to block a particular domain. But as long as we have ISPs and a common communications architecture, if we start using a content-addressable system, doesn't that help censorship? As a censor, I jump from having to censor all…

I think by default IPFS also doesn't even replicate content. So you don't even have to block hash lookups in the whole network but just take down the one host that currently has the only replica.

Re: Decentralized Web Primer

#73

Post by fiatjaf »

Asdfbla wrote: post #72
harperlee wrote: post #68

Decentralization is frequently sold as a means against censorship: if we use a decentralized system such as IPFS, we don't need to have a DNS hierarchy to serve content, so it is no longer viable to block a particular domain. But as long as we have ISPs and a common communications architecture, if we start using a content-addressable system, doesn't that help censorship? As a censor, I jump from having to censor all…

I think by default IPFS also doesn't even replicate content. So you don't even have to block hash lookups in the whole network but just take down the one host that currently has the only replica.

By default IPFS replicates content. That's it's main feature.

Re: Decentralized Web Primer

#74

Post by fiatjaf »

harperlee wrote: post #68

Decentralization is frequently sold as a means against censorship: if we use a decentralized system such as IPFS, we don't need to have a DNS hierarchy to serve content, so it is no longer viable to block a particular domain. But as long as we have ISPs and a common communications architecture, if we start using a content-addressable system, doesn't that help censorship? As a censor, I jump from having to censor all…

The canonical way of getting content on IPFS isn't through some HTTP gateway, but by running a node yourself. In that case there's no way for an ISP to block anything.

Re: Decentralized Web Primer

#75

Post by Asdfbla »

fiatjaf wrote: post #73
Asdfbla wrote: post #72

Earlier quoted context omitted.

I think by default IPFS also doesn't even replicate content. So you don't even have to block hash lookups in the whole network but just take down the one host that currently has the only replica.

By default IPFS replicates content. That's it's main feature.

Pretty sure it used to be that you have to deliberately pin content that you want to share on your node. Else nodes that accessed it will throw it out of their cache if they don't need it anymore.

Maybe they changed the behavior in the meantime though, but IPFS didn't permanently replicate uploaded content in the past without some deliberate user action.

Re: Decentralized Web Primer

#76

Post by lioeters »

Jommi wrote: post #67

Here's a pretty cool talk on the subject as well by Andre Staltz. It's nothing groundbreaking, but just simple facts he puts on the table to show what the current situation is. Highly recommend. https://youtu.be/qZDJ1z0apVk?t=7786 Disclaimer: I helped organize the event where this talk is from.

Thanks for sharing this talk - it inspired me to study and get into these new developments more; now I'm ready to read in depth the book Decentralized Web Primer.

Re: Decentralized Web Primer

#77

Post by fiatjaf »

Asdfbla wrote: post #75
fiatjaf wrote: post #73

Earlier quoted context omitted.

By default IPFS replicates content. That's it's main feature.

Pretty sure it used to be that you have to deliberately pin content that you want to share on your node. Else nodes that accessed it will throw it out of their cache if they don't need it anymore. Maybe they changed the behavior in the meantime though, but IPFS didn't permanently replicate uploaded content in the past without some deliberate user action.

Yes, you have to pin to keep it, but you download it and begin serving it automatically every time you load something. You can continue serving that for a while after -- specially if you're not downloading many other things after.

Re: Decentralized Web Primer

#78

Post by bababooey »

The biggest advantage of centralization is the ability to delete something from the normie web and have it deleted.

Granted, nowadays you have things like the internet archive, but I don't see normal people going along with IPFS for dynamic content like social media as long as you cannot delete things.

Re: Decentralized Web Primer

#79

Post by WJW »

loup-vaillant wrote: post #66
jkarneges wrote: post #43

Earlier quoted context omitted.

> This is why we need YouTube to begin with, instead of millions of people posting their videos on their personal page. People can post videos to their own hosted pages already. We "need" YouTube because 1) people generally don't want to host anything, and 2) it provides connectedness (search, related videos, subscribers, etc). P2P makes the first issue worse. The second issue is a problem of data federation, not cli…

> People can post videos to their own hosted pages already. No they cannot. Here's an example: what if make a nice tutorial, put it on my web site and submit it here and r/programming? If the thing is well done, people will download the video, and the sheer amount of requests may be enough to render my site unresponsive, simply because I don't have the bandwidth. So If I ever make a video, there's a good chance I hos…

You can easily get more bandwidth though, it's not that it is somehow forbidden. You just don't want to pay for it. That is what youtube gives you: 'unlimited' video hosting bandwidth (and improved discoverability) in return for the opportunity to play their ads before your video. The bandwidth costs also don't magically disappear with IPFS, it is just a convenient way to make other people pay for it.

In order of increasing independence you could choose to: - Host it on youtube, with the benefits and disadvantages you already mentioned. - Host it on a public S3 bucket and link to it from a HTML5 video player on your web page. You pay for only the storage and bandwidth used. - Keep the video on your own server, but pay a CDN to cache it for you. Actual bandwidth use of you server is now very low again. - Host it on a (big) server in a colocation center. You would typically buy bandwidth in advance though, so you want to be able to roughly predict how much you need. - Contract with a fiber laying company to lay a dedicated fiber line from the nearest backbone to your home. (Alternatively, a large microwave connection) Buy several 100Gbit NICS to go with it and negotiate peering agreements with the major networks.

Most people don't want the hassle and cost of the latter options, but they are very possible and very legal. In your example with the programming video, if a ton of people want to see it then somewhere along the chain a lot of bandwidth is going to be used and it is _not_ free. All you do is shift who pays for it.

Re: Decentralized Web Primer

#80

Post by WJW »

loup-vaillant wrote: post #65
fiatjaf wrote: post #56

Earlier quoted context omitted.

Relying on others is fine, the problem is when someone relies on you. Please see my answer to the other comment.

> the problem is when someone relies on you I'm not sure what you're getting at. The problem is only magnified with the web: there's only one seed. If a site is down, it's down , and you can only hope Google cache or the web archive got a copy. That problem is never worse with P2P protocols.

That is only valid when all nodes have an equal chance of being down. Big websites have entire teams dedicated to keeping their site online, so even though it's centralized, youtube is actually a very stable website. A torrent with one seeding peer (or an IPFS object where only one node has it pinned) can potentially disappear if a single machine has a disk failure.
Post reply on HN