I have the answer you're all looking for

[Om G]

Nathan, this proposition seems to me, to be the most revolutionary and useful improvement on the web possible.

It also opens up the pool of players, providing intuitive value while not restricting anyone beyond the typical fighting over name ownership.

It's also something that can be started on right now in a nicely surreptitious manner using an 'alternative' DNS system. I will say that it's nice to consider a P2P web where DNS is replaced by 

open DHTs, and where each node on the network is both client and server 
(peer) serving and responding to HTTP requests. If you think about it, 
HTTP is a nigh on perfect async communication method for peers to 
communicate with each other, POSTing back replies when they are ready. 
Tip: the last section of the REST dissertation has a complimentary note 
on this, where Roy mentions that adding a simple message identifier 
header would allow async communication with messages being returned in 
whatever order was fastest, rather than whatever order they were 
requested in.

What are thoughts about a modular second-tier system where the endpoint isn't a main node so much as part of a neighborhood hub?

[Nathan Rixham]

Om G wrote:
> Nathan, this proposition seems to me, to be the most revolutionary and useful improvement on the web possible.
>
> It also opens up the pool of players, providing intuitive value while not restricting anyone beyond the typical fighting over name ownership.
>
> It's also something that can be started on right now in a nicely surreptitious manner using an 'alternative' DNS system.

Yes, indeed we could start immediately, we all have a /hosts file on our
OS, we could just point "hello.nn" to an IP address - in one step the
DNS system is circumvented and taken out of the equation.

Step 2 we make a quick app that updates the hosts file from a data source.

Step 3 we webize DNS records in a standard format (linked data) and have
app from step 2 read those records and update our hosts file.

It's small and doesn't scale out of the box, but we'd quickly have an
alternative to DNS and shared understanding, and free "domains".

From there you just scale up, make a net mounted DHT for these records
and so forth - others more skilled in that area can do that.

The main takeaway is that it's possible, really easy to start doing, and
that HTTP and other protocols will all work out of the box thanks to the
abstractions built in to URIs as names.

>> I will say that it's nice to consider a P2P web where DNS is replaced by
>> open DHTs, and where each node on the network is both client and server
>> (peer) serving and responding to HTTP requests. If you think about it,
>> HTTP is a nigh on perfect async communication method for peers to
>> communicate with each other, POSTing back replies when they are ready.
>> Tip: the last section of the REST dissertation has a complimentary note
>> on this, where Roy mentions that adding a simple message identifier
>> header would allow async communication with messages being returned in
>> whatever order was fastest, rather than whatever order they were
>> requested in.
> What are thoughts about a modular second-tier system where the endpoint isn't a main node so much as part of a neighborhood hub?

If you take a bit of paper and draw a tiny fraction of the web on it, a
bunch of interconnected dots, nodes and arcs, then have a good ol' stare
at it, you'll quickly recognise every architecture you can conceive in
there: centralization, decentralization, neighbourhoods, client-server
relations, hubs, p2p networks - clients can only make requests, servers
can receive requests, peers can do both.

If you stick a uniform interface (e.g. HTTP) in front of anything (data
store, web service, data transformation service) and address those
things using uniform names (e.g. URIs), and have them communicate using
uniform media types (e.g. RDF, CSV, JSON w/ schemas) then the boundaries
are broken down, universality and generality prevail.

The web can be seen as a bunch of interconnected agents, communicating
for one reason or another - it exactly models the same connections we
have in the real world, it's a social system - the human world is just a
bunch of interconnected agents communicating for one reason or another.

IMHO, the PeerPoint document describes the web. Begins to capture what's
possible when you realise you can couple a server+client together, and
more importantly has the right social and ethical reasons behind it.

Turing discovered that if you standardize the input in to a machine, you
don't have to break it down and rebuild it every time you want to do a
new task. Perhaps now people are realizing that we don't have to break
down and rebuild our apps every time we want them to do a new task, all
we have to do is standardize the input and output.

Imagine what would be possible with a standardized web dav like protocol
for uniform data (rdf/linked data in various forms), and a standardized
API for using that data - pretty much everything. Especially when you
consider that 95%+ of what every web developer and programmer ever does
is just data transformation, take that out of the equation and you have
a world of developers with 95% of their time free to innovate, create
and discover.

I'm waffling now, sorry lol.

[Poor Richard]

Some damned good stuff, Nathan. I need to get PeerPoint ported to a wiki soon and organized so we can add stuff like this more easily.

On Sunday, July 15, 2012 8:00:54 AM UTC-5, nathan wrote:
<snip>

we all have a /hosts file on our
OS, we could just point "hello.nn" to an IP address  - in one step the

DNS system is circumvented and taken out of the equation. ( . . . )

I posted this to the PeerPoint doc's resource section as "Nathan's routing proposal"

If you take a bit of paper and draw a tiny fraction of the web on it, a
bunch of interconnected dots, nodes and arcs, then have a good ol' stare
at it, you'll quickly recognise every architecture you can conceive in
there: centralization, decentralization, neighbourhoods, client-server
relations, hubs, p2p networks - clients can only make requests, servers

can receive requests, peers can do both. ( . . . )

 

I posted this to the comments section of the PP doc

PR