Live data from Hacker News

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

blog.neocities.org

111–120 of 227 posts

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

#111
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.

[deleted]

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

#112
post #61

Earlier quoted context omitted.

Databases, and dynamic content in general, can be done with/on IPFS. Take look at OrbitDB ( https://github.com/orbitdb/orbit-db ) - "Distributed peer-to-peer database for the decentralized web" or their blog post "Decentralized Real-Time Collaborative Documents - Conflict-free editing in the browser using js-ipfs and CRDTs" ( https://blog.ipfs.io/30-js-ipfs-crdts.md ). And all that works in the browser without runnin…

In general? No. Just because you can, it does not mean you should use a distributed db. Please remember to say that distributed, open databases have very narrow use cases. Leaving aside use cases like credit card information, there are a lot of user information that is illegal to share unless the user explicitly consents. In the EU you can't even share your access logs by default. And how do you handle authentication…

> "Distributed filesystems and CDN in general are great, but let's use them for things that do not actually need a single bit of security, please."

The notion that distributed filesystems are inherently, or can't be, secure is way off. I would argue that with these technologies, such as IPFS, they can be more secure.

The use cases are not only "open databases" (by which I assume you mean open to public), private databases and data sets can be achieved just as well. Just because it's "distributed" doesn't mean it can't be private or access controlled.

Agreed on the comment re. "...illegal to share unless the user explicitly consents" and I believe this will turn out better in the trustless, distributed web, eventually. Our whole current approach is based on the client-server paradigm forcing us to put every user and their data into one massive centralized database. But we can change the model here. Instead, how about you owning your data(base) and controlling who gets to access it? "Allow Facebook to read your social graph?" "Oh, no? How about another social network app?". As a user, I would want to have that choice.

That bridges to your next point on authentication, which can be done on the protocol level with authenticated data structures. You can define who can read/write to a database by using public key signing/verification. It could be just you, or it could be a set of keys. One good example of this is Secure Scuttlebut (http://scuttlebot.io/). I highly recommend to take a look an understanding the data structures underneath.

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

#113

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…

You're not describing a problem that users need fixing. You're describing how nice it would be for corporations to unload their own infrastructure requirements onto unsuspecting users to try to piggyback on their hardware. That's not a solution to any problem. That's in fact a problem being created for users. Consumers purchase hardware to fill their needs, and there's nothing to be gained for wasting their resources…

well... discounts...

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

#114

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…

You're not describing a problem that users need fixing. You're describing how nice it would be for corporations to unload their own infrastructure requirements onto unsuspecting users to try to piggyback on their hardware. That's not a solution to any problem. That's in fact a problem being created for users. Consumers purchase hardware to fill their needs, and there's nothing to be gained for wasting their resources…

Isn't this the reason why they introduced Filecoin? To incentivize consumers to share their resources.

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

#115
post #46

So a couple questions even reading this... 1. The availability depends on the number of peers like BitTorrent? If so, and if no seed is available, how does one access the content, esp in the context of an intranet? 2. Any change to how we run infrastructure except not serving HTTP?

There are services like www.eternum.io (which I wrote) which you can pay to seed your content. Those ensure that it'll stay up even if some of your content is not very popular.

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

#116

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…

Since I've started using syncthing, I've also had similar thoughts. Say you want to start a private, static blog for a small group of friends ... why host it publicly, then lock it down? Why not just use sync a shared a repo?

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

#118
post #61

Earlier quoted context omitted.

Exactly. It's like, Woah, hold your horses there. "Obsolete"? I don't think so. To what extent can this IPFS serve an API or a dynamic database at this point? To what extent will it ever be able to do that? I think HTTP/websockets is very good for these things. Static data is one thing, dynamic is a whole other story. It seems IPFS is just a new distributed way to archive data. So what? It doesn't help serve somethin…

Databases, and dynamic content in general, can be done with/on IPFS. Take look at OrbitDB ( https://github.com/orbitdb/orbit-db ) - "Distributed peer-to-peer database for the decentralized web" or their blog post "Decentralized Real-Time Collaborative Documents - Conflict-free editing in the browser using js-ipfs and CRDTs" ( https://blog.ipfs.io/30-js-ipfs-crdts.md ). And all that works in the browser without runnin…

Think of orbitdb as a git repository where everyone has write access. Malicious nodes will spam hundreds of gigabytes of data into it until it's large enough nobody can clone it. Even if you solve the spam problem you still have the problem that you need to download the constantly growing dataset. The blockchain is already 160GB big even though it's transaction throughput is anemic.

Full p2p applications can't offload computation, computations have to happen on your computer and for computations you need the entire dataset. This is fine for messaging and static files.

Federation is a far better idea. You get the benefits of centralisation and decentralisation.

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

#119
post #101
post #92

Earlier quoted context omitted.

I agree with you, but your argument is deeply flawed. There's quite a far stretch between "Y can be built on top of X" and "X is good for Y". To provide an argument that might fill this gap: Most systems don't actually have a huge amount of data. Look at the data size and data growth of CRMs, special-purpose wikis, and so on: These are mostly smaller than 500 MB (excluding static content like images), and grow by les…

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.

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

#120
post #92
post #91

Earlier quoted context omitted.

See the comment below https://news.ycombinator.com/item?id=15376665 . It is not true that distributed systems are only good for static content or "append-only" data. "Mutable systems" can be built on top of immutable systems.

I agree with you, but your argument is deeply flawed. There's quite a far stretch between "Y can be built on top of X" and "X is good for Y". To provide an argument that might fill this gap: Most systems don't actually have a huge amount of data. Look at the data size and data growth of CRMs, special-purpose wikis, and so on: These are mostly smaller than 500 MB (excluding static content like images), and grow by les…

I don't really see why a CRM needs to be decentralised. You need to host it yourself to avoid a cloud vendor going out of business but other than that what problem do you solve by decentralising it?
Post reply on HN