Live data from Hacker News

Will there be a Distributed HTTP?

mnot.net

41–50 of 72 posts

Re: Will there be a Distributed HTTP?

#43
post #24

How is this distributed model going to deal with the fact that a lot of (all of?) the websites we visit have dynamic content? I feel like I'd be much better off, privacy-wise, if I could get a browser that had a user manageable list of locations to pre-cache with some kind of daily/weekly offline cache refresh. So when I go to a web page that fetches jquery from google's hosted libraries service, it instead pulls it…

Isn't this how IPFS works? Content is hashed so it will check to see if you have it locally first, then inside your network, then externally from the the closest node that has the data.

Re: Will there be a Distributed HTTP?

#44
post #5

This is actually a pretty cool idea (although perhaps badly explained, given the other comments here). Here's how it could work: IPFS ("In some ways, IPFS is similar to the Web, but IPFS could be seen as a single BitTorrent swarm, exchanging objects within one Git repository") is a globally distributed hash-addressed versioned filesystem. (see: http://ipfs.io/ ) They have a mirror of their homepage hosted on IPFS, he…

Sorry to be pedantic... I thought their main website actually just proxies to the actual ipfs gateway. Is it technically a mirror?

Re: Will there be a Distributed HTTP?

#45
One of the things I wish browsers supported would be signed content... IE your CDN/distributed content doesn't need to be on HTTPS, just have a header with a payload signature against the HTTPS cert that the application host uses... I don't know why such a beast was never introduced into the browsers.

I also feel that it would be nice to see more p2p protocols especially regarding live chat, and other systems. I think having a self-discoverable alternative to IRC could be a pretty nice thing... of course eventually the bots would destroy it if it got popular.

Re: Will there be a Distributed HTTP?

#46

Earlier quoted context omitted.

> Ultimately, it was a losing game, because of the inherent conflict of interest between software author and software user. This is exactly what is broken with our current software business models. On-prem software is expensive to deploy and manage but gives users control of their data. SaaS software is cheap to deploy and manage but takes control of the user's data. We must find middle ground between the two models.…

I'm working on an interesting project right now where the web application behaves like a typical SaaS solution, except that all of the customer's data is hosted on premises. After the initial install, their local servers (and data) don't have to be touched, but the SaaS portion can be continuously improved. So far it's worked really well. Your MSaaS idea sounds really interesting, especially the multiple trusted depl…

There are others working on this now, here in San Francisco. I think it's the tip of the iceberg. The on-prem ISV market is fucking huge.

Re: Will there be a Distributed HTTP?

#47

One of the things I wish browsers supported would be signed content... IE your CDN/distributed content doesn't need to be on HTTPS, just have a header with a payload signature against the HTTPS cert that the application host uses... I don't know why such a beast was never introduced into the browsers. I also feel that it would be nice to see more p2p protocols especially regarding live chat, and other systems. I thin…

That's actually been discussed quite a lot. However, it shares the "request privacy problem" that I talked about in the blog entry; the mere fact that you're requesting information -- even if it's public -- is sometimes sensitive information.

Keep in mind that the determination of its sensitivity is often highly contextual; e.g., something that's not a problem in your country may be illegal elsewhere, or someone in a different situation to you may feel differently about how their request stream should be treated.

Re: Will there be a Distributed HTTP?

#48
post #6

This is one of the most crucial things we need to make free software viable again. In 2006, I wrote that the only solution to the problem of proprietary services was to "build these services as decentralized free-software peer-to-peer applications, pieces of which run on the computers of each user": https://www.mail-archive.com/kragen-tol@canonical.org/msg001... And, in particular, I wrote a few months later that rep…

> replacing HTTP URLs for naming content is necessary and nearly sufficient It depends what you replace them with. I quickly skimmed your essays looking for any proposals, but didn't quite see anything. The obvious thing is Freenet-style public signing keys, but while this helps decentralize distribution (a boon to a person who wishes to publish anonymously - upload and run), the standard centralized naming hierarchy…

I don't know what the answer is. I agree with most of what you say. I think we have to experiment with things that could work in theory and see what works in practice.

Re: Will there be a Distributed HTTP?

#49
Yes, I've already implemented it:

Distributed HTTP: Maalstroom on MORPHiS :)

GPLv2 unlike Bittorrent Inc.'s Mælström

https://morph.is

It is very fast because it is not anonymous first. Although it is 100% designed with being non-leaking over Tor. It already works over proxychains great. I will add SOCKS5 support soon.

Also, don't forget the distributed spam resistant automatically encrypted and transparently authenticated mail:

https://morph.is/v0.8/dpush-whitepaper.odt

Dpush is distributed /unsolicited/ POST :) Solves the previously open problem perfectly.

MORPHiS hosted MORPHiS website:

morphis://sp1nara3xhndtgswh7fz OR localhost:4251/sp1nara3xhndtgswh7fz

URL is a hash of the data or the key that signed it. No MITM possible.

The next module I am implementing is DDS - Distributed Discussion System. It is quite easy because it is fully enabled by the existing Dpush invention that already powers MORPHiS Dmail.

Re: Will there be a Distributed HTTP?

#50
post #21

Earlier quoted context omitted.

A bit of a non-sequiter, but I'll bite. Replicating toolboxes. Or self-replicating benchtop factories. Microcontrollers could be produced using dip-pen nanolithigraohy, or a few other techniques. Of course we need decent open source atomic force microscopes first. There will always be components that can't be produced on that kind of scale. In reprap parlance we call the "vitamins". An apt metaphor.

> benchtop factories This is feasible even using current production techniques. Just make smaller tools. Open hardware designs are a bigger part of the problem, IMO.

We have open hardware designs including the RISC-V, the OpenRISC, and the SPARC, but we don't have desktop semiconductor fabs, nor will we in the foreseeable future.
Post reply on HN