Monomorphic

We’ve now had just over a decade of truly mainstream access to and use of the internet. I think I personally took my first stumbling steps on the web around 1995-1996. At the time, it was a limited phenomenon, rife with poor design. It was hard to see what was eventually going to come out of that. And even today, it’s hard to see what today’s internet will eventually evolve into.

If it wasn’t clear before, the events of the past week have made it clear that the internet is a valuable tool for democracy. When everybody can broadcast to everybody else, as opposed to just a select few broadcasting, it’s difficult to control the information flow. Repressing select bits of information becomes hard – the repression just results in the information getting more attention. In the aftermath of Iran’s elections, it seems one of the most important communication channels for protesters was Twitter.  The situation is being likened to Tiananmen square. Together with everybody else, I could follow #IranElection as the events unfolded. It went to the point where the US State Department asked Twitter to delay upgrades in order to keep the service operative, supposedly because of Twitter’s importance in Iran.

I don’t know enough about the candidates to take sides in Iran, but I think one of our fundamental principles should be that nobody should seek to rule by repressing communication. Today, the Internet is a free communications device that anyone can use. How long will it stay this way? When legislators seek to clamp down on the Internet’s uncontrolled nature and regulate it for one reason or another, we should protest. Unrestricted mass communication for everyone is too important an invention to give up.

For those who read Swedish, Rasmus Fleischer has written a brilliant post on the events from a philosophical-historical perspective.

I enjoy experimenting with new software  just to see what people come up with. There’s just so much unknown software to discover. I suspect most people find something they like and then stick with it until it doesn’t work anymore, but there’s something to be said for proactively replacing your software and searching for better things. Here are some things I’ve taken a liking to recently.

New iPhone OS: Apple released version 3.0 a few days ago. It’s been all positive so far. I get spotlight search for the phone, the keyboard feels more responsive, it finally has copy and paste, Youtube appears to have higher quality, and a slew of other features. (Also MMS which I don’t really need in Japan).

GWT: I started playing with the Google Web Toolkit just for fun. For those who don’t know, it’s an API for developing AJAX based web applications using pure Java, which is then compiled to client side Javascript and a Java servlet. It turns out I can be extremely productive with it – I found that it lets me develop fairly advanced web applications using my existing skills. There’s a very high reward/effort ratio that makes me excited. It feels like I don’t need to learn Ruby on Rails properly when I have GWT given that I’m very comfortable developing in Java.. but we’ll see.

Fluid.app: A web browser enhancement for the Mac that allows you to create separate “applications” from web sites you visit often. This means they will show up in the task bar and application switcher, have their own icon, and occupy less screen space. It sounds simple, but it’s a revelation. (And if you’re like me, you tend to have 15+ tabs open in your web browsers constantly, which is a poor way of managing windows).

Chandler: Like many others, I found out about this little calendar and note manager by reading Scott Rosenberg’s Dreaming in Code , which chronicled the misfortunes of an open source startup project. It went 1.0 last year after many years of development. The impression you get from the book is that the developers had a lot of bad luck despite setting out with the right ambitions. This is now an old debate, but the tool is actually usable today – I’ve been using it every day to manage myself for 3 months. Aside from slight bugs, it feels very smart sometimes, thanks to its unique user interface and features.

Micropayments are an old idea.

Examples of services using something that might be called micropayments today are Apple’s App Store (for the iPhone), Sony’s Playstation Network, various MMORPGs, etc. However the typical payment sizes are still quite large:  the smallest possible payment on the App Store is 100 yen (1 dollar). With even smaller payments, say around the value of 0.001 dollars or less, a new range of possibilities is opened up. For those who worry about payment costs, it will probably soon be economically feasible to make payments in the order of 1 millionth of a dollar, given that network costs, processing costs, and storage costs go down all the time – the economics of electronic payment are really changing. Fraud is probably a much bigger hurdle to overcome.

My case for micropayments is about derivative works. I’m not sure what copyright laws will look like in the future, but it is likely that payments and some kind of monetary system will remain in the picture. With the rise of the internet and various kinds of legal and quasilegal file sharing (the American term “fair use” might apply here), a certain kind of derivative work has proliferated. Songs being remixed, music videos being created by fans on Youtube (usually consisting of the song in its original form and fan-made footage), memes floating around. The available technology eases the process of creating derivative works massively.

The existing legal framework was clearly not designed for this. As an amateur musician, I sometimes make music. Once, several years ago, I wanted to sample a tape recording made by Andy Warhol and use it as part of one of my works. After having e-mailed the Andy Warhol Museum, I was told that a written agreement would have to be set up with the Andy Warhol estate. (I have never made a penny from my recordings; they are made strictly for my own amusement, so there was no benefit for me in going through with a cumbersome process). Different countries have different sampling laws, for instance in Sweden sampling something like 10 seconds for use in your own music is allowed without prior agreement. However, the point here is that with a sufficiently advanced major micropayment system, this process could be made much smoother.

Consider completely original works, their derivative works, derivatives of the derivatives, and so on for a certain number of steps. In mathematical terms, this forms a graph (or rather a tree/DAG), branching out and connecting all the included and indirectly included items. With micropayments, it might be possible to pay the creators of each included work automatically by sending money down these connections, slightly reducing the payment amount on each depth level. (The hard thing here is determining the amount to pay and the reduction amount on each step – this would depend on how much the included work has been changed and how prominent it is, among other things). All of this should be fully automatic.

With such a system in place, anyone could sample anything at any time without worrying about legal agreements. Creators might receive a very large number of possibly very small payments. It’s unclear if the final payment distribution would be different from today, but I’m convinced that more derived works would be created.

However, it’s an open question whether these payments always have to be monetary. Can we envision other compensation systems for the digital world (which do not convert to cash)?

I previously commented on Wolfram Alpha and PowerSet. Fisheye Perspective now brings my attention to another “answer engine” as they are called these days: True Knowledge. You have to sign up for an account in order to test it, which I have yet to do, but one feature that’s immediately appealing is that users can add and edit content. This was apparently one of the main design principles. But is this then just an alternative to Wikipedia? Not necessarily, as it also has an inference system (it can deduce facts from other facts). And it has an API for programmatic access. I can think of many interesting uses for an online user-edited inference-enabled knowledge base, if they can get the details right. These things are still in their infancy (I hope, since I want them to be better).

Computers are connected to people, and to the physical world, through input/output devices. These are not just keyboards, mice, monitors, printers etc, but also various sensors, e.g. temperature, light, movement sensors and video cameras, and output devices like industrial control systems or robots. Every day, we increase the extent of what computers can observe, and what they can affect.

Computers are also more connected to each other, thanks to the internet. So now, by virtue of being connected to computers, physical objects are becoming indirectly connected to each other more and more. One of the consequences of this is that physical objects can manipulate other physical objects in different ways, even when they are far away or otherwise unrelated to the sending object. In other words, the internet is converging with the physical world. This is sometimes called the internet of things.

An example: The Nabaztag is a rabbit like internet connected object that has many novel ways of interacting with its environment. However, it’s an artificial object created for this purpose – the real changes are when conventional objects around us become connected unexpectedly. The Economist has an article about what happens when cars become connected. Quote from the article:

“We can stop looking at a car as one system,” says Rahul Mangharam, an engineer at the University of Pennsylvania, “and look at it as a node in a network.”

In preparing for the future, it would be prudent to anticipate a world where things are interconnected even more strongly today. I can think of several problems and opportunities that would arise in such a world:

• Safety, ownership and security become much more important. Today buildings and property are protected by locks and physical barriers. What happens when the weakest link in a security chain is a bit switch in computer memory? (We already have this in many situations today, but those systems tend to be less connected. The pressure to be more connected will turn those bit switches into greater risks.)
• Privacy and anonymity on one hand, versus openness and identification on the other, will acquire even more importance. I expect we will have the ability to control in great detail what information we want to reveal about ourselves and our objects, and to whom and what. For instance, there are experiments with software to accumulate footage from many different CCTV cameras and reconstruct a realistic three-dimensional model of physical reality. There are as many exciting applications as there are dangerous ones (from a surveillance state perspective).
• Completely unrelated objects might be linked to each other in interesting ways by their owners. I might set up a Rubik’s cube so that entering a particular combination on its faces makes my computer decrypt a hidden file (maybe this isn’t very good from a security perspective). The color and intensities of highway streetlights might change dynamically depending on where the cars are. Depending on whether my friends did something interesting today (found out by observing, for instance, their twitter feeds), I might want the speed dial numbers to appear in a different order on my phone. (The system could also try to figure out which friends I might be likely to contact based on my own actions).

But these are all trivial examples.

A related, but different (as I understand it) topic is being researched by Neil Gershenfeld at the MIT Media Lab. They call it “bringing the programmability of the digital world to the physical world”. This seems focussed on creating programmability without conventional computer equipment. If brought to fruition, it might have some consequences in common with increased connectivity.

Indubitably, these questions will enter mainstream politics increasingly in this century. Ideally, the necessary debates will be informed ones, and held early rather than at the last minute when faced with crises.

Image by Great Beyond. Some rights reserved (CC).

Standardised formats are essential to connections in the digital society. On the hardware side, USB is so ubiquitous and well defined that I can connect essentially any peripheral to any PC. In many cases I can even expect them to work without drivers. For sound, the 3.5 mm headphone plug has been ubiquitous as long as I can remember. For video, there is VGA, DVI, and so on. Even if some of these change every now and then, we can always buy converters to convert from one format to another. The changes happen infrequently enough that this is a bearable burden.

On the software side, from a user perspective, it gets tougher. In terms of document formats, everybody is expected to have a web browser, to be able to read PDF documents, and to play MP3 files. There’s also a certain expectation that people can read and edit Microsoft Office documents, but in general, unless people have Microsoft Office itself, they are likely to use some program that does an imperfect job of converting to and from the office formats. More exotic formats people do not expect to share unless they know that the receiver has the same software.

One of the worst situations (and maybe one of the sources of these troubles) is software architecture. To look at just one subset of this universe, let’s consider some popular Java frameworks. There are many Java frameworks. I can think of Struts, Spring, Enterprise JavaBeans, Tomcat, JBoss, Websphere, OSGI. Each one is trying to be a universal, or near universal, component based framework for large scale Java applications. (Some of these are intended specifically for web applications, but the distinction is a bit arbitrary these days). Each one defines a particular behaviour and API that its users need to fit into.

One problem is that once you’ve developed your application in one of these frameworks, it’s tough to move to a different one. At best it’s “just” a matter of using a different API. At worst, the new framework has different expectations of component behaviour and forces you to either refactor your old application majorly or write lots of adapters.

Software has this particular kind of stickiness: objects designed in one context tend to be difficult or impossible to move to other contexts. Here are some problems brought about by this fact:

• Across several different devices and services, I have many different lists of my various contacts. For instance, I have an address book on my computer, which fortunately is shared with my iPhone. However, there’s also a list that Gmail maintains, one list on MSN messenger, one on ICQ, one on Facebook, one on the Playstation Network… etc. In a world with perfect software, I would have a single contact list that could be updated and accessed from any of these services (and I would still be able to selectively hide things from any one service, if I wanted to).
• Most social networks support some kind of status update feature (Twitter, Facebook, …) but they generally can’t share this information with each other. There’s a tool called ping.fm which is able to update lots of networks at once, but this is just for a single feature. And it took a third party tool to do it. And I have to give it all of my logins and passwords.
• The health care systems in many countries are a mess (UK’s NHS and probably most US systems fall in this category). Different medical offices in different medical IT systems establish different journals, but they have no way of sharing the journal if the patient wants to use a different care provider. As experiences in the UK showed, achieving the ability to share these records can be very difficult sometimes.

So how can we design really future proof standards? Here are my intuitive, unqualified answers:

Favor openness over closedness. Allow unknown entities to enter your protocol at many different stages and in many different roles. Even if you don’t design for this, it will tend to happen. Better to design for it.

Allow extensibility in many directions. Frameworks often allow you to make more specific versions of their components, but it’s rare that you can generalize or inject behaviour at a middle level of a concept hierarchy.

Use semantic metadata. Ontologies are under heavy research in computer science. They are formal classifications of concepts and their relations. One popular format for developing ontologies is RDF(S); for an example of what the concepts can look like, check this RDF(s) directory. I will have reason to come back to this topic in the future.

One example of a brilliant long-lasting standard: TCP/IP. Somehow in this case, the designers got something miraculously right at the first try. I’m amazed at how we keep building on this standard every day.