How I Invented a Decentralised Scaleable Push-Based Micronews System in 2000

A Repost?

This blog entry might seem like it's going to be a rehash of my previous entry How I Invented Social Bookmarking (in which I claim priority for inventing the Miski system, as documented on Wayback at Miski: A White Paper), and to some extent it is.

The most important thing that has happened since I posted that blog entry is the appearance of FeedTree (by "appearance" I mean a Slashdot story and a position in the delicious "popular" list – the first public release of the software was on 23 August 2005). FeedTree is a proposed solution to the RSS bandwidth problem, and it solves this problem by means of decentralisation and "push" technology.

The only thing is, I proposed a workable solution to this problem, before it even existed. In other words, when I invented my "micronews" system, it seemed rather obvious that it needed a system of clients communicating with servers and servers talking to each other, and it never would have occurred to me to implement my system with something as inefficient as RSS polling.

The official FeedTree paper is FeedTree: Sharing Web micronews with peer-to-peer event notification. This paper acknowledges a number of prior sources, both on and off the web, some going back to 2000. Unfortunately my paper hasn't made it into the list of references, possibly because a web page by Philip Dorrell is just too obscure for anyone to know about it. (To get a measure of this obscurity, try searching Google for "dorrell" and "miski".)

Comparison to FeedTree

Time will tell whether the FeedTree architecture is better or worse than the Miski architecture. I have not yet had a chance to experiment with the FeedTree software, or analyse its functionality and architecture in detail, and the following notes are based entirely on my reading of the FeedTree paper.

Main Benefits

Three major advertised benefits of the FeedTree architecture, as compared to existing use of RSS, are no polling, logarithmic scaleability and permanent URLs. The following is a quick comparison of Miski to Feedtree in their ability to provide these benefits:

• No polling: currently RSS requires each subscriber to individually poll the RSS file of each publisher. Miski and FeedTree both provide push-based user notification, so there is no polling, and no unnecessary delay in receiving new notifications.
• Logarithmic scaleability: Miski offers scaleability as a result of clients talking to servers. The reduction in bandwith useage is a function of how many clients there are per server. If the number of servers grows, then scaleability of server-to-server communication is still a potential problem. Although I did not deal with this problem in my design of Miski, there is nothing to prevent additional layers of scaling, for example where larger numbers of smaller servers agree to communicate via smaller numbers of larger servers, and this scaling would be provided in a manner transparent to end-users.
• Permanent URLs: an RSS URL might have to be abandoned if it receives too much traffic. In Miski, URLs are resolved by DNS (separately from resolution of web URLs), and this has enough flexibility to allow choice of a new server if an existing server encounters difficulties caused by popularity.

Centralisation and Trust

In the FeedTree paper, the authors discuss "Outsourcing aggregation", where centralised servers may have too much control over the operation of the system. In the Miski architecture, a subscribing user's server communicates with a publishing user's server, and each user trusts their own server in the same way that we all currently trust our email service provider or our web-hosting provider. Furthermore, I proposed that Miski should use the domain name system to resolve Miski addresses, which would enable users to transparently switch providers, just like they can now with email service and web hosting.

The Documentation of an Unimplemented System

Does the world benefit from people who invent things and never make them? They say that ideas are cheap and it's the work that counts. Unfortunately I have to work at a real job and pay the bills, but these days I am trying to get more stuff done in my spare time, even if it's just writing my ideas down properly.

There is one practical legal benefit from publishing an unimplemented invention, which is that if someone claims to have invented and patented scaleable decentralised "micronews" distribution, sometime between 3 June 2000 and late 2005, my white paper should be good as prior art. This could be useful in the event of a patent claim which might threaten the development of an open and free implementation of any similar system.