Proof That I Really Did Invent Social Bookmarking

In June 2000, I posted "Miski: A White Paper" on the website of my Miski SourceForge project. That project is now closed, and if you want to read a copy of it then you have to read the version archived on Wayback.

Why Did I Invent Social Bookmarking?

The intention of the Miski system was to solve the problems of Usenet. I had always had the dream that if I had a clever idea about something, I could just post a Usenet story, everyone would read it, I would become famous, and my life would change for the better. People would take me more seriously, and someone would pay me to work on the stuff that I wanted to work on.

So I posted various stories about ideas I had, but the fame never came. And I started thinking about what was wrong with Usenet. I realised that even if I posted a story that could be read by millions, actually it would hardly be read by anyone. And even if there were people out there who would be interested in what I had to say, they probably wouldn't be the people who happened to read my postings.

As I saw it, the major difficulties with Usenet had to do with moderation and control over the definition of the subject space, i.e. the news groups. The set of news groups was defined by some sort of semi-democratic decision process, and if the group you wanted to post in didn't exist, then probably you were out of luck. Some groups were moderated, and some weren't. For example, sci.bio.evolution was moderated. Some groups were too moderated. Most annoying was sci.consciousness, which seemed to be moderated like it was a quality academic peer-reviewed journal. They didn't accept any of my postings. There was alt.consciousness, but no one read that for scientific articles because:

• It was unmoderated, and therefore full of rubbish.
• It didn't have the word "sci" in its name.

In the end I had to make do and post articles about my consciousness ideas into sci.cognitive.

I realised that what the world needed was an alternative to Usenet which avoided the problems of the semi-fixed subject space and the arbitrary mapping from subject name to moderation policy. Taking a radical view, I decided that the new system should have the following properties:

• Anyone should be able to post a story into any subject.
• Anyone should be able to make a new subject to post a story into.
• Anyone should be able to set themselves up as a moderator of any subject.

Poster-Centricity

Given all these radical requirements, something had to give, and the system had to become poster-centric, which meant that subject spaces had to exist inside a user space (i.e. where the users are the "posters"). It would no longer be possible to post or subscribe to a subject; it would only be possible to post and subscribe to a subject within a user's subject space. Making the system poster-centric would create new problems, the main one of which was:

• If you weren't subscribed to a particular user, you would never see the stories that they posted.

The solution to this problem was what I called reposting, which meant that one user could read a story from a user they were subscribed to, and then the user reading the story could repost that story into their own subject space, where it would be read by their subscribers, and so on.

This solution created its own problems:

• There would be many copies of a story being posted back and forth.
• Story contents might get accidentally changed when reposting.
• Users would see the same story twice.

The solution to the first two problems was to only post links to stories, and just keep the stories themselves on ordinary web pages. The solution to the third problem was to recognise duplicates and not show them to users reading stories. Knowing that duplicates are being removed, posting users could happily repost links to stories, without any concern that their subscribers were going to be bombarded with duplicate notifications.

Comparison to Existing Systems

Time passed, life was busy, and I never actually implemented any part of my Miski system. No one appeared to take any notice of my white paper, so no one else implemented it either.

Eventually, as usually happens with any good idea, if no one takes any notice of the original idea, other people think of similar ideas for themselves.

The two main incarnations of the concepts in my system are RSS and social bookmarking. RSS was actually invented in 1997, so it pre-dates my Miski concept. RSS isn't an application, rather it's a file format for representing information about links to web pages. In its most basic form, an RSS file contains a series of items, and each item contains a link, a title and a description, with only the link itself being absolutely compulsory. When I first became aware that people were using RSS, it was mainly being used for people using feed readers to read blogs, and for posting lists of links from one website into a sidebar on another website. Implicit in the RSS format is the idea that people and applications want to produce, process and consume information about the existence of web pages. Which leads on to social bookmarking. Social bookmarking was a development of the concept of sharing bookmarks, where the bookmarks being shared were like the bookmarks that you store in your web browser. The most successful social bookmarking system to date appears to be del.icio.us, and it is possible to identify a number of specific analogies between my proposed Miski system and del.icio.us.

The following table shows a rough set of matching terms and concepts between Miski, RSS and del.icio.us:

Miski	RSS	del.icio.us
subject	category	tag
recommendation	item	link
repost		copy
referral	(a link to another RSS file)	(tag another delicious user's delicious page)
subscription	subscription	subscription (in inbox)

What's Missing from Miski

Given the time that has elapsed since I originally invented my concept, and the various developments that have happened since, it is surprising that there is really only one major concept missing from Miski, which is that of tagging. "Tags" are very analogous to Miski's subjects, but they have two radical features:

• There is no hierarchy or any other required relationship between different tags for a user.
• No space characters are allowed in a tag.

These features combine to make tags as simple as possible, since you just pick one or more words to tag a link, and that's it. There are some downsides to this simplicity. Firstly, if there is no structure to a user's set of tags, it may be difficult to discern the existence of any clear "channels" to subscribe to, so the only way to be sure of receiving all the links published by a user that you want to receive is to subscribe to all of that user's links, unless that user has stated their intention to use certain tags to describe certain types of content.

A second disadvantage is that some times you want to use spaces. Not having spaces within tags simplifies the user interface for displaying and entering tags, but if you want to use a multi-word phrase, you have to choose between several different work-arounds, none of them quite as good as just being able to use a space. For example, if you want to tag George Bush on del.icio.us, you have to choose one of:

• georgebush,
• george_bush,
• george-bush,
• george and bush,
• george, or,
• bush.

In my white paper I discussed subjects "pets", "rabbits" and "pet rabbits". In a tagging system, users would tag with separate tags pet (or pets) and rabbit (or rabbits), and the combination of the two separate tags pet and rabbit would imply reference to a pet rabbit, and it would be pointless to define an additional tag pet rabbit.

What Miski Would Have Which is Still Missing From Other Systems

• Miski was designed to be "real-time", i.e. as soon as one user publishes a link – or "recommendation" as I termed it – this is propagated to the user's server which propagates it to other servers which have subscriptions to that user's channels, and those servers can propagate the link to the clients of their users who have current connections and who are subscribed to the user who published the link. In the terminology of "push/pull", this is a "push" system. Unlike some of the ill-fated push systems of the past which tried to push content, Miski would only push link recommendations. (And clients could choose to receive links by normal "pull" mechanisms if they preferred.)
• Miski was more language aware. I assumed that any particular subject would belong to a language, and that each recommendation would have a language, which in most cases would be determined by the default language of the user. Adding language codes to subjects and recommendations would make it much easier to avoid content not in your own language. So French "chat" (= English "cat") would be readily distinguished from English "chat".
• The client-to-server-to-server-to-client architecture of Miski would make it more scaleable. Single server systems like del.icio.us are not hard to scale, but they leave the users without any opportunity to own the location of their own tagging data. Plain RSS can be in a file on a web server with a domain name owned by the user, but RSS retrieved by HTTP is much harder to scale. Miski would be scaleable and distributed, and it would give all users ownership of the location of their own subjects and recommendations via an extension to the domain system.

Because Miski would be a "push" system, and also because of the client-server-server-client architecture, it needed its own web protocol, and in the white paper I suggested pcmsp:, which stands for Poster-Centric Message Subscription Protocol. An address for a channel to subscribe to might be something like pcmpsp:username@yourdomainname.com/rabbits. A URL handler for this protocol would need to be installed in each user's web browser. (The trend these days is not to define new web protocols, but to define new MIME types, where a MIME type for a protocol defines a file type which contains the connection details for the protocol. For example, if email was a recent invention, we wouldn't have a mailto protocol; we'd have an email-address MIME type, and files of that MIME type would contain the connection details for a user's email, which would consist of one line of text which was the user's email address. For some reason new MIME types are seen as more desirable than new URL protocols, even though the result is that you have lots of little files where each file contains information that could just as easily have gone into a URL.)

Using push rather than pull is the fastest way to propagate new information around the Internet, and if Miski was implemented, I would expect it to make the propagation of new ideas occur much faster than is possible via any existing system. Miski has the optimum combination of speed and freedom. If you are connected to the system at a particular time, you can receive and send new information as fast as packets can travel down the line. But you don't have to receive anything from anyone that you don't want to receive from, and your decision to receive anyone else's input into the system is purely unilateral, and each such decision can be revoked at any time without any fuss or bother.

Using a push protocol, Miski could be used as a form of moderated chat, where a "conversation" would happen in near real-time, without any participant having to receive any information from anyone that they didn't want to receive it from. The nearest we have currently to this is the blog "conversation", but blog conversations take place on a somewhat slower time-scale than a live chat system.

I imagined that Miski would be like the coming alive of the "global brain", where each user in the network was a kind of "neuron", receiving information only from a few input neurons (users that the user was subscribed to), and sending information only to a few output neurons (users subscribed to that user), but with all interesting information efficiently and quickly finding its way from where it is produced to where it is wanted.

Folksonomies

A folksonomy is a categorisation system that is based entirely on combinations of the decisions of multiple users as to what categorisations to use. I hinted at the concept in the Miski white paper, and I quote:

In some cases users may wish to change an existing subject in their subject space to better match the names chosen by other users with similar interests.

Spammability

Spam avoidance was a major concern in the design of the Miski system, and the same concern arises in any social bookmarking or pub/sub system. If you only receive recommended links from individuals you have subscribed to, then spam will hardly happen at all, and if it does, all you have to do is unsubscribe. But inevitably people want to trawl through particular subjects or tags rather than wait for information to propagate through some network they have set up. This gets things found faster, but it reintroduces the spam risk.

The Future

I don't know what the future of social bookmarking is going to be, but it might include someone reading this article and deciding to incorporate Miski-style features into existing social bookmark applications.

Or maybe not, in which case we would have an example of Dorrell's Law of Recursive Internet Meta-Obscurity:

If you invent a social bookmarking system to solve the problem of your own Internet obscurity, unfortunately, due to your obscurity, no one will ever find out about it, and it will never be implemented.