Start with a description of the solution. If you can't cover it in 1-2 paragraphs at the beginning, you are in trouble. Don't focus so much on what everyone else is doing wrong - focus on what you are doing and let others be the judge of whether this is better.
HTTP is obsolete – it's time for the distributed, permanent web (2015)
281–290 of 337 posts
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#282Arweave seems to be another approach to the problem.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#283The problem is that it isn’t unique enough from the existing experience and the problems it claims to solve aren’t something non technical people care about. Web distribution in its current form works. Even if it’s supremely shitty grandma can still post photos on Facebook.
If a new distribution format wants to win it needs to be different in a way an 8 year old and grandma can equally understand. IPFS is not that. What 8 year olds and grandma equally understand is that content is king, the layman term for client/server model.
More likely the future will purely be a focus on web technologies for application experiences and distribution. Kill the client/server model. If grandma wants to share photos with grandkids she doesn’t need Facebook at all. She only needs a network, a silent distribution/security model, and the right application interface. No server, no cloud, no third party required.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#284Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#285Earlier quoted context omitted.
It does only the first of those things: using content hashes means that anyone can populate an archive which is easily discovered. For the rest, hosting takes money. People will not archive the entire internet for free and IPFS is not a magic wand which eliminates the need to have people like the skilled IA team. It could make their jobs easier but that’s far from “nearly complete” and no more or less pristine.
It gives you the tools to build an archive.org equivalent using volunteer storage though, rather Than asking for monetary donations. All you need is a database of known content hashes and a database of volunteers and you randomly distribute content among volunteers and periodically ensure a minimum number of clients are replicating each known hash.
Volunteer capacity at the scale of many petabytes of online storage is unproven and the long tail of accesses is enough that you're going to have to think not just about the high replication factor needed but also the bandwidth available to serve that content on a timely manner and rebuild a missing replica before another fails.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#286Earlier quoted context omitted.
log(size of the network) still means it gets slower as it gets larger without any aforementioned speed advantages for all but the IPFS Google popularity equivalent class content.
You seem to underestimate how slowly logarithms grow.
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#287Earlier quoted context omitted.
Sounds like it's working fine for you. "Several seconds" of lag is nothing for an "Inter-Planetary File System", in fact it's on par with other decentralised P2P networks.
Skynet fetches files in under 100ms, you can definitely get a decentralized system going as fast as the centralized web if you build it right. The main challenge for me with this comment is that you can't expect distributed/decentralized networks to win if you set an expectation that "things will just be slower than the normal web". Nobody is going to migrate to that.
I don't know Skynet. I first checked Google, got a Wikipedia link describing a movie, then checked the Wikipedia disambiguation page, but got nothing.
https://en.wikipedia.org/wiki/Skynet
Also, why would a project duplicate the efforts of IPFS rather than contribute to it?
Re: HTTP is obsolete – it's time for the distributed, permanent web (2015)
#288Earlier quoted context omitted.
I'll do a Show HN in a month. Although a reference implementation ( https://github.com/webpods-org/podmaster ) is kind of ready, there's no documentation yet (which will go up on webpods.org soon). The only way to see the feature-set is to look at some of the tests. https://github.com/webpods-org/podmaster/blob/master/src/tes... If you're interested, please email me. I'm looking for collaborators.
I tried to use Solid, but having a protocol to store your data did not seem very useful without being able to swap the applications that use them at will. Each application needs to understand not only the Solid protocol, but the format you are using for your data too. The specification naively says that the data is saved in interoperable formats. Sure, you can store your data in an interoperable data formats, suppose…
I don't think we'll be able to avoid that hurdle; we'll need to make sure that the protocol is really simple.
But having to know the data format of the app itself is to be expected. If an app "instagram-on-solid" stores data in a certain way, the alternate app will need to understand those schemas as well to be compatible. That's how interop has always worked, even in the pre-internet age when we were exchanging files on disk.
> It's been a while, have the applications improved?
I haven't looked at apps in a while - but that was indeed moving very slowly.