So most parts of it could at their core be used in a distributed fashion, but are actually accessed via CDNs. E.g. you could use ipfs-companion[0] to alter all instances of ipfs.io URLs to point to a local IPFS daemon that is connected to the IPFS network in a distributed fashion.
I did just that and streamed a video on DTube via a local IPFS daemon and the result was pretty underwhelming, since it took quite some time for the video to load, but I don't dare to evaluate why that is so. After that it does have the nice benefit though that the same video streams instantly on any other machine in my home network!
In a transitional phase to a distributed web I'd expect a lot of websites to employ a similar approach of using CDNs at first (since not everybode has local nodes running), but its sad to see that some of the flagship projects like DTube aren't even open source (and I have no idea if they ever plan to be) and/or have a distributed version available.
> I did just that and streamed a video on DTube via a local IPFS daemon and the result was pretty underwhelming, since it took quite some time for the video to load, but I don't dare to evaluate why that is so. After that it does have the nice benefit though that the same video streams instantly on any other machine in my home network!
Could be that you just started the IPFS node and it didn't really have any time yet to connect to a large enough number of peers.
But yeah, as you said, the benefit is that after the fetch from the internet backbone, the content now lives much closer for the next time.
No I don't think that was it. I had ~700 peers connected. I guess due to DTube using CDNs in front of IPFS most content is probably only available from very few actual nodes.
My guess would be that distributed internet will never work.
Sure for popular content like Google.com. or the top 1000 of YouTube will work. But the rest will always crawl to a stand still, since the content will always be on a far away or slow node...
I'm not sure if I follow. This is from Sia, so it might not be the case with IPFS + FileCoin, but the cost for finding a host is the same for everyone. The hosts themselves determine their own price, and they're given a rating determined by the amount of storage they have + uptime + bandwidth. Users can then choose who hosts their content by looking at their rating versus cost.
Currently, without monetization in place, popular content is easy to host while unpopular content is not. Monetization levels the playing field.
On IPFS popular content is cached, a website like youtube will most likely not have to pay hosting for any parts of it's website or popular videos if they were to run on IPFS.
Content that is not popular enough to remain in the IPFS caches will require filecoin or some other form of paid hosting to keep it around, thusly increased cost.
> How could Apple or Google or Amazon or Facebook make money by promoting a distributed internet?
Perhaps unprofitability is a feature, not a bug.
Individuals can choose to seed content they care about (given an effective UI), which means the content will be available as long as enough people care about it. “Enough” does need to be a sufficiently small number.
> In a transitional phase to a distributed web I'd expect a lot of websites to employ a similar approach of using CDNs at first (since not everybode has local nodes running)
I'd like to think so, but a more cynical take is that efforts like this to trade on 'distributed' will either (and most likely) fail or, if they do get traction, ditch the distributed backend once it's served its purpose as a selling-point to attract early adoption.
TBH, I'm not sure how big of a future video "platforms" will even have. With IPFS+Filecoin and a few other parts, it might become quite trivial to host your own video content. With that the focus could possibly shift to platforms like Patreon, and if the payment parts of that can be commoditized (via things like Stellar and SatoshiPay), maybe even back to the good old website. One can only dream...
This solution might make a lot of sense as a build-up process.
However, until DTube release a client so that the network can build, it's just a centralized video platform using IPFS and STEEM as storage backends. Unless clients are made available, it might as well use S3 and Postgres.
If it uses IPFS as a storage backend, then why is it faster to watch the video on the website then via IPFS as hobofan did? This seems to be an indication they store that data on a server all the time.
By default, when making requests to the HTTP gateway, it'll cache the content requested until a GC runs. So it's possible that the local node you're using, have not seen the content before so it needs to go out and fetch it while the gateway d.tube uses, already has the content fetched and only needs to serve it.
Of course, the second time you load the content (or if another node on your local network already loaded it) via a local node, it'll be much faster than the public gateway d.tube is running.
Disclaimer: I work for Protocol Labs specifically on IPFS.
So most parts of it could at their core be used in a distributed fashion, but are actually accessed via CDNs. E.g. you could use ipfs-companion[0] to alter all instances of ipfs.io URLs to point to a local IPFS daemon that is connected to the IPFS network in a distributed fashion.
I did just that and streamed a video on DTube via a local IPFS daemon and the result was pretty underwhelming, since it took quite some time for the video to load, but I don't dare to evaluate why that is so. After that it does have the nice benefit though that the same video streams instantly on any other machine in my home network!
In a transitional phase to a distributed web I'd expect a lot of websites to employ a similar approach of using CDNs at first (since not everybode has local nodes running), but its sad to see that some of the flagship projects like DTube aren't even open source (and I have no idea if they ever plan to be) and/or have a distributed version available.
[0]: https://github.com/ipfs-shipyard/ipfs-companion