“Basecamp was done almost entirely without risk.”

April 22, 2011 | 1 comment

I really like this quote from 37 signals:

Basecamp was done almost entirely without risk. It was completely self-funded. We treated it as a side-product and a side-project until it could pay the bills. And only then did we make it the main focus of the company.

I absolutely hate risk. I think it’s a misnomer that entrepreneurs somehow are in love with risk and making big gambles and taking big bets. I think that’s probably true for some. It’s certainly not true for me. And I think it’s certainly not true for a large constituency of other successful entrepreneurs.

I think the act of putting yourself in a position where you’re not forced to take on all this risk and bet everything is the hallmark of running things well.

The comments are worth a read too. In particular, I agree with the assertion that if your job doesn’t allow you to have site projects, you should get a new job.

httpID: adding identity to standard HTTP requests

April 19, 2011 | 17 comments

This is a more technical post than I’ve been writing lately. I’m considering splitting out into two blog channels; let me know if you’d prefer this.

This is a request for comments and ideas. Please let me know what you think in the comments. Thanks!

One of the advantages of the decentralized social web, as opposed to a social network (federated or otherwise), is that identity can, theoretically, be shared with any web page, anywhere. That page doesn’t have to be running any particular software or provide any particular function; it should optionally be able to support identity-related features. That could then be used to tailor the page to the viewing user. (Of course, sharing identity should never be required, for security reasons.) This is part of three broad activities that I see as being part of the social web:

  • Publishing web content in an identity-aware way
  • Consuming web content in an identity-aware way
  • Sharing socially

Much of the decentralized social web development activity to date has been focused on the third point, and on reading and writing as part of a social web application like StatusNet or Diaspora. However, I’d like to look at the first two points with a view to make them web infrastructure, rather than features of a web application.

To achieve this, I’d like to be able to report, as an option, the identity of the person making an HTTP request, as part of the headers to that request. This might come from the browser itself, eg via an identity plugin, or it might come from a web-based identity proxy.

HTTP supports basic authentication, which involves sending a username and password, potentially in the clear. Out of necessity, we’ve moved beyond this, eg for things like API authentication. Often tokens, hashes and encrypted requests are included as extra header values to authenticate a request.

I’d like to use the same general principle for identifying a user. Here’s how it might work:

  1. The user visits a site for the first time. The browser sends a standard HTTP request. (Or, alternately, a HEAD request, if the site content isn’t required.)
  2. The site responds as normal, but with an extra HTTP header indicating that it’s identity-aware, including the URL of a handshaking endpoint. This will be ignored by clients that aren’t looking for it.
  3. If this is a standard browsing scenario, the user’s browser asks if he or she would like to share identity information with the site. For the purposes of this example, the user clicks “yes”. (This step can be left out if this isn’t a standard browsing scenario.)
  4. Via the handshaking endpoint from step 2, the user’s browser gives the site a public and private key, and a URL, through which it can access the user’s identity information as an XRD file (as in Webfinger). This is exactly the same as the public and private key system used to retrieve social information in points 5 and 6, using the same method. The site simply makes a signed request to the user’s identity URL, which can be anywhere.
  5. The browser receives public & private keys for use with this server only. These might be stored in the browser, or in some central identity store that all the user’s browsers access.
  6. Whenever the browser makes a request to the server, it adds extra headers using these keys (and HMAC-SHA-1), signing each request with the user’s identity until he or she says otherwise. It also sends a header to indicate when the user’s identity information was last changed, in order to prompt the site into obtaining new information if it needs to.
  7. If the site in point 4 is associated with a specific person (for example benwerd.com would be associated with Ben Werdmuller), he or she can use the public and private key generated in step 4 to browse the user’s site.

The publisher would get a list of users who have identified with the site, and, depending on their server or content management system, might add some of them to special access control groups that would allow access to different content. The next time the user visited the site, they’d see more privileged content. A notification would probably be sent to them to let them know this had happened, but this is out of scope for what I’m discussing here. (Perhaps notification methods could be shared as part of a user’s identity information?)

Conversely, the user’s XRD file containing their identity information can also change depending on who’s accessing it (as the requesting site always makes a signed request).

This system has a number of advantages:

  • It’s server and system agnostic. It simply uses the building blocks of the web.
  • It’s very easy to build for. Checking and setting HTTP headers are easy to do, and don’t require any front-end work like HTML parsing or JavaScript libraries. This makes it usable for APIs and feeds as well as web pages, and for clients that use web APIs as well as web browsers.
  • The web isn’t just a platform for people to read these days. This method doesn’t depend on anything visual.
  • You don’t need to control the root of a domain to make it work. If you install a script at http://yourdomain/~foobar/banana/hockeystick.php, the system will be happy there too.
  • It’s passive. There are no blockers if you don’t supply identity information – you just see something different.
  • It’s based on similar assumptions to WebID, but doesn’t require SSL certificates in the browser, and it’s as easy for a web app to implement as it is for browser software.

It incorporates the following assumptions:

  • Relationships are assymetrical. (Here, there’s a set of keys for each side of a relationship. If one side stops participating, perhaps by removing the other from an access control group, the other side is still valid.)
  • Privacy isn’t binary. (Everyone gets a different view on a given page or piece of data.)

Let’s call it httpID. I’m looking for feedback on the idea and process. Does it make sense? Have I missed something obvious? Let me know. If there are no major blockers, I’ll firm up the spec and create some libraries.

Bookstores and serendipity

April 15, 2011 | 2 comments

Here’s one of my favorite places on Earth:

Blackwell

It’s called the Norrington Room. It sits in the basement of Blackwell’s, the oldest bookshop in Oxford (where I grew up), and when it was opened in 1966 it was the largest room full of books for sale in the world.

I love bookshops, but I rarely spend money in them any more.

Over at the Scottish Book Trust blog, Heather Collins has written a plea for the survival of high street bookshops, arguing that we should pay the bookshop price premium for similar reasons to paying extra for organic food. There’s no denying that they’re a dying breed, and while I certainly agree that I don’t want to see the demise of the bookstore, I also don’t think that artificially supporting them because they inherently deserve to survive is going to work.

So what is it about bookstores that’s so wonderful, compared to (and let’s face it, this is what the choice boils down to) Amazon?

Whenever I’m in Berkeley, I take time out for a visit to Moe’s Books on Telegraph Ave. It doesn’t look like much from the outside, but its textured history and almost anarchic layout over five floors makes a visit feel like diving for treasure. Moe’s is opinionated; the staff clearly have an opinion about what you should be buying, and their passion comes through in the way they store and display their stock. They know you could head over to Borders, or do a book search on Amazon, so what Moe’s deals in is serendipity, distilled and condensed and plastered all over their shelves. More so even than the Norrington Room, this is a place you walk into when you don’t know what you want to buy. (A lot of people like City Lights, across the bay in San Francisco, but for me Moe’s is where it’s at.)

Amazon also wants to introduce serendipitous discovery, but it does so naively, using a process I wrote about years ago. They simply look at their aggregate data and tell you what other people bought, based on the product you’re currently looking at, the products you’ve looked at previously, and overall. Some of the recommendations are decent, but it’s so far proven itself to be a particularly bad system for uncovering titles that aren’t necessarily related to recent searches, but you find interesting anyway. They try and mitigate this with curated lists of products, but it’s hard to find one from someone whose opinions you’re interested in, and they’re too easy to game by marketers.

I think this kind of cultivated serendipity has the potential to be the savior of bookstores. Conversely, trying to directly compete with Amazon will be their demise. There’s no way they can compete with the online bookstore’s distribution, reach or economies of scale, but there’s also no way a software platform – even one as sophisticated as Amazon’s – can compete with the humanity of a few opinionated people who know a lot about books.

So bookstores should forget the identikit chain model. Hire the smartest people they can find – as Blackwell’s does – and get them to cultivate collections of interesting, hard-to-find books in such a way that unsuspecting customers can fall down into rabbit holes of hitherto undiscovered ideas. Serve great coffee; encourage visitors to browse and read. Have themed evenings, run book clubs, invite authors for signings. But embrace the fact that some people will be reading ebooks, and others want to buy bestsellers online. Run kiosks, and find ways to sell ebook versions of those hard-to-find books they’ve lovingly placed on the endcap. Make high street stores a place for discovery and learning, and even fill some of the gaps left by libraries (another dying breed). Turn them into social hubs with events and music.

An organic, human community? Now that’s worth paying extra for. It’s no wonder that so many identikit chain bookstores are dying at the hands of Amazon: they don’t dare to offer anything different.

Photo of the Norrington Room by Juan J Martinez, released under a Creative Commons license.

Confessions of an entrepreneur’s wife

April 14, 2011 | Leave a comment

This article is long, but worth reading to the end:

He came home and lay on the couch for a week, confused and a little lost. With the long overdue luxury of time and hindsight (and bed rest dictated by a bad case of bronchitis), he analyzed the past year’s activity. He believed that the two board members and the slow-paying investment group were planning to bankrupt the company in order to buy it cheaply out the back end.

Following my post yesterday about becoming a tech entrepreneur, Phaedra Hise’s story about her husband’s adventures in a beverage startup includes the dangers, high points and low points of running your own venture – both in terms of your business and your personal life. It’s well-written, vital stuff. Click here to read the full article.

Edited to add: anyone who knows me even a little bit will know that I don’t particularly sympathize with Bill in this article – but I thought I’d make that crystal clear. Nonetheless, it’s a good article, particularly if you read between the lines.

Next Page »