Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Locking the Web Open: A Call for a Distributed Web

brewster.kahle.org

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Locking the Web Open: A Call for a Distributed Web

#61

Post by Animats »

gglitch wrote: post #56
Animats wrote: post #48

Kahle's approach works only for static content. It's not hard to distribute static content; BitTorrent does it just fine. The Internet Archive stores static content. Kahle thinks in terms of static content, because that's what the Internet Archive does. But it's less of the Web today. Despite that, it's good to have a way to distribute static content. Academic publishing, after all, is almost all static content. That…

Why are micropayments worse than the current web? People have differing opinions on the advertising-pays-for-content-so-don't-block-it issue, but are you referring to something technical?

No, just the general failure of the pay-to-read model. Other than the New York Times, the Wall Street Journal, and the Economist, few general publications with a paywall make money. They all have large, worldwide reporting staffs. Nobody is going to pay to read your blog.

Pando Daily is trying pay-to-read. It's too soon to tell how that will work out.

Re: Locking the Web Open: A Call for a Distributed Web

#62

Post by joepie91_ »

nekopa wrote: post #37
omouse wrote: post #31

Earlier quoted context omitted.

First...IANAL (I Am Not A Lawyer) You aren't the only one, but with Freenet it's fully encrypted. Let's say you had a Freenet Silk Road application. You won't know it's a Silk Road web page that's being saved along with images of marijuana to your computer unless you go through an indexer/search site and even then you still won't know that those bits of data are stored specifically on your machine. So in order for th…

Not talking about the legal aspects, but, (and I really, really hate to bring up the "think about the children!" argument here) what about if I am unknowingly helping people who create and share child porn? It doesn't matter (to me) if I am on the hook for it or not, I just don't know (ethically?) how I would feel if I knew that was going on via my PC. Drugs I don't give a shit about, and I hate how the "think about…

I think an important realization to make, is that you can't fully stop behaviour that you find unethical. If somebody has an incentive for doing it, then it's going to happen, somewhere, somehow, in some way.

Therefore, the equation changes - it's not about what least accomodates those with (in your view) unethical behaviour, but about what most accomodates those with ethical behaviour.

That is why highways and Tor make sense, from an ethical point of view, despite them being used for things you ethically disagree with - because those things would happen regardless (there's incentive after all), and you're simply making ethical behaviour easier.

A similar equation applies to DRM, actually, and to why it doesn't and can't work. Those with 'bad' intentions (ie. pirates) have the incentive to break it anyway - financial incentive for commercial pirates, "for the fun of it" for non-commercial pirates.

Your actual customers, however, don't have that incentive, and to them it's an insurmountable wall that they can't get over, even though all they wanted to do was fix a bug that you as a vendor hadn't had time to follow up on yet.

Not using DRM wouldn't change anything about the 'unethical' behaviour - they were going to pirate it anyway - but it would make things better for those with 'ethical' behaviour.

Re: Locking the Web Open: A Call for a Distributed Web

#63

Post by justin66 »

Titanous wrote: post #23

I really wish that the Internet Archive would provide bulk access to the Wayback Machine dataset. It would allow for a lot of interesting experimentation and research.

> I really wish that the Internet Archive would provide bulk access to the Wayback Machine dataset.

Have you asked them? Did they refuse outright?

Re: Locking the Web Open: A Call for a Distributed Web

#64

Post by phkahler »

api wrote: post #50
schoen wrote: post #49

I'm happy to see this article, and it reminds me of things that others have been talking about for some time (for example, the "Redecentralize" community). I've participated in some file-sharing litigation which has made it very clear to me that decentralized P2P systems are not inherently more anonymous than other technologies. In fact, there's a cottage industry of P2P monitoring companies that participate as peers…

The only mechanism I'm aware of that truly allows anonymity over your own connection (or a connection that can be tied to you) is onion routing. On top of that, you must do it from a separate device or isolated VM to prevent hardware fingerprinting. Anything less than that is like using snake oil crypto: it might make you feel good, but it's not really there.

>> The only mechanism I'm aware of that truly allows anonymity...

We have a need for both solid anonymity and zero anonymity. I think the first step is to be able to authenticate whom you are communicating with, and to reach them without a central authority. After that, you can choose to strip identifying information, or build a web of trust, or anything else. I think privacy can be built on top of an authenticated net, but the reverse is probably not possible. Today we have neither.

Re: Locking the Web Open: A Call for a Distributed Web

#65

Post by Titanous »

justin66 wrote: post #63
Titanous wrote: post #23

I really wish that the Internet Archive would provide bulk access to the Wayback Machine dataset. It would allow for a lot of interesting experimentation and research.

> I really wish that the Internet Archive would provide bulk access to the Wayback Machine dataset. Have you asked them? Did they refuse outright?

I have not personally asked, but I think the Archive Team has. I don't know the reasons behind the policy.

Re: Locking the Web Open: A Call for a Distributed Web

#66

Post by [deleted] »

LukeB42 wrote: post #34

I've been thinking of how to decentralise the web as-is since 2011, the current development branch for this perspective on it is here: https://github.com/LukeB42/Uroko/tree/development It's basically a collaborative caching proxy. One process is a proxy that can also coordinate multiple users editing the same page and a subprocess acts as a DHT node. You can use a raft-like log of hashes of pubkey,content and the pre…

[deleted]

Re: Locking the Web Open: A Call for a Distributed Web

#67

Post by notduncansmith »

LukeB42 wrote: post #53
notduncansmith wrote: post #51

Earlier quoted context omitted.

So the "log of hashes of pubkey,content and the previous hash" is conceptually similar to a blockchain, and I think reading into how that works (consensus, trust, etc) would give you some insight into the issues you're describing. You may also find the IPFS project of interest: http://ipfs.io/

I've found IPFS very interesting and reccommended it to peers, but it lacks the collaborative editing aspect. Trusting the initial public offering of a resource is still an interesting issue. IPFS is content-addressable by hash, addresses map to their content in a computable way. The idea for the distributed hash table in Uroko is that the keys are existing URLs. Imagine thousands of peers all saying they have a new…

> Trusting the initial public offering of a resource is still an interesting issue.

As you mention, resources on IPFS are addressed by the hash, so I'm curious what you mean by "trust" here - do you mean that you can't trust the accuracy/validity of the content? I would assume that content on this kind of network is signed by the publishing party, so if the signature checks out against your PKI, you can trust the content.

I'm also curious as to why Git (or a spiritually similar adaptation) doesn't fit the needs of what you have in mind. Come to think of it, I don't think I see the use-case for Uroko - would you mind explaining?

Re: Locking the Web Open: A Call for a Distributed Web

#68

Post by LukeB42 »

notduncansmith wrote: post #67
LukeB42 wrote: post #53

Earlier quoted context omitted.

I've found IPFS very interesting and reccommended it to peers, but it lacks the collaborative editing aspect. Trusting the initial public offering of a resource is still an interesting issue. IPFS is content-addressable by hash, addresses map to their content in a computable way. The idea for the distributed hash table in Uroko is that the keys are existing URLs. Imagine thousands of peers all saying they have a new…

> Trusting the initial public offering of a resource is still an interesting issue. As you mention, resources on IPFS are addressed by the hash, so I'm curious what you mean by "trust" here - do you mean that you can't trust the accuracy/validity of the content? I would assume that content on this kind of network is signed by the publishing party, so if the signature checks out against your PKI, you can trust the con…

Yes and thank you for your question. I mean the accuracy of the content. As users of a web that's been embedded in a distributed hash table where URLs are the keys and revisions of content are possible values, we will want some peace of mind if an organised party configured nodes to insert advertisements, for example. This means all nodes have an altruism score associated with their public key, and the system being designed to help a node perform a distributed summation of a node's altruism score, producing a positive or negative total. It means having some way of verifying if content you received was good, and some way of rating your act of rating, based on your altruism score.

Another thing is that for obvious reasons initial tests of the network ought to redact all tags from documents before they're ever sent to a browser. It also means manually implementing same-origin policy due to the proxy address being the origin of every script being served to you.

Uroko intends to be a spiritually similar adaptation of git. If you look at the models.py the concept is based on revisions that belong to a path, which belongs to a domain. Think of them as commits on a branch belonging to a project.

So it is a spiritually similar adaptation of Git, but Git isn't an overlay network, which gives us an addressing scheme to identify nodes independent of their ipv4 or ipv6 addresses (Kademlia gives a routing scheme with a possible 2^160 node IDs..), message rebroadcasts, pings, helping peers bootstrap in and transmitting peers you know of in every message, tolerating node failures and ensuring no one is left out of what is an ad-hoc system built on an ad-hoc peering arrangement has been demonstrably well served by the use of this sort of overlay network.

Also Git is not an HTTPD. Uroko is, and a design goal is to support users simultaneously collaborating on the same document in soft real-time. You should be able to synchronise your cache of the web with friends directly, edit over the lan/vlan, and generally keep popular sites available to nodes in your overlay routing table.

Re: Locking the Web Open: A Call for a Distributed Web

#69

Post by substack »

Animats wrote: post #48

Kahle's approach works only for static content. It's not hard to distribute static content; BitTorrent does it just fine. The Internet Archive stores static content. Kahle thinks in terms of static content, because that's what the Internet Archive does. But it's less of the Web today. Despite that, it's good to have a way to distribute static content. Academic publishing, after all, is almost all static content. That…

There are extensions to distributed protocols like bittorrent that are already deployed to address mutable, non-static content. The approaches I know of address content under the hash of the public key. One of these approaches is http://bittorrent.org/beps/bep_0044.html and ipfs supports this technique too.

If you have a single mutable pointer, you can build a feed of data that points at immutable content by its hash, which could replace the data model of twitter, facebook, or many other social networking web services. The benefits to decentralized distribution are huge: native offline functionality, trivially transferable identity, longevity and robustness against providers shutting down, direct commerce without middlemen.

Payments, or perhaps ISP-style peering arrangements may help with the spam/large binary problem. A big part of distributing the data model will also involve distributing the costs, but this is somewhere non-profits like the Internet Archive can play a very important role.

Post reply on HN