My new blog, the Juxtaprose blog is now online, and, as it turns out, I am now posting there everything I would have previously posted here. So, if you would like to keep up with my posts on the web and technology, please head over to the Juxtaprose blog.

As an example, I'm going to post an entry about why the "web as platform" idea associated with web 2.0 incorrectly equates the platform with web sites / services / companies, rather than with the web itself. I used to write things like this for this blog, but I now get to write shorter and simpler entries for Juxtaprose, and I like the constraints.

So, my current plan for the iCite net blog is to write and post a few more entries about the ideas of the iCite net—just to memorialize them a bit. And, after these are posted, I'll more dramatically "freeze" this site and put pointers everywhere to the Juxtaprose website. By freeze, I mean that I plan to cease blogging here and cease making changes to this site.

***

Personally, I am doing well. I got swamped with a big work project for a few months (since my previous post here), which project recently ended. Now, I am full-time for a couple months on recording an album of my music and launching my extremely small record label and recording studio (said extremely small studio is being built down the hall as I type).

I've also started a new podcast at Wrong Notes, which will pick up again now that I'm not so swamped with web work. Later in the month, I'll post my next podcast on the "Worst Song Ever" (written and recorded by my cousin and myself when we were teenagers).

Thanks for tuning in here—hope to see you over at the Juxtaprose blog and/or Wrong Notes in the future!

I like blogging, but the conversations I am having online are working way better via IM, email, and discussion forums. There, I said it.

I like blogging, and I like having a blog. But, writing stuff that other people read is, at best, only one thing to have a conversation about—it's not actual conversation in itself.

The URL.

While I appreciate that you, oh impressively geeky web 2.0 startup, want me to know that I "own my own data" on your web service, I don't feel like it's really mine unless I can own the URL as well.

I appreciate that you are thinking of me, and offering me at least some opportunity to export and import data from your web service. But let me use my own domain name. This way, you won't be able to take my URL away from me when I want to stop using your service, and I won't feel locked in.

My stuff online means a lot less to me without the context we create for it on the World Wide Web. And, on the World Wide Web, that context can exist because my URL can be used in hypertext references to my stuff.

I can only really call something mine on the web when I own its URL (which, generally means owning a domain name and having at least very basic control over web server paths).

Historical note: from the point of view of the iCite net project, one of the goals was to support a network without this kind of dependency on URLs. So, URLs were overlaid with unique identifiers called CIDs—which enabled stuff (content) to be identified portably across URLs (both at the domain and the path levels).

Part of the reason for CIDs was that URLs, in particular, being directly dependent on the function of domain name system, aren't free to identify stuff (content) that isn't tied to a domain. But, anyway, I realize that asking web service owners to let me use my own domain name with their services could require dealing with some relatively complex DNS issues.

So, you: you have a web service, and you want me to own my stuff that I post on your service. Please think about how to let me use my own domain name as the domain name part of all of the URLs your service creates for my stuff. Otherwise, I probably will stay away.

(Hey, other successful services have done this: Blogger immediately comes to mind . . .)

***

This was originally going to be, at least partially, a shout out to PeopleAggregator (yo Marc!). They are trying to take a high road, beyond the typical web 1.0 / 2.0 "lock-in" model. If you want PeopleAggregator on your own URL, you can run a version of it yourself. That's a way to start . . .

***

P.S. I do have another, new, blog about web design, information architecture, user experience, etc., in the works and launching soon. I'll announce it on this here blog when it goes live. Though, no worries: I'll keep posting strange posts like this one on this here blog :-)

(I am crazy busy with work, though I squeezed a nice camping trip to Lopez Island in this last weekend, and will be at Bumbershoot at least some of this next weekend. :-)

I've started writing a longer post about what I call "Firefox Office", which was set off by Jim Benson's post, When is a Spreadsheet not a Spreadsheet, about Google Spreadsheet and (in the comments) about wikiCalc.

But, I wanted to separately point out this excellent and enthusiastic Screencast of Flock Beta 1, by Josue Salazar (of Made in Costa Rica, which I mention especially because I love Costa Rica, and Josue's enthusiasm reminds me of Costa Rica).

Anyway, I wanted to make a quick point about how the web is more about web browsers than about websites.

In the early days of the World Wide Web, disintermediation, or cutting out the middleman, was a big idea. And, to the degree that the economics of distintermediation didn't work out for everyone and led to the dot com bust, reintermediation has been a big part of the so-called "web 2.0" era, e.g., many of the darlings of web 2.0 are effectively middlemen, albeit they are middlemen of web services, aka centralized websites.

But, the web browser (and, in general, the web client that lets people browser the web, including playing media files) is the interface to the network that is the web. And, as such, websites (and, in general, web services) only matter to the degree that they deliver things to the web browser / client.

Flock is a step in the direction I am imagining in that it allows the browser to interact with web services without utilizing websites. For example, Flock can use either Flickr or Photobucket as its "network" for images that are displayed in the browser.

So, imagine a browser that can use any number of image services the way Flock uses Flickr and Photobucket. Imagine that anyone can host their own image service. Imagine that "hosting" is not really required, e.g., any browser is part of the network and can itself be a host (i.e., browser to browser, or peer-to-peer, image services).

I am just saying: that kind of thing can happen in the browser. And, when it does, it distintermediates the websites and web services.

So, the browser can and will disintermediate all of the web 2.0 version of "the web as platform": beyond this, the browser + network = "the web as platform", or whatever one might want to call it. But, in any case, we won't need any of the current web 2.0 services or sites. They may be options that people will use, but they themselves won't be the platform we'll want to build on (because we'll just skip the middlemen).

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 Irrepressible.info).

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:

to: web@example.com
from: me@my.example.com
subject: get icite.net/*

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

to: web@example.com
cc: you@one.example.com, her@two.example.com
from: me@my.example.com
subject: put icite.net/index.html

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.

Today is the third anniversary of the iCite net project (past eras: first post, first anniversary, second anniversary). And, I am pleased to announce that the iCite net project is now officially and fully hibernating.

I am pleased to announce this because, over the last two+ years, most of my work on the iCite net has been in the realm of trying to get the project in some shape where it isn't gnawing at me. I thought the natural approach was to always keep pushing towards releasing some or all of what I was working on.

But, I've just had too little time to do that in any way that would satisfy my intentions with this project.

So, for the last year or so, I've been asking various friends (thanks—you know who you are) for their suggestions to my question: "what's the best way to let go of the iCite net?"

So, after considering a range of options between just shutting this site down and stopping blogging (least effort) and doing a retrospective blogging marathon of all of the concepts I've discussed here (most effort), I've settled with the idea of hibernating the iCite net. This mostly required that I block-out some time (e.g., to update the icite.net website, which is now stripped down to pretty much just the blog).

So, first of all, this blog will continue to exist. I'll keep using the iCite net blog as I have been—which I don't know how to describe, but, if you're reading this, I am guessing you'll recognize it.

The best thing for me about the iCite net project has been meeting people (i.e., you) who've come across this blog and found that we had one thing or other in common. And, thanks again to those of you who've encouraged me to continue blogging here. That's still going to happen, and I hope I'll keep meeting you.

***

Now, for a brief intermission, I'll mention some of the other stuff I'm up to:

I've been working on the launch of the new Juxtaprose site, which will feature a new group blog on web strategy / design / information architecture / content management, etc. (which is the work I'm doing day-by-day). Friday was Anastasia's last day working at Amazon (yay!), and we are again both working under the Juxtaprose umbrella.

Personally, my major focus has more and more become my music projects. I've been working on a new Ear Reverends album, called Err or Man, which I am really excited about. Check out the Ear Reverends' Wrong Notes blog for updates—my current plan is to start doing a full-on podcast there to talk about and play the works in progress.

I also have several other music projects that I'll be announcing later. And, I am working on creating a new recording studio that is part of launching / expanding my record company, HereJam Records.

Also, I just completed the theme music for the new Make Video Podcast series, hosted by Bre Pettis. The first episode with my music is online, Microsofties Make Bugbots—check it out.

And, also, I am co-writing some of the upcoming Real-World Ajax book (my name isn't up on the site yet, but I am working on chapters with Jim Benson). I think it's going to be a really handy book that you will want to own :-)

***

So, my work on the iCite net project has produced a large mess of potentially very interesting work stuffed in various corners of my computer and office. And, by hibernating this project, I am nevertheless letting the sleeping bits lie.

But by not killing off this blog, I'll keep a place for "stuff like the iCite net" I might hear about or otherwise dig out of my own archive here.

So, I'll kick-off this next phase of the iCite net (as just a blog*) with a mention of something I am excited about. I recently had the good fortune to meet Reg Cheramy, and have some conversations with him about his Zigtag project.

Zigtag is the first web development I've heard about in a long time that really made me go "whoa"—like, it's got the kind-of approach that I wanted to see when I started working on the iCite net.

So, I'll be keeping an eye on the development of Zigtag, and recommend you do too. I am definitely interested in things that push the boundaries of how web the web can be—and will write here about the things I find.

* subject to change

Why is the World Wide Web different than any other "web" (e.g., the semantic web, the blogosphere, web 2.0, the microformat web, the structured blogging web, the web standards web, the tag web, the whole new Internet, etc.)? I think about this question, and feel that the answer, while not something that fits into a soundbyte (or even a blog post), is important.

So, I don't feel like getting into much punditry about this, but I've felt, first of all, the need to distance myself from some of the last-couple-years' trends that overly concentrate the web into centralize services / ownership. So, here are some trends that I've decided to eschew:

Too many people told me that we need to use Flickr to post our photos, so now, I no longer use Flickr. I don't need Flickr.

Too many people told me that we need to use del.icio.us to post our bookmarks, so now, I no longer use del.icio.us. I don't need del.icio.us.

Too many people told me that we need to have links (aka tags that link) to Technorati in our blog posts, so now, I no longer link to Technorati. I don't need Technorati.

Too many people told me that we need to use Google or Yahoo to find useful information on the web, so now, I no longer use Google or Yahoo. I don't need Google or Yahoo.

***

The web is built on a hierarchy of domain names and paths, and this hierarchy can be a significant liability (though, obviously, it has some positive, practical, consequences as well). This hierarchy places each domain owner in the inherent position of power over the uses within their domain.

I had wanted, with the iCite net, to introduce a content address overlay that would live on the web and allow us to route around this particular hierarchy of domains (e.g., if the same web contents can be addressed at multiple domains as the same contents, it's value isn't concentrated into / controlled under a single domain). Someone should consider doing this—it probably isn't actually that hard to do (unless you're me)!

So, the Flickr I want is the one I can at least run on any domain, completely independently of Yahoo's flickr.com and other domains. (Gallery is pretty great, btw, though its social features don't match Flickr's.) And, there are already some alternatives to del.icio.us that can be run on any domain.

We need easy ways to mesh together multiple web resources hosted on different domains (which, given a little more faith in XML-style data than I have, could be done now, even without direct APIs or a relatively simple semantic model like RDF).

I'd also like to have 50-100 great full-web search engines to choose from (my apologies in advance to all of us who ever have to optimize sites to show up better in search engines results). Some of these search services can, as an incentive to people like me, offer more privacy (e.g., not blanketing the web with tracking beacons, and no retention of personally identifiable data).

While the concentration of power into individual domains is one thing inherent in our web that we need to counter, the ability for popular / ubiquitous web services to track and retain data about us (and then to use that data in manipulative or malicious ways, contrary to our personal needs) is something we've casually allowed to become commonplace. We need to kick our habit of turning blind eyes towards these sites / services that keep and exploit lots of data about us, and we need to stop supporting them.

***

I know, for a lot of people, a service like Flickr makes publishing on the web way more accessible. So, I specifically don't want to knock that aspect of these services I've mentioned.

So, it's not like I want these sites to go away. And, I also think it's great when one of these sites is brand new and really catches your fancy (e.g., Flickr was my absolute favorite site for almost a year). But, I think there should be a lot more sites and services like these, run by all kinds of people—and, most ideally, I want to see a huge increase in the means for people to post to the web along a variety of independent paths.

So, I feel I can write about this here because the few people who read this blog, like myself, are probably the ones who should not be pushing people to use these centralized services as if they are inherent parts of the web. Rather, it's probably up to us to be the people who are supporting and developing decentralized alternatives to these domain-locked services on the web.

Starting tomorrow, I will be at the Information Architecture Summit in Vancouver, B.C. Please come on over and say hi to me if you see me there!

Also, I'm looking forward to having lunch (tomorrow) with some of the Bryght guys (at least Boris and Roland) and Will Pate (hey, happy birthday Will!). And, I'll get to hang out with Chris Dent—turns out we're both riding the same train up from Seattle (I'm going to work on some song mixes on the train, and I bet Chris will be coding ;-).

I've been crazy busy and haven't launched the new Juxtaprose website or blog yet. I might soft/half launch just the blog today or tomorrow, as that's the place where I'd probably want to blog about the conference and/or it's subjects. I'll update here with a link to the new blog if I turn it on between now and the end of the conference.

I recently realized that the semantic web is actually pretty successful (e.g., I heard that something like 10x more money is flowing into semantic web companies than is flowing into so-called web 2.0 companies).

I've also become more accutely aware of how popular tech-focused blogs tend to be heavily biased towards the "computer company" model of success, e.g., something is just not successful if it doesn't have a buzz word that's easy to market, and/or a hyped coding technique or tool that programmers can be convinced they need to get on their resumés.

Anyway, I mostly wanted to note this example of the Semantic MediaWiki. If you are at all familiar with wikis, be sure to go into edit mode and see how the semantic wiki markup translates to the displayed information and links on the page.

This seems like an excellent example of a few things:

1. semantic webs can be easy to build
2. the RDF model can be easy to use
3. tags, taxonomies and ontologies are happy together
4. the data entry technique that helped make tags popular is also useful for marking up hierarchies and relational structures

Along the lines of my last point, I wonder whether it'd be fun to think about creating mashups / search engines* based on parsing the wiki markup directly, rather than based on parsing the RDF/XML. . .

* search engines are the orignal mashup apps, right?

(As I sit here watching and feeling philosophically inspired by curling. . .)

Disclosure: the iCite net is just a personal project defined by the occasional gathering of examples of my exploration of what I call different webs. As such, it's almost never about working towards the imminent release of any products, tools, or services—to see any progression here may require a perspective with something like a geologic time scale in mind.

(I guess there are some parts of icite.net that suggest something more exciting is happening, and I should make some time to update these.)