Towards independent web apps

Werner Vogels is stripping away dependencies from his weblog app in a way that all Winerians will find pleasing.

So now we're serving static HTML like it's the 1990's all over again. (Only this time, we're saving them to the file server via HTTP, not FTP.)

This has the nice effect of not tying us into some weird, proprietary server - the only thing it needs to understand is GET and PUT, basically.

But this time, it's the 2010's, and we now have browsers powerful enough to run whatever apps we desire.

So: what about running all the HTML generation stuff in the browser, and using the server only as dumb storage? Just an idea.

The Intimate Internet: You're gonna need a thick skin

Due to social networking, we're all neighbors now. (And it's only getting worse.)

I find that this deprives me of a lot of options for jokes. The people (and their projects) I want to joke about are just one hyperlink away. I myself am quite sensitive to criticism, so I also hold back criticism of others.

But criticism is important, lest we all become a bunch of homogeneous circlejerkers.

In the old days, artists, and everybody who put out stuff into public view needed a very thick skin. It came with the territory. If you were an artist, you had to live with those blood-sucking critics.

But because the internet is so low-key, we're all just normal persons now, putting our projects out into public view.

But that shouldn't stop us from criticizing each other. I think we all need to grow thicker skins, so that we can allow the criticism that invariably comes from public attention.

Get ready to be dissed!

Content-centric networking and microdata

PARC's content-centric networking (CCN), aka named data networking, is a "master idea" about how to re-architect the internet, given what we've learned since the WWW took off.

Like Git, CCN uses content-based addressing. A piece of content has a symbolic name (e.g. /com/nytimes/front-page/2011/02/19), which is cryptographically bound to a signature of the creator of the content (e.g. NYT Corp), and to a hash of the data.

Symbolic names have hierarchical structure, and are late-bound: a common example is /room/projector which is an interface to the projector in the current room. (Plan 9, anyone?)

There are two kinds of packets used in the CCN protocol: Interest and Data packets.

• An interest packet is analogous to an HTTP GET, and expresses the client's interest in a piece of content given its symbolic name.
• A data packet is analogous to an HTTP response, and satisfies an interest. It contains arbitrary content, cryptographically bound to its creator via a signature and to its symbolic name. The receiver can thus easily verify that the content is legit.

CCN can not only be used for classic WWW-style applications, but also for multimedia protocols like VoIP. Results show adequate performance compared to stock protocols. From CCN's content-based architecture we get a lot of benefits for free (e.g. caching is much easier).

Content-centric architectures seem ideally suited to the problems of our current, heavily fragmented social web experience. We still need to figure out the details, though.

See also: camlistore, Content-Addressable Multi-Layer Indexed Storage, a "gitified" database, by the Google frat pack.

Dazed and slightly confused notes on the future of web platforms

First, there's the Locker Project, motto: "I am the platform".

Even though it's by the creator of Jabber, it's not about streaming XML stanzas, thank you very much.

Locker uses JavaScript connectors, that know how to talk to a service to retrieve and sync your stuff (Flickr, Twitter, ...). Think Emacs modes for different services.

Locker seems to run on the server, using node.js, so until everyone of us has their FreedomBox plugged in, this will not really give us freedom.

What if we ran this in the browser, using client-local storage? And then, as Dave Winer would tell us, we push that stuff as RSS, err, Atom feeds, maybe connected using Atom Paging and Archiving, to a dumb cloud store, hopefully free as in freedom? (This is where Content-centric networking comes in, as a simple way to dedup, among other awesomeness.)

Doing the crawling of a user's feeds in the browser has the big benefit that we have cycles to burn and bandwidth to waste there. Scalable following is damn hard, which can be seen from the fact that it's one of the few algorithms that's not provided as a shrink-wrapped, commoditized package. Yet.

The second piece I find wildly interesting is homomorphic encryption. As far as I can tell, the promise of homomorphic encryption re cloud storage is that the cloud store can sort and search encrypted data. I.e., data it can't even look at can still be subjected to the Big Data treatment, aka Google's infinitely-scalable b-tree. (Links: Order-preserving Encryption, Cryptographic Constructions for Secure, Privacy-preserving Distributed Information Sharing.)

Exciting times!

Of course, if we want to do to microdata and the web what Emacs did to plain text and Unix, first we need a real Lisp in the browser. Thankfully, that's exactly what I'm working on at the moment. Stay tuned.