HTTP is obsolete. It's time for the Distributed Web (2015) • Hacker News Board

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#161

Post by blurbleblurble » Sun, Oct 01, 2017, 5:02 PM UTC

adamsea wrote: post #135

blurbleblurble wrote: post #102

Earlier quoted context omitted.

I don't literally mean a Raspberry Pi. Raspberry Pi is the Apple 2 of what I'm imagining. I'm talking about some next generation stuff, picture a Firestick with a much more refined iteration of sandstorm, with distributed apps that have hardly even been conceived of right today in 2017. If my roommate can plug a Roku into the TV, and knows how to use Ableton Live and Squarespace, there's absolutely no reason he could…

Extrapolating the needs of business owners from your roommates behavior sounds like a winner ;-)

My roommates are all self employed musicians/artists, dependent on cloud services. So yeah I'm thinking about their business needs!

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#162

Post by blurbleblurble » Sun, Oct 01, 2017, 5:14 PM UTC

vog wrote: post #119

carolc wrote: post #101

Earlier quoted context omitted.

Agreed that many CRMs etc. don't have a lot of data. And that's actually good, it makes the database size very manageable in the context of trustless, distributed networks. I'm not following the logic of the argument here though, jumping from "X is good for Y" to "...don't actually have huge amount of data", perhaps you can elaborate? With a merkelized append-only log (immutable DAG), there's always an audit trail. I…

Here's my complete line of reasoning: You can build mutable systems on top of immutable (append-only) systems. But is that a good idea? Yes, it is, for systems which don't have huge amounts of (non-static) data, and/or system which need an audit-trail anyway. And these are more systems than one may initially think.

I think git is a great example of bridging the mutable/immutable gap. The "mutable" stuff happens locally in the ram, or on a local filesystem, as someone edits their files, debugs, whatever. A commit represents a save checkpoint. Somebody has decided that this state is worth snapshotting, that it would be a useful reference down the line. At this point an immutable version is made, ready to be shared.

As with git, even if a version (commit) is immutable, it doesn't mean it's worth saving. Lots of times, you might make a temporary branch locally to do some work. Then you'll merge it and push the merged version upstream. Later you might check out a new copy from upstream, not caring that your temporary working branch isn't there.

User friendly versioning is a major challenge for dynamic, distributed applications. How do we gracefully bridge the gap between long term (distributed) memory and short term (local) memory? Each specific application has its own needs and tradeoffs.

And how do applications communicate about which versions are compatible with the applications' needs? About which versions are worth holding onto?

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#163

Post by matchagaucho » Sun, Oct 01, 2017, 5:15 PM UTC

blurbleblurble wrote: post #74

I need to comment because people are missing the point... there's nothing in this text that says the web won't need servers. Imagine that you and some friends want to launch a small local business and need to host a website. Instead of paying to host it "up in the cloud", why not plug a few raspberry pi's into the walls at each of your houses? Between that and also seeding it from your laptops, the site should have d…

The "problem" in this article's premise is coupling links with physical servers, for which DNS and CDNs have solved.

Distributed computing certainly has it's role, but the added complexity of cache invalidation, versioning, and content synchronization are undeniable.

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#164

Post by matchagaucho » Sun, Oct 01, 2017, 5:19 PM UTC

__s wrote: post #27

jlrbuellv wrote: post #18

It's kind of funny that the example link to a "permanent" object still returns a 404 ("ipfs resolve -r /ipns/QmTodvhq9CUS9hH8rirt4YmihxJKZ5tYez8PtDmpWrVMKP: Could not resolve name.") I totally want the web to magically be distributed too, but clearly not even the author is bothering to host their IPFS content anymore...

> IPNS isn’t done yet, so if that link doesn’t work, don’t fret. Just know that I will be able to change what that pubkeyhash points to, but the pubkeyhash will always remain the same. When it’s done, it will solve the site updating problem.

DNS does that too?

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#165

Post by brownbat » Sun, Oct 01, 2017, 5:19 PM UTC

shade23 wrote: post #158

How does ipfs deal with dynamic content? And how would you make sure that everyone uses an updated version of the website.

I was worried about that too.

Scheduled republication is my best answer so far.

If you promised to sign and republish the same file every day with a new timestamp, then people would know when they had the latest, and when they didn't... would just have to wonder if you fell off the earth, which we sort of do already with all those abandoned free software projects online.

Republication may be cost prohibitive for large files, so instead you could republish a metadata file that pointed to the latest hash as of the metadata file's publication time.

For the "hit by a bus" problem (or for a server doing this automatically, the "hit by a comet" problem?), it'd be nice to include a dead man's switch from a third party, where they can publish a "FINAL -- EXPECT NO MORE UPDATES"...

But that that point you're trusting a third party. If you're willing to trust a third party this is far easier. So that might be what we'd end up with... something like DNS providers, but they're suddenly managing indexes and metadata for hosted files? I don't know...

(Also, this has probably been worked out already by smarter people than me, I haven't looked at IPFS much, this was just a back of the napkin guess.)

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#166

Post by lgierth » Sun, Oct 01, 2017, 5:31 PM UTC

shade23 wrote: post #158

How does ipfs deal with dynamic content? And how would you make sure that everyone uses an updated version of the website.

See PubSub: https://ipfs.io/blog/29-js-ipfs-pubsub/

You can use it as the base for CRDT structures: https://ipfs.io/blog/30-js-ipfs-crdts.md

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#167

Post by blurbleblurble » Sun, Oct 01, 2017, 5:41 PM UTC

userpass wrote: post #121

vog wrote: post #119

Earlier quoted context omitted.

Here's my complete line of reasoning: You can build mutable systems on top of immutable (append-only) systems. But is that a good idea? Yes, it is, for systems which don't have huge amounts of (non-static) data, and/or system which need an audit-trail anyway. And these are more systems than one may initially think.

I don't really get it. Sure it's fine if one p2P app uses 3GB (1GB for the append only log, 2GB for a database with indices that can actually be queried) of data. What if you have several apps? Let's say 10. Then you need 30GB and because people only have 32GB to 64GB of storage on their phones the discussion ends right here.

I didn't downvote you. But your data sizes are arbitrary.

Why would something like a chat or email app need to hang onto that much history?

Imagine a distributed "email" app that uses networks of mutually trusted peers to deliver encrypted messages ("emails") asynchronously. My device doesn't need to hang onto your emails indefinitely. It only needs to hang onto them until they've been received. This could be done via explicitly sending receipts, or probably in most cases by giving stuff simple expiration dates. The sender would have the most incentive to hang onto the original message until its been delivered.

How this scales in terms of MB and GB is hugely dependent on how your application is configured, how frequently new data is emerging, the limits set by peers for how much they're willing to share, etc. But text is pretty cheap. I can't imagine storing 3 GB of yours or someone else's text emails on your phone, short term or long term. The raspberry pi plugged into the wall at your house can has much more storage anyway ;)

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#168

Post by prithvizi » Sun, Oct 01, 2017, 5:49 PM UTC

How would I use ipfs in a serverless model like AWS Lambda?

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#169

Post by LukeB42 » Sun, Oct 01, 2017, 5:52 PM UTC

Synchrony is an intended solution to centralisation written back in 2015 after being designed since around 2011: http://github.com/psybernetics/Synchrony though this implementation also ships a peer-to-peer hyperdocument editor baked into the core of the UI so the Python PoC is a bit of a mutant.

Currently aiming to release a Go implementation at some point after canning a C implementation earlier this year, where p2p is instead accessed via CONNECT proxy.

Is there any interest in this project?

Re: HTTP is obsolete. It's time for the Distributed Web (2015)

#170

Post by IncRnd » Sun, Oct 01, 2017, 6:15 PM UTC

neutronbits wrote: post #54

IncRnd wrote: post #35

Earlier quoted context omitted.

That's how these things always work, by saying "it will work one day." If it would work, and the cost benefit ratio were there, people would adopt it quickly. That's what happens with just about everything else.

Wow! What an ignorant view of technology adoption! Almost, every revolutionary technology you see today (right from radio and A/C current to personal computers and deep learning) did not work fine once upon a time. It is because people kept saying, "it will work one day", and continued working on them that we have these technologies making our life simpler these days.

> "it will work one day", and continued working on them that we have these technologies making our life simpler these days.

You unknowingly make my point. I have nothing against people working on new technologies until they work. That's a strawman on your part.

But, this isn't a case of working on something until it works. The headline of this blog is, "HTTP is obsolete. It's time for the Distributed Web." IPFS is not ready to replace http, and it won't be until the cost vs. benefit ratio works out for enough people.