Good call. I'll be needing one of them as well.

Can we see what it looks like?

When will the signature bounty be started.

Welcome to the vidz community i think you picked a good coin to invest in and i hope you upload a lot of good action movies.

I have some reservations about IPFS. It's a distributed file system run by volunteers, but few if any of them are intending to be the bandwidth backbone of a video streaming site. This will just get content from this site blacklisted as soon as it gains any traction. At least with bittorrent those seeding are intending to seed, and those watching provide support for the bandwidth of the torrent, so its a win-win. Moving to IPFS seems to make the site dependent on those running nodes without any benefit for them, which is unsustainable.

I also streamed an entire movie and I seem to be getting it all from one ip address. Seems like a single point of failure. Thoughts?

I think you've misunderstood. As we mentioned IPFS is intended to be another streaming method that we've introduced to the platform, content can now be added in the form of a WebTorrent magnet link or an IPFS hash. Secondly, one would have to go awfully far out of their way to blacklist content used entirely on our site specifically because there's no single point of origin. While someone yes might choose to blacklist our gateway, this wouldn't affect our services heavily.

We're not so brazen to think "lets use everyone else as a crutch." We'll be setting up several nodes to be used as IPFS gateways and heavily contribute towards open and public IPFS gateways. Our own nodes will bootstrap off one another and pin each others content, whatever it may be.

Again, I wouldn't word it as we've moved to IPFS but rather it's now another form of uploading content we support. I mentioned before, there's also a lot very cool things IPFS brings to the table like for example dumping our index to a json file regularly, hosting it on IPFS and creating a simple decentralized search index. It's brought a lot of potential to light.

The issue is that with IPFS being fairly new and not in widespread use, the data used by this site if it gained traction would stand out greatly. A node operator wouldn't have to blacklist the domain or the gateway, just the handful of hashes that were causing the huge amount of bandwidth. On the other hand, if you're running nodes that support the distribution of content for the site, then we're back to single points of failure. I watched a movie a little while ago and the whole thing came from one ip address. How does this set up "route around" legal threats?

Manually auditing all those hashes and adding them would really be going out of your way especially with no easy way at this point in time of determining which hashes are used by the site. The same argument you made can be made for any content being served through IPFS that's taking up a lot of bandwidth. It's not a single point of failure, we're running nodes to assist the IPFS network your argument makes the assumption the entire network complies to this mindset of "I haven no incentive to seed these files so let me go out of my way to blacklist them" which is literally the opposite of what IPFS stands for. There's a reason why for example ipfs.pics's gateway for example will still serve you non-image content if you request it... because that's what it's suppose to do.

It came from one IP address because it comes from the gateway server, the gateway server is the one that interacted with many other network nodes to assemble the file blocks. If you inspect the javascript on one of our pages right now we have statically added one IPFS gateway because while we could use other public nodes like ipfs.pics's we know that's not what the intend it to be used for and adhere out of courtesy. We'll be adding more nodes to this list and we'll be adding the functionality to set a preferential IPFS server in your user profile so rather than being served from one of ours, you can set your own.

You should check out the IPFS subreddit, the legalities of running a gateway has been discussed quite a bit on there.

Here here! Id like to see fox offered as a 24/7 live stream.

It's not something we've had to time to heavily look into so the current answer is no. I mentioned them because another user said he had a working test/example using MKV files so I asked him to forward me his test data/sample as it would speed things up on our end.

If you're wondering why MKV/non MP4 files are a headache it's because in HTML5 when videos became a standard to the browser, the standard was also that it needed to have a specific video encoding and specific audio encoding (h264 aac). For a long time before videos were natively supported in the browser Flash which is a browser plugin was used as a hack to circumvent this but it meant videos needed to be converted to FLV.