Is there an IPFS based video site like Vimeo.com or invidio.us?
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.
1 Like
@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.
https://github.com/ipfs/go-ipfs/blob/master/docs/gateway.md
1 Like
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
js-ipfs - or connect to external IPFS node, usually with
go-ipfs.
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.
https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/node-types.md
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.
1 Like
There is a good analysis of IPFS gateway, written by pinata, which provide IPFS pinning service.
1 Like
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.
3 Likes
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
Regards
Suzanne
screenplay ghostwriter
Thanks for that cool recommendation! Pubswap looks good. 
Jason, has there been any improvement in the IPFS network concerning video streaming since you made the “not capable enough to provide stable video streaming…” comment?
Thanks,
1 Like
Hi, I made https://ipfs.video and it works using js-ipfs by filling the Javascript MediaSource API using the chunks from the ipfs network.
An example is 01_llama_drama_1080p.webm
This is not ideal yet, I think the async makes the buffering stutter a bit, so room for improvement. But it does work, feel free to try it out and check the source.
1 Like
I’ve been interested in how videos (and large images) can be better managed on IPFS, and this conversation has been going on for several years now. This thread is a few years old, and I wanted to link in my own comments that I posted over on the IPFS GitHub repository too: Create custom HTML5 video player for IPFS files · Issue #920 · ipfs/ipfs-webui · GitHub
That discussion I started on that issue is mainly focused on how the HTTP Gateway action could be improved to make native browser video (and other large file) viewing more effective. However, in the intervening years, we now have js-ipfs as an option, where it can more directly interact with the IPFS network as a node itself, which might give more flexibility for the specific use-case of a visitor wanting to load a large file?
So, bumping this conversation back up again to see if we now have the tools to make something like the mockup I created in that GitHub issue:
Namely, for a website interacting with an IPFS Gateway, or js-ipfs, if it is given a CID that is the root node of a large file, can it:
- Request just the first data blocks of the file as a first priority over the rest of the file (to get the “magic bytes” of the file, and for video formats that support it, be able to start playing the first few seconds of the video).
- Request larger chunks of the file that are further-ahead of where the visitor is currently viewing, and as they asynchronously come in, create a visual for the human visitor to see how much of the large file is now known and locally cached.
The ipfs.video site looks like some great steps in that direction (thanks @bneijt!). I only recently found out about that site/project, so dropping a line here to see if there’s any interest in bootstrapping further development of that idea.
2 Likes
Thank you for posting. I recently quit my job to go freelance and I’m going to make time to upgrade ipfs.video to the new js implementation. Biggest issue atm is trying to sync up the incoming byte arrays with the video buffer to keep the browser from loading the full video into memory. Hope that with upgrading I can make it work better OR maybe we can find a way to use my own decoder and a canvas using WASM if all the other options fail.
The source for ipfs.video is open, feel free to experiment and/or open issues there.
There is a large discussion in the Peertube community about using IPFS to help deliver videos:
Peertube is a Free Software, peer-to-peer, video platform: