This brings it back to a distributed communication problem. If you could distribute content more consistently and 100,000 computers could step in as dns providers with authentic data rather than concentrating dns at dyn or Google it would help. That will still require protocol updates so that the fail over uses local content. Really ipfs and distributed content could be a component to help with distribution. It definitely isn't a complete solution alone (yet -- there is a push to make it the solution).
The IPFS powered internet would perhaps lead to more uploads but it would scale significantly better and will be cheaper to maintain. Hence cost can also go down for end users/consumers.
... 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 person on the train.
This would only work as long as person A is running IPFS, connected to the hotspot and has any cached content somebody else is concurrently interested in. The hotspot is very unlikely to run IPFS and to have any storage, so cache hit ratios would not only be low they would be dependent on person A's transit schedule.
> This scenario would require significantly less bandwidth overall.
No, the same amount of bandwidth would be consumed, but perhaps over a cheaper radio bearer.
> The IPFS powered internet would perhaps lead to more uploads but it would scale significantly better and will be cheaper to maintain.
Somehow I doubt that. Total costs would most likely go up, but they would perhaps be more spread out.
> Hence cost can also go down for end users/consumers.
Consumers don't spend anything for accessing content on the Internet, so I really doubt there are any cost savings to be had.
It is, for now, indeed.
> Except you are not allowed to download videos from YouTube
I think youtube would be interested in some load balancing if they could keep the income from commercials. Wait, what, there wouldn't be a need for YouTube. We'd only need a way to pay content creators build into the system (Ethereum coupling somehow?? I'm not sure, can views be tracked in IPFS?).
> This scenario would require significantly less bandwidth overall.
The same amount of bits are pumped around but they have to cover significantly less physical distance and hubs. This reduces bandwidth.
> Somehow I doubt that. Total costs would most likely go up, but they would perhaps be more spread out.
Me pumping bits from my neighbor's house to mine instead of us both via the backbone from some server in a central location requires less (expensive) infrastructure between me and that central location.
> Consumers don't spend anything for accessing content on the Internet
indirectly they (we) pay for the copper and the fiber.
Firstly, it's not up to Google. Secondly, how would that even work?
> Wait, what, there wouldn't be a need for YouTube.
Yes, there would. YouTube isn't the solution to a technical problem.
> We'd only need a way to pay content creators build into the system
Why?
That's also a pretty big "only".
> The same amount of bits are pumped around but they have to cover significantly less physical distance and hubs. This reduces bandwidth
No, it doesn't. What it reduces is bitmiles. Which may or may not be significant. Mostly not, but it may have some significant if we can lower the usage of some scarce and expensive radio bearer.
> Me pumping bits from my neighbor's house to mine instead of us both via the backbone from some server in a central location requires less (expensive) infrastructure between me and that central location.
Not really. You are still going to need that infrastucture, so no cost savings.
> indirectly they (we) pay for the copper and the fiber.
So we do, but using IPFS isn't going to result in us getting a check in the mail. Costs are still zero and savings likewise.
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.
No, it is not. Not from a legal perspective, which is all that matters in this context. With seeding you are making things worse for yourself, as you are not merely downloading but also distributing. Seeding is also relevant with regards to downloading, as IPFS automatically starts seeding what you download.
Also, I have WiFi on always and my battery lasts all day, so I doubt this will be a problem.
No matter what incentive scheme you device , it's not going to help you with your battery.
Obviously with certain incentives, battery would become irrelevant. If this hypothetical "IPFS ratio" were as valuable as (for example) what.cd ratio, I'd have no problem carrying around car battery to continue seeding. Thankfully, I don't think it would be possible for my phone to consume that much power in a day.
Sure, cold hard cash would suffice, but imaginary Internet points won't do. But even with cash there comes a point where you would turn off IPFS, because the alternative would be to have a dead phone for the rest of the day.
> Thankfully, I don't think it would be possible for my phone to consume that much power in a day.
Perhaps not that much battery, but it is quite easy to deplete your battery in much less than a day by having your hotspot on constantly, which is what IPFS would require.
If you have anything to share at this point this is probably a good indication that both clients have some content in common. So first of all, transfers over WiFi while the phone is in use anyway are not that expensive, and more importantly there’s an opportunity to save a lot of battery, and data, that results in substantial net positive gain.
To illustrate imagine the likely scenario of two people using some form of Youtube with a distributed IPFS cache while on a plane. If those two people have anything in common—and certainly there are things like news etc. that are always in common, those can be shared instantly over the WiFi.
So for an insignificant battery investment, you can potentially save a lot of data and modem power in the long run.
Obviously content would be highly duplicated between peers, but you'd have access to a significant chunk of the "popular" internet, and would be able to avoid in-flight WiFi.
For such a mesh network, you don't even necessarily need to connect over WiFi - lower energy Bluetooth could be used too.
That feels optimistic. I doubt people have that much free space on their phones, especially those that don't have flash cards. Heck, a basic iPhone won't have. Even a 16GB model has something like only 12 GB free when it's empty.
> For such a mesh network, you don't even necessarily need to connect over WiFi - lower energy Bluetooth could be used too.
IPFS doesn't (currently) work over Bluetooth.
However, my main point is, that I don't think most people would be altruistic enough to participate unless they could plug in their phones on the plane.
Having run many a phone into the ground while hotspotting, I do not consider the battery investment insignificant. It's annoying enough when I drain my own battery when using the hotspot, I would never allow complete strangers to do that to me.
The network works even if people only seed during a download. Obviously, that’s less than ideal. For mobile, though, this is perfectly fine.
The point of IPFS is you can do an ‘airdrop’ without having to coordinate it. You lookup content by hash— If it’s available locally? Great! If not just get it from remote and add to cache. Simple as that.
That's a reasonable approach, but due to the synchronous requirement I guess the offload factor would be minimal. When I want to download something I might as well enable wifi and see if it's available locally. After I'm done there's really no incentive for me to keep seeding or even have wifi turned on.
> P2P networks like Bittorrent pride themselves on being available despite high churn, so this is right up their alley.
This really isn't applicable to opportunistic mobile use of IPFS, as you are unlikely to have a large enough local swarm to guarantee uptime or availability.
IPFS content is chunked, your swarm is lan+wan.
> That's a reasonable approach, but due to the synchronous requirement I guess the offload factor would be minimal.
A room full of people using their phones is what I have in mind. Remember, a node’s cache is not exclusive to just the content that’s being currently consumed. Anyway, the point was whatever’s the offload factor it would still be a net positive.
Also one can imagine if IPFS gets popular, just as ISPs collocate CDN caches in the present model, WiFi routers could come with a local node of their own. The “Web Accelerator.” And now we’re talking!
There’s opportunity for caching at many network levels, but there’s no incentive to do so with HTTP.
Yes, but for offload, all that matters is your local lan swarm.
> A room full of people using their phones is what I have in mind.
That might work to some extent, but how often do you (i) spend your time in rooms full of people and (ii) have no wifi.
> Anyway, the point was whatever’s the offload factor it would still be a net positive.
Not quite. If the offload factor is sufficiently small there is no rational reason to burn battery on it.
> Also one can imagine if IPFS gets popular, just as ISPs collocate CDN caches in the present model, WiFi routers could come with a local node of their own. The “Web Accelerator.” And now we’re talking!
Possible, but unlikely. Web cache hit ratios are abysmal, normally it's much cheaper to just up the bandwidth. A lot of business models would also have to change for the (large) and interesting content to become third party cacheable.
> There’s opportunity for caching at many network levels, but there’s no incentive to do so with HTTP.
There are also many business models where there is no incentive to cache either.
Sure, but there’s also no cost to it, if you go with the piggyback/opportunistic approach. That’s the point. It’s either net positive or just neutral. Whether the local offload is effective or not— that’s a different argument.
Anyway, the driving reason for my interest in IPFS is re-decentralization of the Web. If it can, theoretically, save some data on mobile—so much better.
What it needs, though, is simply work on mobile at least as well as HTTP. There’s no doubt IPFS has no fundamental architectural problems in that regard.
Though, full disclosure, it does have some major implementation issues at the moment.
Non-mobile devices start at $5. A considerable server is <$100. Even only modest amounts of server persistence allow for a powerful distributed net.
ipfs pin myhash
IPFS provides no anonymity, so it won't take long before DMCA notices to start arriving.
In the way that, if one node is forced to take down some information, that information may still be accessible from other nodes under the same address as before. It's not quite immunity: They can still harrass individuals. Call it "resilience", maybe.
> IPFS provides no anonymity, so it won't take long before DMCA notices to start arriving.
It should compose well with Tor, I'd hope.
Does IPFS work with Tor?
It is decidedly more resilient than regular hosting in that situation.
IPFS so only as resilient as you are good at dodging DMCA notices.
The equivalent is not practical in traditional HTTP, where content at risk of being taken down is scraped from the server and that snapshot-in-time is hosted as a mirror, generally at a different domain.
Which is also why a regular consumer should never use IPFS and why prosumer should immediately disable caching and seeding upon install.
> All it takes is a single user (or an arbitrary number) outside of US jurisdiction and the content is more or less DMCA-immune.
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.
Plus you'll still have to seed the original which opens you up to liability, as IPFS does not provide any kind of anonymity.
So, while better than traditional HTTP, IPFS isn't really immune to takedowns nor very resilient.
Unless they changed policy, seeding is strictly a manual, opt-in process.
>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.
I disagree, IPFS is a pretty reasonable plan for resiliency in the case of static web content, as previously discussed.
If instead of "kindness of strangers" you frame it as a "market with incentives" to maintain information availability it is both less condescending and more accurate to how situations are likely to play out with things like DMCA'd content.
>So, while better than traditional HTTP
(which is all it needs to be)
>IPFS isn't really immune to takedowns nor very resilient.
That wasn't the goalpost we originally set, nor one of the project's longterm objectives, so I'm not sure the relevance.
Pinning may be manual, but is not content automatically cached and seeded (until purged from the cache) once any content is retrieved?
> I disagree, IPFS is a pretty reasonable plan for resiliency in the case of static web content, as previously discussed.
How is it a reasonable plan to exploit the naive and the uninformed or to depend only on those that are outside your juridistiction and unassailable by their own?
> If instead of "kindness of strangers" you frame it as a "market with incentives" to maintain information availability it is both less condescending and more accurate to how situations are likely to play out with things like DMCA'd content.
What incentives exactly would those be?
I also find it interesting that you object to kindness from strangers.
>>So, while better than traditional HTTP
> (which is all it needs to be)
That might not be sufficient for IPFS to get enough adoption, tho.
>>IPFS isn't really immune to takedowns nor very resilient.
> That wasn't the goalpost we originally set, nor one of the project's longterm objectives, so I'm not sure the relevance.
Fair enough. It is however relevant in the sense that it both removes a use case and acts as a disincentive for users to participate, as there is no liability shielding.
Have you ever used Bittorent? It works great.
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.
...but that's the same as saying let's back the decentralized web with centralized resources erp.
Zeronet offers no anonymity, you have to use Tor for that.
I don't see how IPFS tackles the problems of guaranteed availability and enough redundancy while relying on volunteers to mirror and serve content.
Also, if you want to DDoS content, it sounds like all you need to do is find the IPs of the nodes that host the content you want to target (which might not be many, and I guess become visible to you once you access/download that content) and knock them out
Unless I missed something?
Good luck adding all DDOS bot IPs to your null route.
Or why the current model (SaaS with Javascript apps literally shipped to every browser) isn't distributed computation.
(The long digression on takedowns doesn't illuminate this at all either.)
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 to access your blog they may pull directly from my cached version, or from the original host (depending which is fastest). Merkle DAGs are used to hash content for quick locating, to ensure content is up-to-date, and to build a linked line of content over time.
This gets more interesting if there's a widespread service outage. IPFS nodes will continue to serve the most up-to-date version of the web even if the web is fragmented. As new information becomes available it is integrated into the existing cache and then propagated to the rest of the fragments.
I still struggle to understand how this works with databased content, but I do believe IPFS addresses this content.
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.
Check out https://github.com/ipfs/archives to learn more.
Sure, you can manually publish archives over IPFS, but that's not something that automatically creates an IPFS cache copy of whatever you are surfing.
Say I have a site that sells Awesome Products. L337Hacker mirrors my site, does a DDOS on the original and lets IPFS take over, redirecting the shopping cart to his own site.
Is this a potential scenario? If so, is there any way to prevent it?
First: publishing the catalog isn't the same as processing the shopping request. Online commerce is largely an update to catalog + mail-order shopping as it existed from ~1880 - 1990. If someone else wants to print and deliver your (PKI-authenticated, tamper-resistant) catalog, that's fine.
Second: The catalog isn't the transaction interface, it's the communications about product availability. The present e-commerce world is hugely hamstrung on numerous points, but one of these is the idea separating the catalog and product presentation itself from ordering. So long as you're controlling the order-request interface, you're good. A payment processing system which authorised payments via the bank rather than from the vendor would be helpful. Also a move away from account-info sharing.
The key is in knowing who the valid merchant is, and in establishing that the fraudulent merchant has misrepresented themselves as the valid merchant. Perhaps authentication within the payment system would help.
Taking the shopping cart's payment mechanism out of the shopping cart would help.
If content is created specifically for IPFS-caching (similar to Freenet or Onion), then it may be possible to be authoritative, but content cached from the web should never be considered so.
Not at all, rather the opposite, it's very easy to verify a page since the hash is based on the content.
You have file "ABC" that you want to download. So you fetch it and once you have it locally, you hash it yourself and you compare the hashes. If they are the same, you know you have the right thing. If they are different, someone is sending you bad content.
If the original page can perform the hash and embed it, that would somewhat alleviate the issue during the fetch, but do nothing to prove that the IPFS-served page was trustworthy or not, unless some third-party knows the original hash, as well.
If the page was served to the IPFS network, to be cached, by a neutral, trusted third-party, that would somewhat alleviate the problem, although there arises the problem of trust again.
The only way to minimize the trust issue is if the page originates from inside the IPFS network and is not a cached version of page originally served outside the network.
1) The web as a whole is decentralized, but any given web site is centralized by default. A webmaster can "push" a modification or deletion from a central server and have it trickle down through caches/proxies unless someone like archive.org makes a deliberate decision to archive it. In systems like IPFS, content deletion and modification follows a model more like garbage collection, where pointers to old data can hang around and continue working even if an "authoritative" pointer is pointing to something else. Basically, nobody has the authority to break a link (law/policy-mandated filters notwithstanding).
2) The web doesn't really have any built-in mechanisms to promote redundancy for durability, availability, or performance purposes. By default, there's one daemon serving one copy. Everything else (CDNs, forward/reverse proxies, failover) is some kind of optimization tacked on after-the-fact.
The idea is that we run that centralized search engine via Smart Contracts.
In other words, using a decentralized currency such as Bitcoin and decentralized execution environment like Ethereum, we create softwares which pays people for providing CPU time and disk space (facilitated by IPFS).
Few missing pieces of this puzzle are homomorphic encryption implemented on Smart Contracts level which will allow that CPU service.
Once that's done then we can have the distributed web of the next level.
Multiparty computation makes some security sacrifices (breaks if M out of N people cheat, breaks undetectably iirc), but I think the blowup is less than 10x for some operations and less than 1000x for the others.
Still not pretty, but at least makes certain things possible. But not competitive search engines.
If you're hosting content at a certain rate, then the rate drops so that it's less profitable or no longer profitable, wouldn't the proper strategy be to drop that content and then find something worth hosting?
Disclaimer: I have worked on building the Internet since before the web, and have a BOFH kind of point of view of things, 2 or 3 times over now ..
I support IPFS - and things like it - as a technologist/hacker/punk-ass because, in fact, we have built an utter monstrosity of a beast of a spaghetti god of an Internet, and we can always do better.
Software - and by extension, inter-networking - is like music. There will always be better ways to do it, beyond the horizon of what is current and now. Just because what we've got "basically works, even though its all broken", doesn't mean we can't 'fix whats broken'.
To those of us in the group of your postulate, whats broken is the fact that its all so damned hierarchical, and requires canonical/authority issue and agency in multiple forms before the bits can flow. We can't just set up an IP address - we also have to have DNS, serve content on it on some port, etc. And, on top of this, we end up having to sort it out all the way down the OSI stack, at the hardware layer, by keeping as many hosts as possible up and running as are required to service the customers, here and now, who are using our service.
All of that is what is broken about the current Internet, but of course the irony is that it is all that works about the Internet at the same time.
So, IPFS/distributed/etc. means this: we can un-bork all of the above, and just have all the things route down to the real, hard, user of the system, i.e. the original content provider. IPFS, and its ilk, is all about putting the original content provider in control, while also having the network - as a function of its operating capability - contribute to helping those content providers who become, eventually, popular.
So, we don't have a lot of rigid hierarchy - we have instead multi-variate spread spectra of responsibility/duty to serve up the bits of it all - packets at a time, as part of participation in the whole - to those who want something, and those who know how to find it, from those who have something, and know how to name it.
In short, "its not about the network any more, its the people..."