in IPFS you can’t remove a content but you can unpin a ressources if all peer unpin a content the ressources is not up in your swarm. so you can use bot for check content of ressources and unpin a ressource if contents is “undesirable”.
Thanks Josselin. We’ve seen some discussion around the ability to choose what you share. Do you know if this has been implemented anywhere? This is VERY important for the studios.
Awesome thanks Josselin!
Will do. There’s a very high level architecture diagram here in slide 7 https://blusttvblog.blob.core.windows.net/website-media/2018/02/GT-Systems-Blust-entertainmen-09022018.pdf and a more detailed explanation in our white paper here https://blusttvblog.blob.core.windows.net/website-media/2018/02/GT-Systems-Blust-entertainmen-09022018.pdf
With IPFS every user sharing only the data that they choose to download beforehand. If your users are the Hollywood studios and those studios don’t download any porn they won’t store any porn either.
It’s similar to how a company that hosts linux distributions via bittorrent won’t store any porn on their PC either. At the same time, every user that actually downloads linux distributions from them is free to also download porn via bittorrent and that’s outside of the control of the company that hosts the linux distributions.
1 Like
Our customers are people who download the Blust app to watch movies. 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? It can’t be overridden? That would be perfect. Obviously users can download other IPFS apps but that’s out of our control. Long as we can prevent insertion of undesirable content in the file systems under our control.
i’m not sure but you can test locally to create to application which use IPFS in App A define a specific repo_path (ex ~/repo_app_a) and App b another repo_path (ex ~/repo_app_b) in IPFS network it can two speprate node so with two seperate DHT. After that imagine the app A is blust you can in this dht for example exlude all peers else your peers node and hollywood provider. i you add a ressource on app A et after you try to get that with http://ipfs.io/ipfs/<your_hash> (if your peers and hollywood reject all also) that not exist i guess but if you to do that on app B your hash is gettable by ipfs.io.
Regards
2 Likes
I don’t know how official it is, but several of Protocol Lab’s devs are mods at the filecoin subreddit: https://www.reddit.com/r/filecoin/. It’s the most official forum I’ve come across.
I don’t think that is correct. I’m not aware of any encryption for blocks at rest (i.e., in the IPFS repo). If data is encrypted using a proprietary product I don’t see why that would cause problems; IPFS should just store whatever you give it.
1 Like
That’s what we thought. If that is the case then it’s perfect.
I was trying to access the documents but you’re domain is being flagged by metacert -
Perhaps you should get in touch with the devs.
Thanks very much Dmitriy we just did some changes devs are investigating immediately.
What browser and o/s were you using please?
Can you access: http://blust.tv ok? The primary domain for the file that raised the Phising alert is windows.net (Azure blob storage default). What Metacert product were you using that tripped the alert?
I’m on macos high sierra and using chrome 64.0.3282.140 - this is the url that metacert redirects me to - https://block.metacert.com/?domain=https://blusttvblog.blob.core.windows.net/website-media/2018/02/GT-Systems-Blust-entertainmen-09022018.pdf&redirect=https%3A%2F%2Fdiscuss.ipfs.io%2Ft%2Fgt-systems-ipfs-and-filecoin-questions%2F2050%2F8
Yep, http://blust.tv works fine. I’m using this extension in chrome 64.0.3282.140 - https://chrome.google.com/webstore/detail/cryptonite-by-metacert/keghdcpemohlojlglbiegihkljkgnige?hl=en
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 
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.