the iCite net > news / blog > a permalink

news and thoughts on and around the development of the iCite net
by Jay Fienberg

How can we move the web?

posted: May 31, 2006 1:52:29 AM

With the iCite net project, I imagined a world wide web that extended 1) beyond the bounds of the physicalness and hierarchy of URLs, and 2) across multiple protocols, beyond just HTTP. (I also imagined a web that extended beyond singular data formats, but I am not going to talk about that now.)

So, in this post, I will attempt to merge a couple things I've been thinking about lately: a crazy idea about using email as an alternative world wide web, and the undermining of net neutrality (which I think is explained well in Ethan Zuckerman's article, One Internet, Indivisible—see also his blog post on Net Neutrality, and the hope the US could learn some lessons from African experience, and Amnesty International's

Part of what makes the World Wide Web great is that all of it is everywhere in the one-click-away sense. And, part of what's a liability of the World Wide Web is that it's one-click-away-ness is dependent on the physicalness of URLs and on the HTTP protocol. (By physicalness, I am referring to the fact that URLs more so than not directly indicate physical servers configured in hierarchical relationships to each other, e.g., from DNS down to a specific website down to the file path of a resource.)

Where the net neutrality issue comes in is in how companies and governments use the physicalness of URLs and our reliance on HTTP to block parts of the web from being everywhere, i.e., these entities are not respecting the world of ends principles, aka net neutrality.

This destruction of net neutrality is happening to one or other degree in different countries, and may happen across the board at the carrier level in the US (more info that might help us stop this). And, so, I've been thinking about how we might want to move the web someplace(s) else that keeps it available.

Now, the someplace(s) else can't be simply another country. And, that's where my #1 and #2 ideas come into play: the someplace(s) else are 1) a web not bound within URLs, and 2) a web not bound within HTTP.


So, just as an exercise for the reader: why should web resources only live in one place on the web, i.e., be tied to a single URL? Why should the web be navigable only via HTTP? Why not have a web where the same information can be addressed in many places at once? Why not have a web that is accessible via multiple protocols?


Now, onto my crazy ideas about email.

When those of us involved with creating the web get excited about "user generated content", i.e., ordinary people sharing info with each other on the web, I think we sometimes forget that these ordinary people, in many ways, have been very effectively sharing info with each other via email for many years.

Having gone through both a few years of "email is dead" idealism and also seen how intensively people use email in a number of settings, I've started to come around to the idea that email is better for "user generated content" than the web in some ways, albeit existing email user interfaces have never evolved into true web interfaces.

To the degree that links are what makes the web work, we need to acknowledge that mostly "links" mean "the browser user interface that let's people click on links and surf from one web page to another". So, I've been imagining a purely email-based equivalent, e.g., where clicking on a link in one email lets you surf to another email.

Email is sometimes described as using "store and forward" protocols, which basically means that emails get copied from one server to another in order to get from one destination to another. What's interesting to me about this is the idea that the same information gets to live in multiple locations.

So, what if we started moving the web into email protocols, and storing and forwarding it to each other. Some is on some or other servers, some is in your "inbox". But, imagine it's still a web that you can get to by clicking a link.

Email protocols are more asynchronous than HTTP, and this means that anything that isn't already cached locally on the email web won't be snappy and quick. But, I imagine a different interaction can occur, based on the fact that computers have more and more hardrive space.

So, on the email web, I would request the complete Wikipedia that might be returned as 100,000 emails to me, with new and updated articles being resent at some interval. When I want to access Wikipedia, I access a local copy. If I need the most up-to-date info, I subscribe (OMG, we don't need RSS, right! it's all just email) and get new emails.

Then, I can send an email to all of my friends noting that I have a complete copy of the Wikipedia—my email includes a link, which when clicked, takes them to my local copy of Wikipedia on the email web. Wikipedia can be made accessible through anyone's email address.

Internet cafés can cache sites like Wikipedia providing fast local access via a location accessible email address. (And, I should note here that my effort on the iCite net was to first use HTTP for all of this, and just abstract the URLs—email doesn't inherently make this all work / it's not that this couldn't work with HTTP too. Ideally, one's browser could switch between HTTP, email protocols, IM protocols, etc.)

Again, imagine an email client that makes this all seamless. It's a web browser, and it's all about links. It's just that the links initiate interactions over email protocols.


A key piece in all of this is identifying and addressing things. The World Wide Web combines this—an article on Wikipedia is identifiable by its URL which is how the article may be addressed and accessed.

With this email web, let's imagine that the HTTP URLs are still used as identifiers (i.e., truly as abstract URIs, in fact). But, they no longer are, in themselves, addresses. Instead, one might use an address like:

subject: get*

And, we could also imagine "push" interactions like:

subject: put

Note the peer to peer(s) nature of the exchanges that comes from having persistent "from" and "to" addresses—that's a powerful feature that many aspects of social software on the web / RSS / web 2.0 / mashups / AJAX has tried and failed to beat.


Anyway, I've decided to leave this a bit rambling and disorganized with the hope that it kind-of starts your mind wandering down some different paths. The themes are: making different webs, creating a true web interface for email, and thinking about how we can continue to have a World Wide Web in spite of centralized and competitive interests trying to carve-up and lock away (or, even "own") parts of the current web.

permalink | comments {0} · trackbacks {0}

also available as: rss · rss2 · rdf · atom

Comments and Tracbacks

Note: All comments and trackbacks are moderated. Spam is deleted. Other comments are approved as promptly as possible.

Note: Older posts no longer accept new comments or trackbacks.

« prev post
Third anniversary of the iCite net, which is officially hibernating (or, the iCite net = just a blog*), and everything merges with the night

» next post
The browser for disintermediation on the web (and of web 2.0)

blog newsfeeds

brief content:

 XML  ·  RSS  ·  RDF  ·  Atom 

full content:

 XML  ·  RSS  ·  RDF  ·  Atom 

blog archive

jan · feb · mar · apr
may · jun · jul · aug 
sep · oct · nov · dec
jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

jan · feb · mar · apr
may · jun · jul · aug
sep · oct · nov · dec

may · jun · jul · aug
sep · oct · nov · dec

first post: 
April 30, 2003

highlight views:
Spammers' Choice

Jay elsewhere online
Jay Fienberg - the official home page

Wrong Notes - the music blog of the Ear Reverends

Fine & Full, aka, a fine and full burger

Sociomobilepoetextologia (moblog, currently inactive due to lack of proper mobile)

to enjoy roll
sites I like to read when I start from here

· Anastasia Fuller
· Andy Baio
· Biz Stone
· Boris Mann
· Bre Pettis
· Chris Dent
· Danny Ayers
· Dare Obasanjo
· David Czarnecki
· David Weinberger
· Don Park
· Evan Williams
· Greg Narain
· Jason Kottke
· Jim Benson
· Lucas Gonze
· Marc Canter
· Matt May
· Matt Mullenweg
· Michal Migurski
· Nancy White
· Rebecca Blood
· Reg Cheramy
· Richard MacManus
· Sam Ruby
· Shelley Powers
· Tim Bray
· danah boyd

powered by blojsom

Entries by blojsim