Guest post by Hans Blaauw, The Skypeteer

[Editor: I'm sooooo sorry for spelling your name wrong, Hans. Corrected.]

UPDATE 13 December 2005: the download is temporary offline. Download Mood O Matic

With the introduction of the Skype mood field in version 2.0, I have come to the conclusion that this Mood field can be used for much more dynamic information to show to the world.

After enabling my Mood O Matic i immediately received a few people interested in it. This proofs that information in the mood field can be very powerful. (by the way, the odd looking dude on the picture is me the bluedude).

That's why I created the Mood O Matic. This software does dynamic mood by using Moodies.
Moodies are code snippets that update the Mood in Skype with interactive information. Information can be:

- items from a RSS feed;
- highest auction bid on a product you sell;
- output from a brainscanner :-) (Thanks Mat);
- information from a database;
- anything else...

The script Moodie can update the mood field by getting information from scripts:

Below you find some sample URL's to use:

http://www.skypeteer.com/moodies/stock.asp
http://www.skypeteer.com/moodies/skypestat.asp
http://www.skypeteer.com/moodies/cnn.asp

For developers
Developers can develop new moodies that are configurable through the main Mood O Matic interface. Besides that developers can write scripts that produce dynamic information.

Checkout the readme file in the VB6 moodie sample directory.

Coobol, the new p2p R&D firm, mapped Skype supernodes earlier this week. (Full size image, 1.1MB) A Coobol spokesman explained it like this:

A Skype supernode is a dynamic peer-to-peer server in SkypeNet. A supernode is one of Skype’s users. Powered by these unknown supernodes or users across the world, Skype is able to provide the super world telephony communication system for free. However, this is not something new. As we all know, this is just the basic theory of peer-to-peer technology. Inspired by p2p mechanism, Coobol will provide our partners with software, solutions and Internet platforms for them to build a variety of applications, such as P2P network security, content publication, streaming media, global VOIP network, virtual office, SNS (Social Network Service) etc. We are determined to be a world-class peer-to-peer research and development company.

Coobol is a peer-to-peer technology specialist. They focus on the research and development of software, network communication platforms and tools based on peer-to-peer technology. They "bring ordinary people together to create miracles." The name Coobol was created initially by team members during a tea party. Their office is in Hong Kong.

There are many things we don't know about Skypenet, that I would hope technical R&D firms like Coobol might be paid to investigate. For instance,

• What is the frequency distribution of Skype supernode lifespans?
• Why are Chinese Skype supernodes not shown on the map? Where else are these factors at play?
• How does the number of supernodes vary by time, for example by time of day and day of week?
• How many supernodes are being operated by Skype itself instead of its users?
• How many supernodes would an attacker have to disable to cause the remaining supernodes to overload?
• What is the range of Skype users supported by supernodes? Does this vary a great deal?
• Any way to tell how many supernodes are being run over dial-up connections?
• Do all the regions have similar ratios of nodes to supernodes? Or do they vary?
• Are the number of supernodes keeping up with the number of active Skype users? With the the number of minutes served?
• If you can identify Skype supernode IP addresses, can you measure the amount of cloud traffic a supernode passes along? The amount of chat/voice/video/data relay bandwidth?

This gent put his 277 Skype contacts to use today as he changed his "real name" to "1968 DB5 - Bid: £30k - 4 hrs left" for a while.

It's a great example of "field overloading," where users put a form field to novel uses. In this case, using Skype's p2p white page cloud to share a classified automobile-for-sale advert. Overloading is often a response to users wanting to use a system for more things.

You can easily imagine sharing your eBay listings, romantic status, career availability, or your public calendar. Some you'd make public, others shared to select friends or your whole buddy list. Putting your social capital to use at the edge of a network.

The Skype team that defines the user profile fights to keep it simple and small. Big and complex slows down the Skype ID cloud. Even small changes to the profile can double the bandwidth Skype clients use to keep the cloud moving or to search the cloud.

Skype product architects should pay attention, though. This is opportunity knocking, tipping its hand. Can you spell "Edge Commerce"?

Have just read Richard Stastny's comprehensive recount of the goings-on around ENUM at the IETF meeting in Paris. I can't but help feel that, despite the good intentions, some decidedly anti-competitive actions are going on here by the carriers.

In essence, the telcos are keeping control over a numbering business that is being run as a cartel that keeps out non-POTS VoIP applications, and discourages new POTS entrants. And since there is (today) no defensible service element in "VoIP service" other than the trivial routing function, the erection of artificial barriers to enable rent-seeking is priority #1, #2 and #3 in telcoland.

The importance of phone numbers is too easily dismissed in a world of email addresses, Skype IDs and IM buddies. Numbers work across all alphabets and typefaces, are relatively unambiguous, are easily entered and displayed on restricted UIs, and can easily be conveyed verbally and in print. We have a system for mnemonic mapping to letters where necessary. Competing global numbering schemes are unlikely to emerge, because of potential for namespace confusion (although local versions such as SMS short codes do sprout up). Numbering is serious business, if somewhat obscure and technocratic. Despite their sometimes confusing split semantics as "naming" and "routing" objects, they need not be casually dismissed as an obsolete anachronism of the pre-IP world.

The technical problem any ENUM system solves is the conversion of a phone number to any other form of URL (and back again). The specific business problem that Carrier ENUM purports to solve is one of trust. If the user is empowered to create records in the routing table for IP communications, you face two problems. Does the user really own/control the ID that they are mapping from? And do they own the one that they are mapping to?

The puchase of the voice service acts as the "trust anchor" — if we gave you the phone number and VoIP URL, the mapping must be correct.

Yet in doing this Carrier ENUM denies you any possibility of asserting ownership over your phone number independently of purchasing an overpriced "voice service". It's a bit like you only being able to buy domain names in conjunction with getting an email account at AOL or MSN. If you happened to want to use your email address (think: "phone number") in some crazy new-fangled service like instant messaging (think: VoIP), you've got a problem. Oh, sure, you can do it in various numbering range ghettos that aren't routed by half the world (and are charged at random rates by the other half). It's like Microsoft's support for Apple — sure, we like competition, as long as it knows its place.

With domain names, I can obtain clear ownership. I get to set a record for my domain that says who I'm empowering to manage the domain's details for me. In other words, someone thought through the various roles of ownership, assignment, management, operation, etc. in advance. They made a reasonable stab at creating a system that separated them. With hindsight we know it's not perfect and involves excessive expense, but it's quite good.

What you would really like to be able to do is enter someone's phone number in Skype, call them, and if they're using a Skype-enabled device you get an ecrypted, wideband audio Skype call. But we can't do that easily today because I could claim to have your phone number, and calls to you would come to me.

I'm totally guessing, but I assume that the PhoneGnome device (which bridges PSTN and VoIP calling) has some patented secret provisioning sauce to tackle this problem. The device, I suppose, places a free PSTN out-call and uses caller ID to associate the SIP address and PSTN number. (Self-provisioning would allow you to fib too easily.) But it doesn't scale well unless we all buy one; and an $119 device is kind of expensive if all you want to do is prove you are the owner of a phone number so you can use it in an IP service like Skype.

Carrier ENUM makes me feel a bit queasy, because there's no need to be a "carrier" to do VoIP or ENUM. If the VoIP application is independent of transport, will I be able to declare myself to be a carrier, obtain numbers, and participate in Carrier ENUM? Methinks not, and that smells bad. (I also suspect Carrier ENUM is great for perpetuating the dependence on SIP proxies and smart networks a-la IMS, and preventing P2P connections. You can bet the technical rules will subtly stop any domestic IP connection from being classed as "carrier grade" and allowed to participate in Carrier ENUM as a peer.)

So is the only alternative the unattainable nirvana of User ENUM, where the plebs seize control? Not necessarily, but we could take some baby steps along the way.

If I were a regulator, I'd be looking to unbundle the phone number trust function.

Luckily, we've already got a model for it, at least in the UK. If you want to port your wholesale DSL line from one company to another, the requestor must receive an authorisation code issued by the incumbent. And the incumbent must authenticate the user when they request the code.

Break apart this mechanism, and it provides me a way of requesting codes, and third parties using them to authenticate my ownership, but without actually completing a number port.

This only works for the phone number ("E164 number" in telcospeak). If I wanted to map it to my Skype ID, I still need a similar mechanism to assert ownership of that ID. This strikes me as a problem easily solved with today's digital ID technology ;)

It would not be unreasonable for a "virtual VoIP network operator" like Skype to charge you for access to this trusted directory function. Particularly if the receipient was a POTS (or POTS-on-IP) competitior that wants to disintermediate the Skype network while still allowing the use of Skype IDs! (There's an business model struggling to emerge in every VoIP operator…) Given the near-zero barrier to market entry, let the market find a price, I say.

Since numbers are also de-provisioned and re-cycled, invalidating the truth of ownership, there needs to be a mechanism to publish these events. This is non-trivial. But even if we don't solve this problem at all, the system seems stronger than the contract-based alernative of DUNDi, where the user unilaterally asserts truth in identifier ownership, and post hoc regulation deals with miscreants. At least we got the records right up front, even if they age badly.

This solution may be a turkey. I've no idea. But there are plenty of other possibilities lined up. For example, I could port control of my number to Skype, but retain the actual voice service somewhere else. If DNS can separate out the ownership, registration and operation roles, so can numbering. Part of the problem is being presented with a false dichotomy of Carrier vs. User ENUM. Another part is ENUM accepts the legacy world of phone numbers on the carrier's terms - such as accepting only the management roles that existed in the old world. It may seem pragmatic now, but we'll regret it later as new features take decades to reach "numbered" devices via the numbering cartel.

A deeper part of the problem is the assumption that we want a single, monolothic POTS application — that calling any phone number should make a single device "ring" and be answered. The idea you would place a bell in your house and remotely allow anyone in the world to activate it day or night will seem truly quaint to our grandchildren. ENUM focuses tightly on legacy phone numbers and their messed-up meanings, rather than offering a general frameworks for inter-service interoperability. Is ENUM a good answer to a bad question?

Anyhow, let's disaggregate the functions behind the Carrier ENUM curtain. Let multiple domain-specific registries and directories emerge, re-combining the elements in new and useful ways. Let them be safe in the knowledge that the records in their directories have at least some kernel of truth to them. Let some competition into places that don't know what competition and innovation are.