GT Systems IPFS and Filecoin questions

We’ve posted a ticket to metacert but looks like it may be a “false alarm”. Cryptonite only verifies crypto sites. We’re not a crypto site yet. From their product description in the Chrome web store “This extension does not provide a green shield for non-Crypto sites like Twitter and Github. By only verifying Crypto sites, we help people stay more vigilant when buying and selling Cryptocurrencies.”

It seemed weird that it got flagged - I hope it gets resolved quickly. Lots of people (at least in this communities) are beginning to relay on similar tools, so avoiding false positives is going to become more and more important.

Agreed. But the tools need to get better and do a bit more work on it too. Thanks for the heads up.

Hollywood supplies us with those movies and they set the terms. So if we control the app and IPFS and the user just chooses how much they share, we can prevent other content being shared on the IPFS associated with the Blust app?

Technically Hollywood doesn’t set the terms – each buyer’s local copyright and commerce law sets the terms of sale. In the U.S. this includes First Amendment, Fair Use, Security Research, and First Sale Doctrine exemptions for starters. Also nobody really controls what IPFS does on their node except the node owner (which is really also the case with DRM keys despite Hollywood’s wishful thinking, but I digress). That said, if you use a smart contract and Filecoin to incent DRM-encrypted block distribution, then you could probably devise a method of making a specified blacklist subscription and local-node enforcement a core requirement of those contract terms. Content addressing makes it easy to create a blacklist of the known hash-ID’s of files and blocks matching your undesired “pirate” or “malware” content list.

There’s obviously no way to blacklist or otherwise control hash-ID’s you don’t have prior knowledge about, and you can’t really force any nodes to spy on themselves to insure “compliance”. Sony tried that with a CD injected rootkit once, and that didn’t work out very well for them.

1 Like

Don’t know the US rules yet but in Australia it’s the same. Overarching consumer and Intellectual Property law and regulation sets the framework. But our supply contract with the studios sets the fundamental commercial, security and other terms that we can offer and sell content at. This is why we have been working with the studios for 10 years. It takes a LONG time for them to become comfortable that we can use a technology that is destroying their business for good. And we have done that. In the words of the digital VP for one of the big 5 “Rhett, the peer word makes us nervous but we’re coming with you”. We have been working “inside the Hollywood tent” for 10 years on using p2p. They know us and trust us.

That’s where we need to get some clarity. Rightly or wrongly, we know for a fact that some of the more conservative tech guys in Hollywood are very concerned about “bad stuff” sitting alongside their “good stuff”. We think there are solutions to this. We’re looking at ways to do it now. Appreciate the smart contract/coin inventive suggestion that fits very well with our strategy and architecture. We will try to avoid black/white lists at all costs they are a serious pain to track and enforce. We think we can do it without that.

Not necessarily :wink:

Totally agree. We are all about full and open disclosure of what we are doing. Have been from day one. Akamai tried p2p a while back too without disclosing. That didn’t end too well for them either. We’re about building the movie service that everyone REALLY wants. Including latest possible AAA releases (we’re working on earlier release dates too), great indies and back cat; super premium quality and legal movie sharing. As opposed to what we’ve got. The ONLY way we’re going to get that done is by working WITH the community.