D.tube I think it is called is IPFS based, but I am not sure if it has a strong connection.
Currently, when we use D.tube, we connect to the IPFS gateway. There is no difference with normal centralized sites.
But may be in the future, it can let users, which running local IPFS nodes, connect to IPFS network directly to watch video, rather than through IPFS gateway, although need to struggle with unstableness of IPFS network.
@jasonzhouu thanks! Is the IPFS Gateway a place we can browse IPFS?
Where is it? IPFS-Desktop has a GUI, but it is difficult to visualize what is on IPFS. One only sees hashes as far as I can tell.
It’s a bridge between IPFS network and Internet Browser, running on a remote server.
An IPFS Gateway acts as a bridge between traditional web browsers and IPFS. Through the gateway, users can browse files and websites stored in IPFS as if they were stored in a traditional web server.
So would that be something like IPFS-Companion, the browser extension? (Which I find makes all pages load much more slowly.)
No, IPFS-companion let you connect IPFS network directly, rather than through IPFS gateway.
Yes, IPFS gateway and IPFS companion both let users connect to IPFS network through web browser conveniently.
IPFS companion connect to IPFS network by:
- creates a IPFS node embedded in web browser with
- or connect to external IPFS node, usually with
External node can be any instance of IPFS daemon that runs outside of web browser process and exposes Gateway and writable API over HTTP at TCP ports.
Embedded node is a js-ipfs instance running in browser (in-memory), without need for any external software.
I think it’s because the IPFS nodes behind IPFS gateway caches tons of data, which makes it faster than your own IPFS nodes created with IPFS-companion.
There is a good analysis of IPFS gateway, written by pinata, which provide IPFS pinning service.
Thank you, I think I am getting a better understanding now. I might even be able to explain it to somebody else, if I get a few more points.
So, a good way to understand this “node” is to just imagine myself being on Mars, and as I am there, it is best that I have my data there, too. So, my node is a cache of data, that I may or may not need, and that other Martians might want too.
When I navigate to a web page, IPFS-Companion grabs as much data from that page as possible (something like pursuing all the links that page has and grabbing the content from those links too) and it brings that back to my Martian node. It might take longer for me to browse that page on the first occasion, but later on, if I revisit it, or follow one of those links, that data will already be local, held in my node. And Martians will be able to receive those pages rapidly from my Node now too, as that page is now available from my Martian Node, as well as slowly from Earth.
Is that right?
Thanks for that link. I shall see if that helps explain it.
Check out pubswap.com.
We have been using the IPFS network since inception and support both gateway streaming as well as direct IPFS network connectivity in the browser. As mentioned by others, the direct IPFS network connectivity is unstable at best and not ready for production usage. I am hoping the js-ipfs team will switch their focus to where I believe their value lies, connecting browsers directly to the network. Not in competing with go-ipfs.
I just tried D.tube with https://github.com/ipfs-shipyard/ipfs-companion set to redirect to local gateway. If you open Network analyzer (OPT-CMD-E on Firefox) you can see the browser at least try to get a few page assets via 127.0.0.1. As for the various dtube subdomains, I can see that some of the requests are IPFS CIDs, but I don’t think any of them are downloading via localhost.
Yes, I think it’s reasonable, as IPFS network is not capable enough to provide stable video streaming.
this is the two video site