5 ms·
You can already fit all the Netflix movies into a space much smaller than a phone: http://memkite.com/blog/2014/04/01/technical-feasibility-of-building-hitchike
by Houshalter 11y ago
You can already fit all the Netflix movies into a space much smaller than a phone: http://memkite.com/blog/2014/04/01/technical-feasibility-of-building-hitchikers-guide-to-the-galaxy-i-e-offline-web-search-part-i/ http://memkite.com/blog/2014/04/01/technical-feasibility-of-...
It's only 5-24 terrabytes. That's not including tv shows, which would make it much bigger. But even those would still be small enough to fit it in a small box.
- toomuchtodo 11y agoI think the content addressable web is going to help the web bloom in places it's not currently accessible. Take something like the Netflix open connect appliance, preload with a couple hundred TB, plug it in and have it start announcing content in locations with poor network connectivity. EDIT: Thinking about this more, it becomes almost like S3 for all web content. Each piece of content can be addressed with its SHA hash, disparate nodes can increase the number of replicas based on demand, etc. IPFS, I'm pulling even harder for you now!
- digi_owl 11y agoDon't torrents pretty much offer that already?
- toomuchtodo 11y agoThey get us mostly there. The rest of the way is how you combine getting that data into a browser. Subresource Integrity [1] includes the hash of the content/object in the link to the resource, as well as the URL/URI; this lets you do fun things like not fetch duplicate content if its already in the browser's cache from another site (think a specific version of jquery, for example). Magnet links [2] are a great example of this in practice, but that's bittorrent-specific (although I would not be surprised if you started to see ideas from Magnet URI scheme work their way into Subresource Integrity): "The Magnet URI scheme is a de facto standard defining a uniform resource identifier (URI) scheme for Magnet links, which mainly refer to resources available for download via peer-to-peer networks. Such a link typically identifies a file not by location, but by content—more precisely, by the content's cryptographic hash value. Since it specifies a file based on content or metadata, rather than by location, a Magnet link can be considered a kind of Uniform Resource Name, rather than the more common Uniform Resource Locators. Although it could be used for other applications, it is particularly useful in a peer-to-peer context, because it allows resources to be referred to without the need for a continuously available host." Github has a great explanation as well: http://githubengineering.com/subresource-integrity/ http://githubengineering.com/subresource-integrity/ [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/ [2] https://en.wikipedia.org/wiki/Magnet_URI_scheme https://en.wikipedia.org/wiki/Magnet_URI_scheme
- digi_owl 11y agoSo something like rather than putting a URL inside a img tag, one could perhaps put a magnet URI, and wait while the browser trawled supported P2P services for said image? On that note, there as an article posted here on HN a while ago about Gopher. And at that point i found myself wondering if Gopher could have been modified or extended to handle such a scheme.
- toomuchtodo 11y ago> So something like rather than putting a URL inside a img tag, one could perhaps put a magnet URI, and wait while the browser trawled supported P2P services for said image? Exactly, although your browser would probably want to make an attempt at the URL specified before falling back to P2P/DHT if the server or URL wasn't available (you'd want to get objects like CSS, JS, or images FAST but other objects could probably lazy load in the background). The Magnet URI scheme already supports this behavior. > On that note, there as an article posted here on HN a while ago about Gopher. And at that point i found myself wondering if Gopher could have been modified or extended to handle such a scheme. "Everything old is new again."
- digi_owl 11y ago> "Everything old is new again." Heh, that line pass through my mind every time i see a Slack headline...
- nitrogen 11y agoHow does SRI prevent other sites from using a hash of third party content to load JS they shouldn't load, or sniff browser history by specifying hashed unique to a site and measuring load times?
- toomuchtodo 11y agoIt doesn't. Methods would have to be designed to prevent this. I don't believe its insurmountable though.
- nickpsecurity 11y agoThere's theory and practice. Theory: you can fit Netflix on a phone. Practice: you can't by far. That's unlikely to change unless you own EDA companies, memory fabs, content industry, and whole supply chains. Your link must be a pitch for a company's offerings instead of anything remotely like your claim. Good luck on that, though, as it sounds interesting. ;)
- digi_owl 11y agoThat brings to mind an anecdote i ran into in relation to copyright. Apparently a startup was attempting to offer a cloud PVR service, but then ran into the MPAA. Before the encounter the company was planning to use de-duplication to keep storage expenses down. But that was nixed by the MPAA lawyers. They insisted that each customer had his own, encrypted, storage area. Anything else would be considered a broadcast service, requiring a very expensive license agreement. At that point i think the company founders basically threw they arms up in exasperation and shut the company down.
- rahimnathwani 11y agoI think you're talking about Aereo. The story was longer and more complicated than that. They put up a decent fight, and bowed out. But this isn't the end of the matter for cloud-based 'cable operators': http://www.reuters.com/article/2015/07/17/us-filmon-copyright-ruling-idUSKCN0PR02620150717 http://www.reuters.com/article/2015/07/17/us-filmon-copyrigh...
- digi_owl 11y agoAs best i recall, it came up in relation to news about that. But it was not about Aereo directly. It seemed to have been a company getting ready to offer their service, and wanted to clear things with the MPAA (or the MPAA lawyers showed up unannounced). Only to find it impossible to both hit their planned price level and meet MPAA storage management demands. This because the MPAA demands basically meant they had to massively inflate their storage capacity, and thus the hardware cost pr customer made them uncompetitive with existing PVR products.