211–220 of 286 posts
If you do anything that needs a central server, suddenly its advantages vanish. I could imagine Wikipedia using this; I couldn't imagine gmail doing so.
Earlier quoted context omitted.
> Well apart from battery, ... and that's pretty much the deal killer for this on mobile, even ignoring everything else. > If I was an ISP, I´d like it if a Youtube movie ... except you are not allowed to download videos from YouTube or most (if not all) the popular video content services. > a Youtube movie would flow from one persons mobile to the hotspot of the train said person is sitting on and on towards another…
Depends, I'm wondering if it could be cheaper energy wise if everybody was tapping into each other phones nearby instead of reaching for the cell tower.
This sounds like distributed Geocities, where you can have any content you like so long as it's static, or at least, changes in iterations of static files like a HTML-generator blog. If you do anything that needs a central server, suddenly its advantages vanish. I could imagine Wikipedia using this; I couldn't imagine gmail doing so.
We keep things that are important, and throw away the garbage. But if we keep everything, there will be mostly garbage.
We can think differently with ipfs. Traditional web allows everyone to publish content somewhere, hoping that search engines will index it.
With ipfs, the same file (with the same content) is only indexed/stored once and then you reference the hash to get to the content.
This fact changes the problem of search.
Take all the world's movies. With ipfs + p2p network, you only need one back end in the form of a distributed search index, which can index all the movies in the world.
Same with the world's music. You only need one back end which can index all the music.
The index can be as simple as {"movie title": [sha256]}, where the array contains the hashes of different 'encodings' of the same content (eg. 'dvd rip', 'blue ray' or 'mp3').
Content can be indexed by all kinds of properties of course and it can grow organically over time to include more and more details.
With ipfs plus the p2p network we'll build 'apps', not 'pages'. People can have a list of 'apps' running on their machines - which are node instances in various distributed applications, sharing the same p2p network and using ipfs as storage.
Apps can have 'backend' and 'front end' parts - the back end is the part which participates in the p2p network, while the 'front end' provides a human interface to the back end, were users can search/browse/view the content.
Apps are distributed as git repositories stored in ipfs, while the 'core' running on the user's machine compiles the sources (inside a build vm) and loads the resulting binaries into containers running in virtual machines.
This would make it easy for devs to write and publish new distributed apps, making the network totally decentralised and virtually unstoppable.
Ps. If you feel that this insanity could work, then I'd love to discuss it in more depth - delegate78@gmx.com
This sounds like distributed Geocities, where you can have any content you like so long as it's static, or at least, changes in iterations of static files like a HTML-generator blog. If you do anything that needs a central server, suddenly its advantages vanish. I could imagine Wikipedia using this; I couldn't imagine gmail doing so.
Most of the pages on the Web are still static HTML or something close to it, though.
Earlier quoted context omitted.
Most of the pages on the Web are still static HTML or something close to it, though.
Maybe but very few of them can do their job with only static HTML.