Live data from Hacker News

IPFS is the Distributed Web

ipfs.io

231–240 of 286 posts

Re: IPFS is the Distributed Web

#231

Earlier quoted context omitted.

> "Not everybody is clever enough to run their own stuff" It's possible to make home servers easy enough to use they're effectively plug and play. I've got my own ideas of how this can be done, others have different ideas, but the goal of easy home server infrastructure is the same. Once you have that, it becomes painless to take part in IPFS or similar.

I used to think that home servers could be the best solution, but I see more and more obstacles in the way of adoption. First, even if you can create a plug and play home server box, it will still need some configuration to make it available from the internet, which while very obvious to anyone a bit techie can be difficult to even explain in layman's terms. Secondly, it is not clear if there is an acceptable solutio…

> "First, even if you can create a plug and play home server box, it will still need some configuration to make it available from the internet"

Will it? The device I had in mind would plug directly into a router, occupying two LAN ports for connectivity, and one USB port for power (USB ports are increasingly common on routers these days, even the free ones ISPs give out). In addition, IPv6 removes the need for NAT and port forwarding. The device could even come with a default DNS name setup, so it could be literally plug and play.

> "Secondly, it is not clear if there is an acceptable solution to security issues."

You build the security into the device, e.g. firewalls and process isolation. You could also design the device so that flashing new firmware required a physical button on the device to be pressed to enable this feature for a short period of time, limiting the window of opportunity for the device to be infected with malware.

> "Auto updates could be part of the answer, but it seems that human intervention would still be needed from time to time and that imply an effort of the user to keep informed and aware of such operations."

Information about security updates could be done via email or SMS, which are both easy enough for mass market users. You would enter these details at the point of purchasing the device, so you'd have nothing extra to setup once you had it. If you had to update your contact details, this would be easy enough to set via the home server GUI.

Re: IPFS is the Distributed Web

#232
post #12

Earlier quoted context omitted.

Does that mean they are assigning random IPv6 addresses to computers on the network for each peer or connection and maintaining a mapping in memory?

Normal static address is assigned. Whether it comes from the external range or from the link-local range doesn't really matter. You could potentially randomise the source at the exit to prevent identification of your hosts, but you don't have to. For most practical cases just imagine you're getting a big ipv4 range. Whatever you can do with it - you can do the same with ipv6. NAT, no NAT, filtering, static or dynamic…

That's what I'm asking. IPv6 feels like a regressiin over NATv4 because it can leak which internal device made a request. Is there a standard way to randomize addresses that works with ofd-the-shelf router firmware. Also, are link-local IPv6 leaking MAC addresses?

Re: IPFS is the Distributed Web

#233
post #189

So I've got a (let's say) WordPress blog. Where's the "here's how to get your existing content on IPFS in less than an hour" guide?

I think it'd have to be saved statically. Which actually makes this question interesting: How do you store comments on an IPFS site? Constantly updating a single file on IPFS?

Interesting question. I know nothing about IPFS other than what I've read in the past five minutes on Wikipedia, but:

1. HTML wants badly for a nested relational document format. Essentially tin or mutt's "in reply to" and "references" headers.

2. A comments stream is a) a parent document to which b) multiple child documents, themselves possibly having c) parent-child relationships, d) are associated. Rather than thinking of "threaded discussion == single document" think "threaded discussion == a set of related documents".

That gives the option of having a discussion "occurring" across multiple sites, with some form of trust, whitelist, blacklist, or other mechanisms for reflecting what you do or don't include in the discussion. Individual comments, as their own docs, could also be freestanding instances.

Finding children from the parent becomes an interesting question.

There's also the matter of versioning a document. Tying a git-like capability to this could be interesting.

Re: IPFS is the Distributed Web

#235

Earlier quoted context omitted.

Well apart from battery, If I was an ISP, I´d like it if a Youtube movie would flow from one persons mobile to the hotspot of the train said person is sitting on and on towards another person on the train. This scenario would require significantly less bandwidth overall. Same goes for neighbors accessing the same information. And this can be extrapolated to many situations. The IPFS powered internet would perhaps lea…

> Well apart from battery, ... and that's pretty much the deal killer for this on mobile, even ignoring everything else. > If I was an ISP, I´d like it if a Youtube movie ... except you are not allowed to download videos from YouTube or most (if not all) the popular video content services. > a Youtube movie would flow from one persons mobile to the hotspot of the train said person is sitting on and on towards another…

> except you are not allowed to download videos from YouTube or most (if not all) the popular video content services.

If you're not allowed to download videos, then how come they show up on my screen? That information wasn't on my device before I pressed the play button.

Re: IPFS is the Distributed Web

#236

Earlier quoted context omitted.

Depends, I'm wondering if it could be cheaper energy wise if everybody was tapping into each other phones nearby instead of reaching for the cell tower.

No, because you don't want nearby people draining your battery by using your phone as a server.

By allowing your phone to be used as a server, other people will let you use their phones as a server, so you can download faster. If this sharing doesn't emerge naturally, then it can be directly incentivized with ratio tracking (like private torrent trackers), or even with money like the Karma WiFi service.

Also, I have WiFi on always and my battery lasts all day, so I doubt this will be a problem.

Re: IPFS is the Distributed Web

#237

Earlier quoted context omitted.

I am a novice, but I'll do my best to answer. IPFS isn't a replacement for the existing web like many of its predecessors, for the purposes of your question, it really works more like a drop-in shared caching system. The site host doesn't have to participate in IPFS for this to work. As an example: You host a blog. As an IPFS user, I surf to the blog and store your content in my cache. When another IPFS user attempts…

> The site host doesn't have to participate in IPFS for this to work. Really? An IPFS user will scrape HTTP content, republish it over IPFS and update a directory of where non-IPFS content can be found over IPFS? I must have missed that part.

Yeah - there's a ton of immutable URLs on the web. All of CDNJS/JSDelivr/Google Hosted Libraries, most of raw.github.com, all Imgur & Instagram images, all YouTube video streams (excluding annotations & subtitles), and all torrent file caching sites (like itorrents.org). There are probably some large ones I'm forgetting about, but just mapping immutable URLs to IPFS could probably cover 1/3rd of Internet traffic.

Check out https://github.com/ipfs/archives to learn more.

Re: IPFS is the Distributed Web

#238
post #164

Earlier quoted context omitted.

> Perhaps so, but if your plan for resiliency is based on the kindness of strangers in countries where the DMCA nor censorship does not apply, it's not much of a plan. Have you ever used Bittorent? It works great.

It works great only for a limited number of use cases. It's terrible for unpopular content, it is not immune to takedown notices nor is it very resilient in the face of a determined adversary.

Backing 'long tail' content with webseeds works well for Bittorrent.

...but that's the same as saying let's back the decentralized web with centralized resources erp.

Re: IPFS is the Distributed Web

#239

Earlier quoted context omitted.

No, because you don't want nearby people draining your battery by using your phone as a server.

By allowing your phone to be used as a server, other people will let you use their phones as a server, so you can download faster. If this sharing doesn't emerge naturally, then it can be directly incentivized with ratio tracking (like private torrent trackers), or even with money like the Karma WiFi service. Also, I have WiFi on always and my battery lasts all day, so I doubt this will be a problem.

Having wifi on all day is one thing, actually using it is totally different. Just activate your wifi hotspot on your phone and start using it from your computer. See how fast the battery depletes.

No matter what incentive scheme you device , it's not going to help you with your battery.

Re: IPFS is the Distributed Web

#240

Earlier quoted context omitted.

> Well apart from battery, ... and that's pretty much the deal killer for this on mobile, even ignoring everything else. > If I was an ISP, I´d like it if a Youtube movie ... except you are not allowed to download videos from YouTube or most (if not all) the popular video content services. > a Youtube movie would flow from one persons mobile to the hotspot of the train said person is sitting on and on towards another…

> except you are not allowed to download videos from YouTube or most (if not all) the popular video content services. If you're not allowed to download videos, then how come they show up on my screen? That information wasn't on my device before I pressed the play button.

Streaming is not downloading (and seeding).
Post reply on HN