The Rik Notes

OS X 10.7 Lion and User Conditioning

2011-07-21T10:45:00.000+01:00

Over on his blog, Faruk Ateş discusses user conditioning from the perspectives of Apple and Google. I encourage you to read his column as it has some very keen insights, but I feel the need to comment on his statement about the direction of scrolling content being muscle memory since time immemorial (i.e. the 80's):

People are used to their scrolling behaviors; after all, they’ve used them in one and only one way since the 80’s—or whenever they started using computers. It’s understandable that this complete reversal of (mental and physical) muscle memory doesn’t appeal to everyone.

I don't particularly agree with that powerful statement, for a couple of reasons. First, to talk about switching scrolling behaviors, one needs to look at when scrolling became touch-based rather than click-on-scroll-arrow-based. The idea of using the trackpad to scroll I think originated in the PC laptops where the right side (and bottom for horizontal scrollbars) of the trackpad was used as a scroll area. And that was certainly not done in the 80s.
There's also the mouse wheel scrolling, but I contend that a wheel is a physical impersonation of a scrollbar, so I'd be surprised if Apple expected mouse wheels to behave in an inverted fashion.
Anyway, my point here is that Apple didn't necessarily make such a massive change: it only fixed a mistake it introduced when it allowed for two-finger scrolling on the whole trackpad: Apple thought it was emulating the scroll bar movement, when in fact it should have realized that it was emulating the hand moving the content around.

I have for a long while been of the opinion that Apple is systematically fixing its interface behavior to move towards a unified model of virtual touch where anything physical will be made obsolete in favor of touch screens. Over a year ago, I was hoping to see soonish a MacBookPro with dual screens and running iOS.
Lion is slowly but surely moving towards this unified model where touching the virtual content is the cornerstone of the UI. Apple made a direction mistake a few years ago when it introduced "two finger scrolling". Had it known it was making "two finger virtual touch" at the time, I am certain it would have gotten the direction right. That's the extent of Apple's change.

The real user conditioning change is from using physical intermediaries to act on pixels vs. using your hands. And in 5 years' time, no adolescent will ever understand why we were sliding our fingers down to go down.

More on identity

2011-03-05T08:31:00.001Z

Dave Winer wrote a blog post titled Using DNS as a thin ID system . I encourage you to go read it, but in essence his main gripe is that the current means of identifying a person online are too complicated.
And I agree, but with a caveat: there is clearly a need for a simple identification system, while the need for (and current existence of) more complex ID systems is also there.

Winer postulates that the DNS could be used for the simple ID system. Let's call it SID for short. Here again I have to agree he's on to something, since when we designed the .tel top level domain, that was a primary goal.
However, with .tel we started by the complicated stuff, implementing all the current stuff like OpenID et. al., and also implementing a unique, original encryption system for sharing private information inside the DNS zone itself.
So now in the spirit of bootstrapping and getting something up quickly, here's my implementation of Winer's SID:

http://passw0rd.henri.tel

Here's how it works:

Assume you don't know the above URL
I go to your site and want to authenticate myself
you ask me for my domain name (henri.tel) and password (passw0rd)
you look up password.domain
if you look up using DNS and it returns NXDOMAIN, then authentication failed
if you look up using HTTP and it returns 404, then authentication failed

That's about it.

Oh, one more thing: inside passw0rd.henri.tel there are a number of interesting records of type NAPTR that point to my different web properties. There are also TXT records that define my name and current work. If you're looking it up via HTTP, you'll get that info in the hCard of the resulting page.

All of this, today, is available to any .tel owner, without any need for knowledge of DNS or anything beyond knowing to uncheck the "create a link" box in the below screen:

That's all there is to it.

Now the purists will say that this identification system lacks much more than it provides. I agree. If you want OpenID, my henri.tel domain is an OpenID provider as well.

But here, we're looking for a dead simple way of knowing that the person is the same person who came last week. We don't want more than that, and I think Winer's SID is something worth trying out, especially since it's pretty much universally applicable across all top level domains. (I would only use domains, because they give you good legal control in case someone tries to impersonate you, etc...)

Connecting More: People and things

2010-11-09T11:18:00.001Z

We're at a cusp of a new phase of the Internet, where an extremely large set of non-computers are going to be nodes in this vast network. Those new entities will be people having their own real estate (i.e. domains), and devices that have just enough electronics to communicate in there.
I've got a post with Justin Hayward on the Telnic Blog talking about this "Internet of Things", and how the first step is necessarily discoverability: how a newly arrived node says "hello, I'm here and that's what I can give you."
I can't wait for my garden sensors to tell me that this area of the lawn is too wet and the water isn't filtering down, before the lawn turns yellow and exceedingly ugly (true story).

And another step towards iOS on Macs

2010-07-27T14:55:00.000+01:00

Apple just released a multitouch trackpad for your macs.
This is yet another step towards replacing OS X with iOS, as I was describing in my June post entitled "The never-ending Apple Revolution".
I for one am looking forward to that new generation of operating systems being ubiquitous.

iPhone 4 light apps

2010-07-21T16:56:00.002+01:00

There are at least 50 iPhone 4 light apps now, which have one or more of the following features: turn on/off the torchlight on the back of the phone, and strobe the torchlight.
That's it. Half of those apps cost $0.99, and probably most of the rest have ads enabled.

I thought it was pretty stupid, and I was also told the apps are slow to start up. One of them takes 5 seconds just to load up. So I felt the need to write in 2 hours a light app with strobing, including separate controls for light/dark timings of the strobe. Kind of fun. The app loads in less than 2 seconds and is well under 100kB.

If you want the source code, just let me know.
Update: I've just submitted the app to the AppStore, called "☼ Flashlight ☼"
Update 2: It's available on the app store.
Please leave a comment here in this post if you have issues or suggestions with the app. Thanks.

The "light" app in all its glory

The never-ending Apple Revolution

2010-06-08T10:23:00.000+01:00

Steve Jobs just announced the iPhone 4, with a slew of new features and his usual hyperbole. But let's stay clear of discussing the hyperbole, which Apple fans and foes alike love to argue upon. Just the facts ma'am, and here are some hard ones.

Fact: iPhone 4 is extremely powerful, using the A4 system-on-a-chip that's also in the iPad, even though we don't know if it'll run at the same speed. Nonetheless, it's so powerful that it has literally clearly transformed the smartphone into a multipurpose handheld computer replacement: 720p hi-dev video camera, book reader on a screen with the quality of printed paper, music and video player, games machine, etc...

Fact: iPhone 4 has a front-facing camera. That's nothing new hardware-wise, but this time it comes with software that makes video-calling straightforward. Watch the operators scramble once again to increase their bandwidths.

Fact: iPhoneOS is now officially iOS (not to be confused with Cisco's IOS). It has grown up from its toddler years into adolescence: solid APIs, proven UI paradigms, runs on multiple devices, supports heavy-duty gaming and all manners of application types.

If you now ask why I consider iOS to be an adolescent, and when I'll see it grow to adulthood, my answer is simply the day you'll see Apple computers ship with iOS. It is my firm belief that Apple's iOS is its next-generation operating system across all devices, from laptops to servers and AppleTV. Think about MacBooks with dual screens, the keyboard area being replaced by a second haptic screen. The "laptop" can then be turned sideways into a "book" with two pages when you're running an ebook reader. And of course the MacBook can be sold as-is in every country in the world, no keyboard layout issues. Think about the cost savings.

Incidentally, I only keep my MacBook Pro because I can't yet run XCode to program iOS apps on the iPad. The day XCode runs on the iPad (or the iPhone+screen+bluetooth keyboard), I will never again need my trusty battered OS X 10.6 MacBook Pro.

That, ladies and gentlemen, is the NeXT Step. Soon.
In the meantime, enjoy the music, book, video, mobile phone and gaming revolutions that the wizard Mr. Jobs has thrust upon us in the past decade.

Enough with DRM already!

2010-06-02T12:33:00.000+01:00

Ars Technica (a great publication, in case you didn't know of it) has an article about the problems plaguing eBooks: No universal format, fight over DRM, etc...

If you read the comments section, there are only two universally acclaimed places from which to buy books online: Baen (webscriptions.net) and O'Reilly. And guess what they have in common? Absolutely ZERO DRM and therefore the ability to provide the books in a multitude of formats, including the ubiquitous PDF.

Personally I've been buying and reading books from Baen on my iPhone and computers for 2 years now, and it and O'Reilly are the absolute only two places I buy books from. It's easy, prices are good, and I never have to worry about which device I'm reading the book on.

DRM must go. Check out the author Eric Flint's introduction to the newly-created Baen Free Library in the year 2000, and then his followup rant on DRM in 2006. Publishers and authors have been getting this kind of market research continuously for 10 years now, and they still don't get it. Looks like books are going the way of music, movies and video games (Ubisoft, I'm looking at you): how to best shoot oneself in the foot by screwing the customer.

On the need for basic statistics training

2010-06-01T13:06:00.000+01:00

These days anyone will do anything for a bit of exposure, for search engine positioning or otherwise. And sometimes it borders on the idiotic (well, in some cases it truly is Jackass-level idiotic, but that would be on purpose).

Here's the latest beautiful example that I was just given, courtesy of Business Insider: CHART OF THE DAY: Here's Why The Mobile Ad Market Is Still Small

This report on a survey, and accompanying chart, attempts to convince us that the mobile ad market is small and very few people research or purchase products on their cell phones. Sure, the basic idea that weekly only 8% of people research products on their cell phones may be correct. I don't dispute that.

But if I were to say that 32% of all smartphone owners research products weekly on their smartphones, which by the way, are geared to receiving high-quality mobile ads, wouldn't you rethink the conclusion?
Furthermore, while only an assumed 25% of all mobile phone owners today have smartphones, the smartphone share is exploding and therefore so will the mobile ad market.

Lies, damned lies, and statistics

Why I too 'deleted' my Facebook account

2010-05-03T10:50:00.002+01:00

Some weeks ago I pulled the plug on my Facebook account, that I'd had since the days when Facebook required a ".edu" email address. Yes, that was a very long time ago in Internet Years, and no I wasn't in school at the time but thanks to my UPenn lifetime email I was able to get in and see what this new social network was about.

Today I just cannot justify being on Facebook. All my working life I've fought against complexity and interdependence, and many of those at the receiving end of my emails know that I fancy an Alan Perlis quote that goes:

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

And today, Facebook has become such a tangled mess of relationships that:

it's impossible to understand how why you're shown something
it's impossible to control the flow of your information
it's impossible to handle your privacy with any confidence
it's impossible to know where Facebook will stop this cancerous growth

No thanks, goodbye Facebook. Back to basics, to simple and controlled interconnections. Anything else yields an abyss of unending wasted time and resources, and dangerous consequences. It's just not worth it

I'm still here

2010-02-24T14:52:00.001Z

Just in case you were wondering, yes I'm still here.
My.tel 2.0 is out on the iPhone app store. We're busy rolling out a new version of the TelProxy, and I need to update both My.tel and Superbook again. So many new features, so little time.

Emerging

2010-01-14T19:30:00.000Z

Okay it's been a while, I'm now emerging back from a stretch of intense work.
My.tel 2.0, the iPhone app for managing your .tel domains, is in beta and almost done. Also TelPages is being tested, especially for its algorithms, and I'm quite happy with the first iteration.
All in all, work is progressing well.

Blogger frustrations

2009-10-27T20:59:00.000Z

Gah, Blogger is very frustrating in regards to formatting posts. I had to edit the previous post a dozen times to make it look decent because I had copy-pasted some text from an external site that used tables.
Even after removing all the html code I could barely make it work.
I think Blogger is another failure of Google where it just is leaving it to die a slow death. Why did Google buy Blogger anyway?

Dumbing down

2009-10-27T20:46:00.006Z

I just stumbled upon a blog post I wrote 5 years ago, at 3 in the morning, bemoaning the state of computer games. I'm reprinting it here because it made me realize that the situation has gotten significantly better in 2009, with many developers re-learning that gamers might just have a decent IQ.

Dumbing the game down
Posted at Sep 29, 2004 3:04AM PST
Are gamers considered to be a negatively evolving species? Why are we now only given "cinematic experience", or only faster action? Are we supposed to simply regress back to better reflexes? Or become fatter couch potatoes as we see longer and nicer cut-scenes? What happened to long involving storylines? Where's the intelligence factor gone?
Download Ultima V and play it on the emulator of your choice. That was a real game. Something worth playing, where you as a gamer were respected by the developers as an intellectual peer, not just as a wallet or fast fingers.
I am so happy that we have emulators of old systems. Maybe that will teach the next generation of game developers how to write games. The current one seems to have forgotten.

My quick reviews
Posted at Sep 29, 2004 3:18AM PST
Call of Duty: Beautiful cinematics, but scripted to death and ultimately simply a nice very long movie.
Far Cry: Could have been great, they messed it up by including monsters. Developers: We are sick of monsters. Give us real regular people and make the story not need monsters! You can do it, come on.
Deus Ex 2: Too simple, catering to 10-year-olds. There wasn't one challenging piece, even though the story was better than average. The original Deus Ex was targetting older gamers, in my opinion.
Splinter Cell: An exercise in frustration because it's so precise and scripted. It turns into a game of guessing how the developer wants you to move around the dimly lit room.
X2: Good, but its scope is a little too large with not enough differentiation. It has great potential with a few mods.
Sacred: Very pretty hack-and-slash, better than Diablo 2 except that unique items aren't varied enough, and there are still frustrating bugs at version 1.66. Version 1.7 supposedly fixes them. But the storyline is good, and the world is very large.

.tel management app for iPhone: My.tel version 2

2009-10-22T15:54:00.000+01:00

It's high time I updated the My.tel iPhone app for managing .tel domains.
I've been working on it heavily in the past couple of weeks, and it's shaping up well. I still have a lot of work to do (especially graphics work) but I've already achieved most of my goals. In fact, version 2 is going to be so powerful that I'm worried regular .tel owners will not want that kind of app. I'll probably publish a 'lite' and a 'pro' version.
Among the new features:

support for multiple .tel accounts at multiple registrars (in process)
support for domain display title (done)
much more intuitive profile handling (done)
native Google Maps instead of OpenStreetMaps (done)
rewritten keywords section (in process)
support for the latest record types (done)
profile renaming (done)
subdomain renaming (in progress)

That's about what I can remember off the top of my head. Feel free to comment and ask for other features. I can't promise anything, but you may get lucky.

Note that this will be for iPhone OS 3.0 and above unfortunately, due to a number of reasons including Google Maps support and certain other functions.

Mobile Advertising

2009-10-01T14:52:00.001+01:00

Considering that mobile handsets are quite probably over 4 billion today, v.s. computers at 800 million pieces, mobile advertising is something of a hot potato.

But mobile advertising is much trickier than regular Web advertising for a number of reasons, most notably:

- Not all mobiles have data access
Mobiles that don't have GPRS/EDGE/3G are restricted to phone and SMS.

- Extremely varied screen sizes
Some motorola handsets have screens of 128x160 pixels. The iPhone has a touchscreen of 320x480 pixels. And there's all sorts of sizes in between and outside that range.

- Random Web support
It is so difficult to know how (if at all) the handsets will display web pages that the .mobi registry has created a specific product called Device Atlas to help developers understand the features and limitations of each device.

- Cost and speed of data access
There are now more and more "all-you-can-eat" data plans thanks to the advent of the iPhone, but this is by no means the majority. Furthermore, roaming data access remains prohibitively expensive. On a recent trip to Canada, over a period of 6 days with relatively little roaming data access, I managed to accrue a Euro 450 bill on my French SFR mobile. Talk about forgetting to acquire a local SIM card and switch my .tel domain to it (I won't make that mistake again)! Also speed is a concern, even with the latest 3G technologies that favor larger files over smaller ones: the cost of initiating a connection is high, which will happen for every ad.

A new paradigm

As we were designing the specifications for advertising on .tel domains, we decided from the start that one of the requirements would be that ads should be available directly inside the domain itself, and not just as an add-on to the web interface. Doing so would allow any native application the ability to display those ads without resorting to HTTP requests.

Beyond the obvious efficiencies in a small and fast DNS query, an additional benefit of storing the ads in the DNS (or providing a DNS interface to an ad server) is that the ads are structured data, much like an XML API for ads. So you can easily determine how you wish to display them in a native application, removing all issues of matching advert size to handset screen size at the server level.

An ad in some.domain.tel domains is a TXT record, generally stored in _ad.some.domain.tel, with the following structure:

TXT ".tad" "Version" "DisplayPreference" "Preference" "Title" "Label" "URI" "Description"

where "URI" and "Description" can be multiple consecutive key/value pairs, ensuring that both can be as long as necessary.
Specific information can be found in the full spec for ad serving in a .tel domain.

I am looking forward to seeing ad servers implement a DNS interface to their ads, and in the process making them even more suited to mobile applications of any type.

RSSCloud

2009-09-21T07:45:00.002+01:00

(The below post is relatively technical)

Over at Dave Winer's scripting.com blog there's work being done to determine how to best discover RSS feeds and keep them up-to-date.

Mr. Winer has defined a solution which consists of the following:

- Create a web service with an HTTP-to-DNS API
- Use the above to enter in a unique subdomain a TXT record into a whose sole string is the url for the feed
- Also create an HTTP proxy service that exposes the TXT record to a web browser, when such browser is requests the subdomain

This works, except that TXT records are definitely sub-optimal for this. One should use other types of records more suitable for this, such as NAPTR records. Furthermore, if you have a .tel domain, whether the final implementation uses TXT or NAPTR records, you're already in great shape because you've already got all the tools necessary to support this.

Regarding TXT vs. NAPTR, I suggest using NAPTR records of type 'x-rss' (and also 'x-opml') such that a DNS query to (for example) rss.asseily.tel will look like this:

100 100 "u" "E2U+x-rss:http" "!^.*$!http://rikkles.blogspot.com/feeds/posts/default!" .

The DNS query to get the above is:

dig +short rss.asseily.tel naptr

A NAPTR record has the following advantages over a TXT record:

- It's got an enumservice type ('x-rss:http') which allows clients to understand what it is ('x-rss') and how to access it ('http'). TXT records don't have any of that, which can lead to much confusion unless you structure them accordingly (i.e. have multiple strings, the first one being the type).

- It's got an order and a preference (both 100 in the above case), which allows you to specify multiple ordered URLs for the same feed, and allows you to have multiple feeds in the same subdomain: each unique feed has the same unique order number, and for each unique feed you can have multiple urls ordered by preference. Note that I didn't invent this usage, it's standard for NAPTR records

- The URL that you see in the NAPTR record is actually called a 'replacement', because that's what it is. It 'replaces' the request made, and is in fact a fully qualified regular expression. In the above case, we're saying "please replace the whole query with 'http://rikkles.blogspot.com/feeds/posts/default'. The actual request made was for 'rss.asseily.tel'. That request is now replaced with the give URL. Because this is a regular expression, you could have been a lot more specific with the replacement if you wanted to

Since I'm using a .tel domain, I've got access to an API. The PHP code to create this RSS entry in the DNS is below:

include('Telhosting_Client.php');

$naptr1 = array(
'order' => '100',
'preference' => '100',
'services' => 'E2U+x-rss:http',
'flags' => 'u',
'regexp' => '!^.*$!http://rikkles.blogspot.com/feeds/posts/default!',
'owner' => '@',
'profiles' => '_all_',
);

$config = array();
$config['login'] = '****';
$config['password'] = '****';
$config['wsdl'] = 'my.wsdl';
$domain = 'rss.asseily.tel';

$client = new Telhosting_client($config);
$client->store_record($domain, 'naptr', $naptr1);

Can't be much simpler than that...

Apologies to my iPhone users

2009-09-04T05:54:00.003+01:00

Well I'd like to apologize to the users of my iPhone apps, My.tel and Superbook.
I know that there's a critical crashing bug in My.tel version 1.0.1 as it currently stands on the app store. I'm sorry that I missed that bug when testing the app. It triggers when you're updating a contact record and change its type (say from "Skype IM" to "Skype Voice").
As soon as I was told of the crash, I fixed it. It's a simple 3-line change. I re-uploaded a new version, 1.0.2, to the app store right away. At that time Apple added a new feature when uploading apps, called "Keywords". You can now add keywords to your apps for better searching on the app store (that's assuming search works properly, but it doesn't). Well, I added a few keywords like ".tel, telnic, unified messaging, AIM, Skype". Things that I thought were relevant.

Fast forward to today, which is 21 days after I submitted my 3-line change. The app still isn't approved. Of course I had zero feedback from Apple. I sent emails, and I know that some of my users sent emails as well. So now I have to figure out why in the nine hells it's taking so long, without any feedback. Welcome to the world of the Apple AppStore.

I also have a big update to Superbook will a bunch of new features that's also in limbo. That one has been lingering for over two weeks. So I decided today to reject my uploaded binaries, get rid of the keywords, and re-upload them. This also reset the clock for approval time, so in the best of cases, it will have been one month to get a 3-line change through the Apple process.

Lovely.

Sorry my dear users, but all I can say is "it's out of my hands".

Update sept 5 2009: Less than 24 hours after I wiped the keywords and resubmitted a new binary, Apple approved My.tel. But Superbook is still in the process.

Moral of the story: Don't even try to guess what Apple is doing, I don't think Apple even knows itself.

Idiot's guide to Webfinger and .tel

2009-08-17T12:23:00.004+01:00

Webfinger:

.tel:

At the cusp of contact info convergence

2009-08-15T15:26:00.003+01:00

We're finally getting there: convergence of social networks, users worried about losing their social connections, and innovators looking to provide a proper continuity and contact info stability.

Let's look at what has just happened, and feel the uncertainty in the communications market:
Facebook acquires Friendfeed. Yet another communications channel has emerged and been subsumed. Scoble believes that Friendfeed is dead and is (rightly) worried about what will happen about his Friendfeed social graph.

tr.im the URL shortener has been shuttered and resuscitated after its community showed its support. URL shorteners started as transient solutions but are now an integral part of the persistent Internet content. (Note that I'm not saying "Web content" because there's a lot of content not just on the Web)

There's too much excitement with flashy technologies and not enough focus on some cold hard truths; flashes are in the pan. Facebook has 250 million users yes, but it's not the world's biggest social network; Skype is, with over 450 million registered users, and a very very healthy cash flow - they've monetized it. But not everyone wants to be on Facebook (and the kids are leaving because their parents are on it and it's 'boring'!) nor does everyone want to be in the other proprietary place that is Skype.

So, what do users want? It's simple: they want people to be able to know, at any time, where and how to find them. Essentially: easy discovery of the user's current communication channels.

There needs to be some kind of universal identifier that people can choose to have that allows them to swap in and out different services as they come and go, and big business is flailing around to find and own it. But it does exist already: .tel

There are other solutions being developed of course:
Open Trust Networks are being potentially mooted as the way to go to base ID systems on, but they have to be vendor-independent in order to provide that level of trust for the individual. Ideally, they need to be run as a distributed system rather than a centralized one. That's where the ownership of a domain by an individual which stores information in the DNS works.

Dave Winer is absolutely correct when he states that trading one centralized system for another is no good: it's inherently insecure, provides a bottleneck and a target, and ultimately doesn't give the user his freedom. However, using the DNS enables the load to be spread in a time-proven manner. His idea moves on to give a user a unique URL, but if it is reliant on a centralized system to serve it, the person still doesn't have control over their data and the service provided. If however one uses the DNS as the main entry point, it gives ultimate control to the owner of the DNS zone, i.e. the domain owner.

There's also the new Google Webfinger concept that misses the point completely. What does it ultimately try to do? Provide contact info for a person given an identifier. Well, first of all, revealing an email address as an identifier is people's worst nightmare. Second, it's horribly complicated for no reason whatsoever:
With an email address, you somehow determine how to hit the DNS, which then tells you where to find the XRD file that, once downloaded and parsed, gives you the contact data.
Why not simply finally accept the fact that the best identifier that can ever be defined is a domain name? If you want to get my contact data, simply hit the DNS for henri.tel, the contact data is all there. Here's how my henri.tel DNS contact info looks like. And if you believe that an XRD file can provide more complex data structures than what the DNS records can, put a link to the XRD file directly in the domain itself.
The only reason to start with anything not a domain is to avoid paying the domain ownership fee. But then you lose your freedom. About $1/month is the price of freedom.
Also note that you can do this with any domain, not just .tel. A .tel domain simply has a guaranteed structure that makes all this very simple, and it also gives you the management tools, APIs and privacy for free.

Domains are good. Domains can be purchased. Domains can be owned. Domains can be used to point to anything of importance to the domain owner. Read up on what you can do with the DNS, you'd be surprised.

Commenting on an SEM Clubhouse post

2009-08-12T10:20:00.004+01:00

There's a good discussion about .tel and hCard on the SEM Clubhouse blog. I am responding here because its comments section doesn't allow basic formatting for clarity.

Silver in comment #4 says:

it’s not at all clear to me why a “single universal personal identifier for multiple communication services” could not be their existing website.

Why not an existing website? Well assuming you're using standardized formats so the info can be correctly parsed, why not? Except of course that using http + parsing hCard or other formats is incredibly slower than doing a .tel DNS lookup. Plus, you need the skills so you don't make a mistake in publishing your data. And finally, you need to have a website already. Believe it or not, there are as many companies without websites as companies with. If I'm a window cleaner, plumber, dentist or doctor, why do I need a website? I need a Presence Online, I need to Market Myself, I need to Be Found and Contacted, but I don't need to waste money and time building a website.
Furthermore, even if I do have a website, updating my contact info when it changes can be a chore. If I also have a .tel, I can dynamically pull the .tel info and display it on my website, and use the .tel as an easily updated dynamic data store for contact info.

A simpler way of looking at this is to state that .tel is a business tool.

Regarding:

you need a site, you need to pay for it, and you need a means of updating it

Those are not dependencies for the .tel beyond paying the yearly domain fee (which you also have to pay with your own domain). You do not pay site hosting and other hidden fees, you do not build a site, and you have all sorts of means of updating it, from a standard web interface to complete APIs or even uploading excel spreadsheets.

Also I think you're missing the core point that .tel is (once again) not a website. You're saying:

I’m pleased to hear that .TEL may incorporate microformatting in the future! It definitely makes sense if you want to facilitate machine-readable contact info.

.tel is absolutely the easiest machine-readable contact info system there is! All .tel contact info is stored as structured DNS records. Simply make a DNS query to a .tel domain, asking for the contact records, and you've got them right there. They need minimal parsing, and probably about 100 times less resources than grabbing the data from an hCard. Navigation at the speed of DNS is something to be appreciated. :)

To go back to Yellow Pages directories: they're not competitors to .tel. They'll gladly grab your .tel info to populate their directories, it'll save them quite a few headaches and will make their offering more valuable. It's only that currently SIP and other communication channels are short-changed because of the difficulty of modifying the underlying infrastructures of the major YP providers.

Finally, let me answer your last question:

The privacy feature is the least clear selling point about .TEL. I’m by no means ignorant about privacy issues, but it’s unclear to me how .TEL helps those, and why that those of us who want to make our contact info more readily findable should simultaneously want to keep it private?

To start with, there's a comprehensive .tel Privacy document. You certainly want your contact information readily findable, but are you sure you want all your info findable by everyone? Probably not. You may want to keep that cell phone number of yours private and only give it to a couple of close friends. In order to do that, Telnic has developed a privacy model comprised of encryption specifications and an optional centralized friending system implementation. I've described the implementation in another blog post of mine, Privacy in .tel.

Here's a final thought for you:
Imagine you want to dial a number, but instead dial a name. This is .tel. The name resolves to a number (or many) and the call is made. It's just like typing and name in the browser address bar and it resolving to an IP address. We're in the 21st century. 15 years ago we stopped remembering IP addresses. Why do we still need to remember phone numbers?

Henri.

PS: The .tel-to-vCard mapping info is here.

Google SEO and .tel, again

2009-08-01T17:02:00.003+01:00

I've had again a number of questions regarding Google SEO and why Google isn't showing certain .tel domains high enough (or, why they dropped dramatically in rankings). Google hasn't changed its indexing or ranking behavior on .tel domains, and similarly, .tel domains (as any others) must abide by the standard Google rules.

In general, domains get dropped in rankings for one of a few reasons:
1- duplicate content
2- duplicate content
3- duplicate content

As Google says: "Don't create multiple pages, subdomains, or domains with substantially duplicate content."
What is duplicate content? Google has a full page explaining it at http://www.google.com/support/webmasters/bin/answer.py?answer=66359.
Google despises duplicate content and states: "in some cases, content is deliberately duplicated across domains in an attempt to manipulate search engine rankings or win more traffic. Deceptive practices like this can result in a poor user experience, when a visitor sees substantially the same content repeated within a set of search results."

You MUST either get rid of the duplicate .tels or find a reason to put different content in these different domains. Can you find something unique so the information is different in each .tel? If not, then Google will think you're spamming its index with much of the same.

If you choose to write different content for each of your .tel, I suggest you still choose one "main" .tel that you're going to put most of your link power on. Take a well-indexed domain of yours on Google, and create a link from there to your main .tel, which will help it go up in the rankings.

But again, long story short, never ever duplicate content across sites (whether .com or .tel) or Google will dramatically penalize you.

Why .tel and not a free hcard microformat?

2009-07-08T02:49:00.003+01:00

I was asked on Twitter by @nambor why .tel couldn't be replaced for free by an hcard microformat on your domain (see the tweet here.
Well, let's look at the problem at hand, namely: how can I access your latest contact info when I need it to communicate with you?
That is the fundamental problem that .tel and many others want to solve. And solving it is possible, but a number of prerequisites are necessary:

1. Your contact info needs to be always accessible
So you need to put it somewhere I can get to, which means on the Internet. And it needs to always be in the same place, which means that you can't rely on 3rd parties. You need your own domain.

2. Your contact info needs to be understandable by my dialer program
It's got to be in a standard published format.

3. Your contact info needs to be up-to-date
You've got to be able to quickly and easily update it.

4. Your contact info needs to be protected with strong privacy settings
You probably won't want to give your mobile number to anyone. Therefore you need some kind of identification of incoming requests, and a strong privacy layer on top.

Storing an hcard microformat html document on your website solves point #1 assuming you've got your own domain and website. Incidentally, not having your domain means that you're at the mercy of a 3rd party who might cut you off due to it failing or raising prices to unacceptable levels, which would force you to change the location of your hcard, thus breaking the "always accessible" rule.

The hcard is a good standard and sloves point #2, but for #3 and #4 you'd need to build your own update and privacy infrastructures. While updating an hcard on your domain on the move could be done with some work, a proper privacy layer that doesn't break standards (point #2) and is easily accessible (point #1) is very hard work.

So let's recap the hcard solution: you need to pay for your domain (any .com or equivalent will do) and a website, you need a means to easily update your hcard even when on the move, and you need a custom-built privacy infrastructure that you hope will be accepted.

Well, for about $1/month and a 5 minute setup, anyone can have a .tel that will do all of the above and much more. You don't need another domain, you don't need to build anything, and you've got free apps for all major mobile phones and Outlook. Oh, and you can have your vcard for free too (we'll add in hcard if it's requested by the .tel community).

Restrictions as a positive enabler

2009-05-30T18:01:00.002+01:00

I haven't updated this blog in a while, I was extremely busy (and still am) with all the software releases for .tel. The app Superbook is out on the iPhone app store (at superbook.tel) among many other things.

However, I took the time today to write a post on the Namepros forums to point out that one could easily fall into the trap of thinking "all .tel domains are the same" because of the obvious similarity in their form when viewed through the web. Here's most of my post calling for lifting restrictions on showcasing .tel domains on Namepros, edited for readability on this blog:

You could easily fall in the trap of viewing development restrictions on .tel domains as being a negative point. But then you'd be looking at .tel from the viewpoint of someone building a website where form and function are driven by the restrictions of http+html. You've been operating within them for so long that you've learned not to get close to the boundaries. Hence, you don't see them. Nevertheless, they exist.

Requesting a web page is costly in time and resources. So you work on mobile-optimised versions as well as regular "heavy" versions. Similarly, because creating a single page is hard work, you try to make as few pages as possible. For both reasons, you rely on search rather than navigation.

Making any kind of data-driven site means "dynamic" website, which entails scripting and database backend, and therefore expertise in both (or passing knowledge, which results in a very average user experience).

And let's not discuss multi-dimensional visualization, which automatically means Flash, Java or some kind of 3D language.
And you can only convey text, not language inflexions. Well you can add an audio file, but that's pretty horrible. Then again you can switch to a podcast which is nothing like a web page. You can't even write the text you want, you're stuck with standard fonts. Which is partly why comic book artists scan their strips.

Now let's get to the subject at hand, .tel. With .tel, the form is set. You have two choices: fight it or be happy that you don't have to worry about it. If you're in the first camp, no problem, get any other domain (.com, .biz, etc...). If you're in the second camp, then we can start talking about the benefits of the form being set, and ultimately about the nature of .tel.

Which brings me to the real question that's at the root of the discussion: what are .tel domain builders?

The answer is really simple : Data architects. Librarians. Navigation interface designers. In more mathematical terms, graph creators.

And that is why thinking all .tel domains are the same can hit such a raw nerve. Telsters aren't showcasing their HTML-fu, they're showcasing their graph building knowledge. Yes, the current overwhelming majority of .tel domains contains very simple graphs, but that is why showcasing .tels is so important: learn from your peers. I don't think anyone on the Namepros forum is a librarian by training (please do correct me if I'm wrong!), but they're clearly eager to learn.

Beyond small business owners quickly understanding the value of owning a .tel filled with their contact info, a domainer who wants to build value in a .tel will view it as an incredibly easy-to-use, fast and efficient data source for contact and short textual info.

Think about building mobile apps where the only necessary data source is the DNS. That is of course what the iPhone app Superbook is about, or the TelProxy web application. But you could as well have a navigable compendium of all plant species in the Amazonian Forest, with web link cross references, image links to flickr photo albums, or IRC pointers to live discussions on how to best extract sap from a rubber tree. Without ever writing a single line of code.

Thanks for reading,
Henri

PS: The original post is here

Search and proxy stats

2009-04-26T21:42:00.002+01:00

I'm working on a new search engine algorithm for searching .tel domains. It'll be rather unique and innovative. I don't think anyone has done it quite this way before. And I'm not forgetting the UI interface for gathering proxy statistics for the many of you who own .tel domains. It's coming.

promoting.tel

2009-04-20T14:42:00.003+01:00

Mark just sent me this cool example of his on how to set up a .tel with user-generated content:
promoting.tel

Check it out. One more example of what a .tel is: a personal, persistent and dynamic online contact data store.

The My.tel iPhone app is available

2009-04-17T09:53:00.003+01:00

The free My.tel iPhone app is now available on the app store:
The My.tel iPhone app

You can use it to manage your .tel directly from your phone. My.tel frees you from using web-based tools to manage your .tel domains. Update your .tel domain before boarding a plane, on a road trip, or just to tell your friends which bar you're in.

Features:
- Publish your location with an embedded map
- Update your status
- Add, remove, hide or show contact information
- Add or remove folders and profiles
- Manage privacy settings
- Add or remove keywords

Also, as promised, the entire source code for the application is on the dev.telnic.org site.

Here's the svn browser direct link.

Enjoy, and please post a review of the app if you download it.

Navigation at the speed of DNS

2009-04-07T22:57:00.003+01:00

We've been talking quite a bit about the speed of the DNS, and how .tel will make you rethink navigation.
A picture is worth a thousand words, and a movie worth 30 pictures a second. So here you go, my native .tel iPhone app called "Superbook" in action:

The app is currently being reviewed by Apple.
Enjoy.

Response to shkspr.mobi

2009-04-02T09:39:00.002+01:00

Fun blog post that I read with interest, from someone working for Vodafone: http://shkspr.mobi/blog/2009/03/some-thoughts-on-tel.html

Here are my thoughts, Terence:

I’m glad you won a free .tel domain and have had the chance to quickly and simply populate it, without developing or hosting a website. As you say, a completely different domain. But then you state:

.tel is yet another top level domain to go with all those other highly (/profitable/) popular ones. You know, like .biz, .museum, .info, etc.

I love that play on profitable/popular (in the original post, "profitable has a strikethrough), especially since .tel was designed so that it would be totally different from any other TLD: no websites, and therefore no parking pages, no ads, no redirects, no popup, popunders or malware. That was pretty clearly understood by the domainer community, whose more entrepreneurial members are building new revenue models based on communications services.

Now you think a conversation will go like this:
"Visit aitch-tee-tee-pee colon slash-slash edent dot tell... No... Tell. It's spelled TEA-EE-EL. Yes. Just one EL. No, I don't know why. Here, let me write it down for you on a little cardboard oblong..."

Here's how the real conversation goes, as I've had it happen at least a hundred times already with my domain that I've had for over a year:
"Contact me on henri.tel"
"Oh? on the web?"
"sure. everything's there. phone, email, skype.."
"great, thanks"

And then the inevitable happens when I get an email from those people:
"I love your henri.tel! so simple! Where can I get mine?"

Now compare that to:
"Got a pen? write down my number: 1-202-5551212"
"and what's your email?"
"oah yes, it's xxx@vodafone.com. With an f, not a p-h"

Finally, you wonder about why it's so plain:

First of all, why not take a look at the site. edent.tel... [Snipped a whole discussion about how ugly it looks]... no panache, no style. Just dull dull dull text.

In your opinion it's dull. I guess that’s because you work for a mobile telecommunications company that wants people to spend lots of money downloading content over your mobile internet. Dull in this case means cheap, quick and accessible. Usability does not mean whizzy, colourful, mesmerizing – it means functional. When I want to contact you, I don't care about pretty pictures. I want to click-call as quickly as possible.
Sure I could have your info in my address book, but I'll never know if it's the right info. Getting it really fast from the Net is the way to do it. You can cache it (except for the iPhone not understanding vCard, but with a native app there's no problem), but that would be your choice.

Speaking of "pretty", the website you went to is simply a basic interface to the actual data stored in the DNS. You do not need the website to get to the data. A number of applications already understand .tel domains and go straight to the DNS to grab the data, making the whole idea of "pretty" totally moot. Your .tel is a personal, distributed and privacy-enabled datastore for your contact information. Not a website. Any connected device can read that datastore (because they read DNS) and display it any which way it wants. The website is just a convenience. A simple, quick and standardized convenience. In fact, you do not want the web if you can avoid it. It's slow and inefficient. Using one of the plug-ins for Blackberry or Outlook for example, they pop .tel data in your address book and cache it intelligently, and there's no need to download a static VCard that will get obsolete.

One thing you will have spotted however if you’ve done your research rather than a quick on-spec is that we listen to our users. We’ve tweaked and continue to tweak the interfaces for the web browsers. But because you’re sucking information from the DNS into a proxy page, this isn’t the be-all and end-all. We’ll continue to listen, even to members of the community who have guest passes and didn’t pay their money – including you Terence! Thank you for taking the time to put your thoughts down and I hope you appreciate we read everything and try to respond where we can.

One more point I’d like to make in your comparison. SyncML depends 100% on having supported phones. What if I'm in front of a computer and I have my office phone? Or Skype? or a softphone (like Kiax for example http://sourceforge.net/projects/kiax). The idea of a universal point of contact works when you've got the following features:

- ubiquitous access
- very fast
- very cheap if not free
- easily updated
- owned by you so that you're independent of any service providers

That is what ZYB can never be, and that is what .tel is. However, with an account on ZYB, you could easily update your .tel and sync to ZYB or vice versa. Use ZYB to push the SyncML data to who you want, but edent.tel is significantly lower level, works pretty much every way, and is guaranteed to be yours even when Vodafone decides that ZYB should be discontinued for some reason.

Your .tel is your own personal, distributed datastore for your contact information, public or private, for as long as you decide.

I hope the above explains to you what we know that .tel is, and I hope you can now make a decision on whether to keep your .tel next year – keep your eyes open for updates however!

Submitting your new .tel domain to search engines

2009-03-11T13:36:00.002Z

Some useful links to submitting your domain to search engines (assuming they don't know how to handle .tel domains natively):

Google: http://www.google.com/addurl.html

Microsoft Live Search: http://search.msn.com/docs/submit.aspx

Yahoo: http://search.yahoo.com/info/submit.html

Privacy first? No thanks, give me the standard behavior

2009-03-10T18:05:00.005Z

Speaking of feedback from you early Telsters (love the name!), you've overwhelmingly voted against our assumption that you'd prefer automatic privacy login over having a nice URL.

Here's the issue as it purely relates to the Web proxy of a .tel, and it is mostly due to security features of cookies handling: When you hit for example http://henri.tel, you'll be "redirected" to a server under the domain webproxy.nic.tel. The reason behind that is twofold: one, we're load balancing with unicast to the closest server farm; and two, we have to move you over to the nic.tel domain so that the Telfriends cookies work across all .tel domains.
The "redirection" is still to the same IP address and server farms, and allows the viewer of a domain who's logged in to Telfriends to automatically stay logged in whatever .tel domain he's viewing, and see private data for his friends automatically (via his nic.tel cookie). If cookies could be global to .tel (and not to mydomain.tel), we wouldn't be having this problem.

That said, an overwhelming majority of Telsters want and expect to see yourname.tel on the URL bar. Clearly understood. So what we're going to do first is give up the automatic Telfriends login: a user will need to click once to initiate the login (but won't need to reenter his credentials) and won't see the private data unless he effects the click.
With that in mind, we won't be required to redirect to a nic.tel domain to pick up the Telfriends cookie. And we can then work on determining how to handle a change to the load balancing that won't generate a url change.

More tech updates on this as we dig deeper and decide on the best approach.

Note: of course this only applies to viewing .tel data from the Web. Native apps that grab the data directly from the DNS are not affected.

First feedback on .tel processes

2009-03-10T17:10:00.003Z

Now that we've got our first feedback on the live .tel platform, here are a couple of comments:

1- Renaming folders in the Telhosting control panel
This small feature is in the to-do list and was left out due to time constraints, but in the meantime you can create a new folder, and then:
- click select all
- choose Copy to... in pulldown
- choose folder in pulldown
- click save.

Edit: If you have subdomains under this domain, it is a problem at this time. We'll have to code up an additional API call (or extend the storeFolder method) to do this.

2- Google maps on the web proxy
Instead of a link to the Google maps, it was suggested to embed Google maps in the proxy. There are a couple of problems with that, beyond speed issues:
- the web proxy is currently too lenient and sends out the desktop version to the more advanced mobile phones (iPhone, etc...). We're going to restrict all mobiles (insofar as we can sniff them) to the text-only version.
- when you're logged in to Telfriends, the web proxy is under https and Google maps will need to work with SSL in addition to regular http.
- if a domain does not redirect to a nic.tel subdomain, each domain will have to have its own Google Maps API key, which is totally unfeasible. Google Maps's signup process states clearly that "A single Maps API key is valid for a single "directory" or domain", and we'll need to agree with google that ".tel" can be considered a domain.

3- Private records at any subdomain level
Yes. It's definitely in the plans.

The new TLD .tel is LIVE!

2009-03-07T18:06:00.002Z

After many years of hard work, the new TLD .tel is live.
Today, a new page is turned on the Internet, and the DNS is used as a personal data store for communications.
A quiet, seemingly small technicality, but in actuality a fundamental revolution.

Don't be surprised if people give you a .tel instead of a phone number to reach them.
Welcome to the 21st century!

More SEO/SEM comments

2009-02-27T22:02:00.002Z

Christian Maund-Anderson posted in his SEO canadianvirtual.ca blog an entry titled Don't Tell Dot Tel. In it, he posits that ".tel is about linkspam". From the viewpoint of a web SEO/SEM person, I can understand his reasoning, but I hope to explain in this post that .tel cannot, should not and will not be viewed as a top level link farm.

First, an explanation of what link farming is. From wikipedia's entry on spamdexing:

(link farms) Involves creating tightly-knit communities of pages referencing each other, also known humorously as mutual admiration societies.

In a more general sense, link spam refers to linking pages for purposes other than semantic value, i.e. linking for the sake of linking because, for certain tools and services, the presence of a link is a Big Deal. Since Google first came out with the idea that links are more important than content for ranking results, everyone has started looking at links in a new light.

So, what does it mean for .tel? Well, nothing.

.tel is a publicly accessible distributed database of contact information, where each "node" of the database is owned by different people. This database is very structured, and allows each node owner to primarily store contact information, descriptive keywords and location (longitude/latitude). In addition, each contact info field in the database can also be encrypted using 1024-bit PKI.

This is it. The only relevance to link spam (and thus the confusion in the above-mentioned article) is a combination of two factors: first, one can enter a web url as a contact field, just like a phone number or an instant messaging handle. And second, Telnic has put together a service that allows the database to be viewable from the web.

So reviewing the above-mentioned article, the first point is that Telnic (not the TLD) does not have complete control over DNS. This is a fallacy. When you own a domain, you can have it served by whatever DNS server you want as long as the zone passes validation as an acceptable .tel zone. .tel uses the DNS as the distributed database infrastructure, so the rules are slightly different. You can't add A or CNAME records, but those are only rules, not control. It's similar to saying that a web page must have a starting and ending html tag.

Mr Maund-Anderson looked at the web interface to a .tel and determined that "The .tel pages are awash in links, links to websites, phones, social media." Well, no. There are no ".tel pages" per se. What he saw was a proxy server that queried .tel DNS information and displayed it to the web browser in a standardized way. He could have opened a shell on his computer and queried the DNS directly, and seen the raw data without using a browser. Or he could have loaded up any one of the available applications that query the DNS .tel zones directly, and gotten that info.

So the real question that is asked here is:

Will the search engines be gamed by .tel?

You'd have to be a very stupid search engine to be fooled by .tel: you're 100% guaranteed to know it's a .tel domain, and so you can decide, as a search engine developer, what value you'd like to assign to any information in the .tel, be it a web url or an email address. And instead of getting your bot to parse the web interface, get the perfectly structured raw data directly from the DNS distributed database. Querying the DNS is a piece of cake.
There's no point in Telnic adding a nofollow to the web interface to the database, in fact we should discourage search engines from using the web interface and instead query the data at the source. It's better, faster, cleaner, more distributed, and much less prone to mistakes.

I'd like to look at the problem Mr. Maund-Anderson raises and turn it on its head: with my .tel, I can finally tell the search engines what is relevant to a search regarding me. Let search engines use my .tel as a trusted source for info about me, if I make my WHOIS info public (and therefore they'll know I own my domain). My "profile" is not in crunchbase (crunchbase.com/person/henri-asseily), I've never given any of my info to these people and I never bothered checking their info. I'm not even linking it here because I don't want Google to think I'm giving it any value. If you do a search for my name in Google, you will find my .tel at the top, but the crunchbase url is somewhere in the first page as well, and I'd like that to go away. It's nowhere near as interesting as my twitter or facebook profiles, which I am linking from my .tel.

The next question is of course what will happen when .tel is adopted by the masses and gaming begins (as it always does, in any market). Well, in order to game a search for me, someone would have to effectively attempt to confuse readers and impersonate me with another .tel, and I will have legal recourse. There's a trusted paper trail in the WHOIS data. It's not perfect, but it's head and shoulders above what's currently available to fight impersonation.
There'll probably be a lot more gaming done, but I'm quite confident that search engines will be able to handle that at least as well as they currently are doing with web page that are infinitely more complicated.

No cookie-cutter layout

.tel has many "layouts". I've personally written half a dozen already, for different devices, and even embedded my .tel info in web pages on .com domains. The only cookie-cutter layout is again the standard web interface to the distributed database, and that's on purpose. The last thing people want is another round of parking pages, Google sponsored links and other flash and popup ads. When people put a .tel address in a browser, they'll know what to expect, every time: A set of contact info, keywords and possibly a location record.

The other .tel question
Next, the article states that "I don’t want to go to a page to get my contact’s information. This seems counter intuitive."
Well, where do you want to go? To your address book that's probably obsolete and doesn't have a tenth of the ways to contact me? Why not have a dynamic, always-accessible, global address book? The web "page", once again, is just a convenience for those who don't have another way of querying that address book. As an example, download the latest 2.1 beta of the Kiax soft phone, and enter "henri.tel" in the dial field. Easier to remember than a phone number, and with a lot more features. Of course you can still use and store in your address book the phone number, but know that this is static information that will certainly become obsolete some day.

H

Telsters

2009-02-26T10:53:00.002Z

I just found out that somebody coined the word Telsters. I like it!
And true to the spirit of the Internet, someone created a website to go along with it, and that website is a blog that is more fun and in many ways better than mine:

http://www.telsters.com/

The Facebook privacy conundrum

2009-02-18T10:14:00.005Z

Facebook just backed down and reverted to its old privacy policy, after the massive backlash started by privacy advocates. The interesting thing is Facebook's Mark Zuckerberg comments on the official Facebook blog (and he's got a followup post stating the return to the old terms).

In the first post, something struck a friend of mine familiar with the .tel, and she emailed me about it. Zuckerberg wrote:

People want full ownership and control of their information so they can turn off access to it at any time. At the same time, people also want to be able to bring the information others have shared with them—like email addresses, phone numbers, photos and so on—to other services and grant those services access to those people's information. These two positions are at odds with each other. There is no system today that enables me to share my email address with you and then simultaneously lets me control who you share it with and also lets you control what services you share it with.

Well that's one of the unique problems .tel can solve. Imagine that I give you henri.tel as my central point of contact. You want to send me an email. You fire up your mail client and type in the "To:" field "henri.tel". The mail client understands that this is a .tel and automatically looks up my associated email address(es), including the private one given just to you. You choose the one you want (or it's automatically chosen), and the mail is sent.

What I've done here is give you the ability to contact me via email. However, what I've also done is give you a dynamically allocated email address. If at some point I see that this email of mine has been abused (such as given to people who are spamming me), I can simply change email addresses on my .tel.

What happens then? Well, you can still email me in the same way. Nothing's changed for you. However, the spammer now has an email address that doesn't work any more. If he goes to my .tel to find my new email, he can't because it's private.

So .tel is indeed the system that enables me to share my email address with you and ultimately control the propagation of my email addresses. I can't control who and what services you share it with, but I can stop the sharing when I want. And those who have the power to stop something control it.

Mr Zuckerberg, it may be time for you to sell .tel domains to Facebook users concerned about real privacy.

.tel delegation policy: what it means

2009-02-17T17:06:00.002Z

The .tel AUP (Acceptable Use Policy) specifies a certain number of rules regarding subdomain delegation. I'd like here to explain the philosophy behind them. Delegation fundamentally mean a transfer of rights. In .tel, when you buy the domain smith.tel, you have rights to this domain, as well as responsibilities to abide by the Telnic AUP. You are allowed to sub-delegate the responsibility for updating sub-folders in some cases such as to people in your own company or your own family. So for example, should you want to sub-delegate mary. smith.tel and transfer the rights and responsibilities to Mary Smith who may be your wife, then you can only do so consistently with the AUP's policy on sub-delegations:

The registration and/or use of the Extended Name is free of charge to and is only for the use of subsidiaries, business units or employees of the company or members of the association that is the Domain Name Holder, and is not offered as a service to third parties, or, where the Domain Name Holder is a natural person, the Extended Name is only for the personal use of the Domain Name Holder or the family of the Domain Name Holder, is not offered as a service to third parties, and no fee or other compensation is charged in connection with such sub-delegation.

So you are not allowed to provide either paid for or free sub-delegation to people or businesses outside of those parties covered by the AUP (existing businesses or close family members).

What about for-pay directory services?

You are fully allowed to provide a paying directory service as long as you retain the rights and responsibilities of the domain and do not sub-delegate.

Providing a "concierge service" to update contact information is acceptable within the AUP, whether automated through do-it-yourself front-ends, or manual. However, it is assumed that the data published by you is covered by the normal and regional rules and laws for data protection, and you must have the informed consent of the owners of that data (which, as a for-pay service, is the case) unless the data is already freely available from other sources. This would be a legitimate information service that would not be in breach of the AUP.

What about links to other .tel domains?

Separately, a Non-Terminal NAPTR (NTN, i.e. a .tel link) is a pointer to another (sub)domain, and not a record in itself, which means that it simply points to an external domain over which you have no control, and the responsibility belongs to the owner of that .tel domain. That's the same as having links on a webpage of yours that send the user to another website.

Backing up your .tel information

2009-02-08T07:56:00.005Z

So you spent days, weeks, even months thinking about, setting up, updating and tweaking your .tel. And you're worried about what would happen if your Telhosting provider went down with all your hard work, because of an act of God such as a systems administrator having had too much to drink on the job and having pressed the wrong keys.

Fear Not, my gentle reader. For the Telhosting required API contains an export function that will get you all your data (including non-live data that is disabled because it's not in the active profile) onto your computer. And of course, there's an import function that does the opposite.

These two functions are requirements for any accredited Telhosting provider, so you can be sure they'll exist whatever provider you use. Just make sure you actually back up your data before that systems administrator hits the Crown Royal.

PS: none of our sysadmins drink on the job.

Edit: Below are the links to the relevant API functions, with full description and usage
ExportData to backup all your data.
ImportData to restore that data into a Telhosting provider's system.

Manage your .tel from your iPhone

2009-01-07T17:33:00.002Z

We've just published the source code for "My .tel", an iPhone app for managing your .tel. I wrote it so I could switch my phone numbers as I boarded a plane, and it grew from there. It lets you add/edit/delete/reorder contact records, add/delete keywords, and synchronize your location using the phone's GPS.

The app is missing privacy management, but that will come. It's in active development and will be updated as my time permits.

Have fun with the code, it shows the usage of the Telhosting JSON API.
Here are some direct links for the app and iPhone resources:
- description of both iphone apps
- download source as an archive
- ViewSVN with SVN sources
- checkout link for SVN
- Tutorial for Sample iPhone app and SDK

Privacy now available on vip.tel

2008-12-19T08:59:00.005Z

We updated the vip.tel public beta last night, and it now has full support for privacy. You can friend other vip.tel beta users, and decide what contact information you'd like each of your friends to see (or not).
Of course the friending APIs are now also active.

Get a free vip.tel beta account at http://www.telnic.org/vip/

Shortsightedness

2008-12-12T13:18:00.002Z

Now that the .tel has been available to trademarks for a week, we're getting a lot of buzz and feedback in online communities.
Most of it is really good, but of course there's always the criticism. Some criticism is borne out of misunderstanding (or simply lack of reading about .tel) but some other criticism is very interesting, and shows how quickly one can jump to the seemingly obvious but wrong conclusion. More interestingly, the less technical a community, the more it embraces .tel as a great product. And vice versa. So what's the issue with techies?

Well, as soon as a techie reads "top level domain" (or the TLD acronym), she automatically associates it with "domainer money grab". As you try to explain why .tel is really fundamentally different from any other TLD, the techie will say "but you can publish your contact info hundreds of ways already!" And she doesn't see the connection between these two points, which is as follows:

In order to publish your own information in one place that is forever yours, the best (and arguably only) solution today is to use a top-level domain. If you don't use a TLD, you're subordinated to a service provider that may or may not sell you advertising, cut you off, or even go bankrupt. Then good luck telling everyone that you switched to *another* "forever" place, and listen to the snickers.

That is the reason why Telnic is using a TLD. We're not making money from hidden deals or advertising, or thinking up new business models that promise to make someone else pay for your chance to control your data. You simply pay a small price ($15/year or whereabouts) for your guaranteed freedom and control, and buy your own unique domain. A .tel TLD is the only guarantee for you to own your unique, forever, publishing platform for contact information.

.tel sunrise is ON!

2008-12-03T15:00:00.002Z

The .tel sunrise just started!
The blogosphere is quite awash with comments, as was to be expected. Some are quite thoughtful, others somewhat off-base so I suppose I have to remind people that:

Privacy is fully supported: choose who sees what. Spammers will need to break 1024-bit encryption...

Testing the AJAX/JSON API

2008-11-20T06:11:00.002Z

I'm testing the AJAX/JSON API outside of the Telhosting system.
What's the best way to ensure developers are happy with an API?
Simply by making an app myself using that API, of course. :)

Therefore, a new iPhone app is on the way that will let you manage your .tel directly from the iPhone. Get on the plane, and before you turn off your phone, update your .tel and tell everyone you're not available! Oh and while you're at it, use the GPS to show that you're at the airport.

At this point in the development of the app, I find the API easy to use and quite comprehensive. We made a couple of minor changes to simplify things, but otherwise I'm happy with it.

Monetizing the .tel for domainers

2008-11-15T18:13:00.005Z

(this is in response to a domainnamewire post)

People in the domaining business think of .tel primarily as a domain extension first and a service second. In fact, it should be entirely the other way around. And so people who haven’t bought domains before (and the companies that haven’t sold them before but are becoming registrars to be able to integrate their services into the .tel platform) are the very people who are getting very interested in this service, not because it’s a domain, but because of the features and functionality. .tel is a very simple proposition, but is essentially unlimited in its scope and ability to grow into something far more functional than a simple interactive business card.

.tel is about simplifying communications (or, in more PRish words, reducing friction in communications). It has a clear focus – exposing all the ways you can contact an individual or a business. People will quickly discover what a .tel means to them – instant access to interaction. You set it up easily as you’ll have seen from the beta and it’s immediately accessible from any device. The amount of information is so small, it’s much cheaper and quicker to access over a mobile device than regular html sites (and over PCs too). We don’t do content (although you can dynamically generate your site’s “contact us” page with the .tel automatically) and no, you can’t put PPC ads on the page.

So what does that mean to domainers?

Personally, I see the general dependence on Google/Yahoo sponsored links as the main (if not only) revenue generator for domainers to be a very weak achilles’ heel for the whole domainer industry. Many in the domainer business are so focused on what they see as the Holy Grail of monetization (Google and Yahoo ads) that they’re convinced that there’s no monetization in the .tel.

What are the PPC revenues from mobile devices which is where the major growth is in the future?
Certainly not in web advertising. For mobiles, which are primarily communications devices, PPC actually means “Pay Per Connection”. When you look at it in this light, there are a ton of ways domainers can create revenue through affiliate programs, premium rate numbers for competitions, signposting to content-specific sites, etc. Some of our beta testers (sign up for free) are having a great time thinking of other ways to make money. The content IS the advertising, the marketing IS the product. Andrew Allemann hit the nail on the head when he likened it to a yellow or white page service. We all hate the inflexible way that these are run online today, but that didn’t prevent Yell earning over $1.5B in the past six months.

Monetizing your .tel if you’re a business is about making the phone ring (or email or website ping, facebook page increase in fans, twitter avatar get more followers, and so on) in exactly the same way – but being in control of how they do so and providing a really strong service at the same time. You can even use your .tel to list all of the domains you have for sale (especially the .mobi ones!). Let’s please get rid of the “Click” in PPC and transform it into the more general “Connection”.

Of course, the way we’re doing this with the DNS is pretty cool too, as others have already acknowledged, but we’re only using this because it’s the unique way to deliver a service that anyone can use which is 100% under their own control. I strongly believe that the only way a global, dynamic, decentralized, infinitely scalable yellow/white pages directory can work is when each person (moral or physical) owns its little piece of the directory. Dear reader, you’re never going to invest in publishing a single point of communications for yourself if you’re not absolutely certain that you’re in charge of it for the length of your (hopefully long) life.

Finally, indeed there are no auctions, it’s first come, first served, no premium names and only a reserved list of names that allow Telnic to conduct its business. I guess this might be a threat and an opportunity to the domainer community. A threat, as more people can invest at a level they can afford, increasing the gene pool. An opportunity, because your money will stretch further and the opportunity for another globally effective piece of real estate online that is so completely different from anything that’s been before, with huge consumer appeal, is an affordable gamble, I would assume. And personally, I'm a big fan of the K.I.S.S. principle, and in my experience as a general rule the simpler systems such as first-come-first-served tend to win in the long run.

AJAX/JSON TelHosting API

2008-11-10T16:18:00.003Z

There's the web front-end for the TelHosting software to manage your vip.tel. There's also a SOAP API, but it's currently disabled for vip.tel because we haven't finished testing its impact on the 3rd level domains of vip.tel.

However, there's also now a very simple AJAX/JSON API, and the docs are on the dev site. You can see it in action on your vip.tel TelHosting management console, as the TelHosting software uses it almost exclusively.

Enjoy.

Get your demo vip.tel

2008-11-07T17:10:00.003Z

Just got back from the ICANN conference in Cairo. As usual, the highlight of the conference was our own Telnic party, but hey... I'm obviously biased.
The other highlight as far as we're concerned is the unveiling of the beta VIP Telhosting platform, that you can now try for yourself. Just send an email to vip-support@telnic.org to get your free demo domain under vip.tel (for example, hasseily.vip.tel). You'll be given your credentials to log into the VIP Telhosting website, and in a matter of seconds you'll be up and running.

One thing that we're still missing is that the SOAP API is currently disabled for vip.tel. We'll work on enabling it ASAP. The problem is that vip.tel is a 2nd level domain masquerading as a top level domain, so we have to make sure that the API functions in this manner as well.

Apart from that, everyone was really excited about .tel and we got great positive feedback about our presentations of the Telhosting platform. And don't forget to comment about vip.tel in the forums of dev.telnic.org.

Telnic developer site LIVE!

2008-10-15T08:15:00.000+01:00

The Telnic developer site is live! Go to http://dev.telnic.org. Download apps, source code, etc... forums, wiki, and more.

The only thing missing is the Telhosting software that's in internal beta right now. Expect announcements about this soon. In the meantime, you can start reading up on the APIs and download all the source code for Outlook, Win Mobile, BlackBerry and iPhone.
Enjoy!

.tel and social graphs

2008-09-30T07:45:00.003+01:00

Social graphs are one of the latest developments in the web social space. I've been asked by a number of people already how the .tel relates to the new social graph initiatives, such as XFN and FOAF, and more generally the Google Social Graph API. Let's take a look at this exciting new area:

The Premise
The Web is really good at linking documents together, but pretty bad at linking people together. Why? Well, for one, people don't really exist on the Web, so it's kind of tough to link together fuzzy things. They have a "presence" in different places, what I'd call shadows of themselves being projected on multiple planes. I've got a Twitter stream, a Skype account and this blog, but even if you sum all these things up you can't make me. On the other hand, if you know a document's URL, you can get it in its entirety, a perfect duplication that is the bane of copyright protection people the world over.

So we've got a great Web infrastructure that is really really good at linking things together. Is there a way to leverage it to link people together? If that's possible, then actual "real life" relationships can be significantly improved: if a service somehow knows that I'm your friend, it can automatically link the two of us. For example, if GTalk knows that A is a friend of B because A said so on his website, then if A and B have accounts on GTalk they can automatically be linked as buddies on GTalk without any work at all on the part of A or B. And so A and B automatically are able to communicate on yet another channel, where before they were ignorant of it.

The Solutions
There are two main solutions today to solve that people linking problem.

The first is XFN, short for "XHTML Friends Network". It sounds complicated but it's straightforward. It adds a "rel" attribute to any anchor link on a webpage, allowing you to specify your "relationship" to that link. So you can write
<a href="http://jimmy.examples.com/" rel="colleague">Jimmy Example</a>
to say that Jimmy is your colleague. A simple solution that leverages (X)HTML nicely.

The second is FOAF, or "Friend of a Friend". In short, FOAF allows you to describe yourself in an XML format. So you write a description of yourself (your name, homepage, interests, who you know, etc...) and post it somewhere on the Web.

Applications can use XFN and FOAF to crawl the Web looking for relationships, and that's exactly what Google did. And it provides that data as a service, through an API called the Social Graph API.

.tel and Social Graphs
Is .tel of any interest in the social graph space? Absolutely!
As starters, .tel provides the person with an actual presence on the Internet, in a standardized (and therefore automation-friendly) manner. Owning your .tel means that you have a single point of contact for life, a distribution point for all your means of communications. In effect, you're telling an social application "You can always find me here, and here are all the means to contact me." So .tel solves the communications discoverability problem in a big way.
.tel can complement foaf in a couple of ways:
- I can point to one (or many) foaf documents describing me in more detail.
- And I could generate a FOAF document directly from my .tel information (this is currently left as an exercise to the reader)

One of the benefits of having a top level domain (TLD) dedicated to communications is that it solves the problem of actually finding people. It's great for you to create and host a foaf document somewhere, but search engines need to know where it is. foaf makes use of the "rdfs:seeAlso" tag to link a foaf document to another, giving foaf spiders the means to crawl. On the other hand, since .tel is a top level domain, the list of all .tel is made directly available. Of course subdomains need to be discovered and crawled, but that's under the control of the domain owner.

And then you need to be able to tell people "this is really me, not someone posing as me." When you own your .tel, that problem's solved because someone had to buy it. There's a clear paper trail. That's the other benefit of a TLD. On the other hand, with foaf it's much more complicated. You have to create a PGP signature, make sure it's properly hooked into a "web of trust" and that enough people trust that this key is yours, and then sign your FOAF file with that signature. Achieving a web of trust for a PGP key is not for the faint of heart, to say the least.

The other side of the trust coin is being able to trust people with your info, i.e. making your info only visible to your friends. Both foaf and .tel implement privacy through data encryption using the well-tested public key encryption. However, I think that one of the reasons foaf encryption didn't catch on is again that it's exceedingly complicated to implement. First, you need to create a public/private keypair and store it in the public keyservers. Second, you also need your friend to do the same thing. Good luck with that, using current tools. And finally, you need to encrypt some data with your friend's private key and store it in a new foaf file specifically for him.
When you own a .tel, you don't need to know any of that. The procedure is as follows: someone requests to be your friend, you accept, you put that friend in a group (say, "beer buddies"), and if you gave "beer buddies" access to your email, your friend sees it. Done.
Yes, behind the scenes you've got all this public/private key stuff, and yes you can completely control how that works (through the Friending API or even manually), but you don't need to. And more importantly, you shouldn't have to!

Also with a .tel I publish my communication protocols straight in the DNS for effective use by mobile devices. A web-based document such as a foaf one just can't be retrieved, parsed and made ready for use in real time by mobile devices.

This gives me the simplicity, persistence, control and exposure needed to give any personal information (including phone numbers or foaf documents) to whoever I want, whenever I want.

PS: Speaking of friending, this is an area where .tel can make use of the Social Graph APIs: after launch we will look into enabling the .tel Friending Service to talk to the Google Social Graph API, to discover if you have friends who have a .tel or are on the .tel Friending Service. This will make for a more streamlined user experience and will hopefully help grow what Tim Berners-Lee calls the Giant Global Graph.

Telnic Dev website

2008-09-26T13:24:00.003+01:00

We're putting the final touches on the dev website. All the source code for our mobile apps will be there, including BlackBerry, WinMobile and iPhone. We'll also have the Outlook plugin source code, a wiki, forums and the full API specifications. You'll have a very large amount of docs to work with.

DEMO Conference

2008-09-09T22:12:00.002+01:00

We are at the DEMO conference in San Diego. We presented on monday and it went really really well, great coverage and even more interest than we expected. People get what we're doing, and that's the most important thing! Every single person who stopped by our booth would have bought a .tel had it been available.
Below is the video of our demo with our own Justin Hayward speaking, in which you can see (in order): the Web proxy on a PC, the actual DNS data, the first public demo of the new TelHost management interface, the Blackberry plugin, the Web proxy on the iPhone, and finally my own little iPhone app. It all worked perfectly, even with the flakey GPRS/EDGE connection in the conference.
Note how changes are instantly published live in the DNS, and how fast and easy the iPhone lookups are. And trust me, coding for the .tel isn't any harder than it looks. :)

iPhone again

2008-08-28T16:35:00.002+01:00

Speaking of the previous post on my iPhone work, the source will of course be available. I'll publish it on Telnic's developer website that should go live in early october. This should allow iPhone developers to quickly get going with .tel without having to figure out how to make low-level DNS calls.
I'd love someone with iPhone and Objective-C experience to look over the source at some point and clean it up for release.

iPhone app

2008-08-28T16:22:00.005+01:00

Okay, continuing to eat our own dog food, I embarked upon the development of my first iPhone app, and also the first iPhone app to use .tel.
Within a couple of days I had an (ugly) app that would look through my address book, find all my friends who had a .tel, look up their .tel for a LOC (location) record, and compare that to my own location via the iPhone GPS service, and finally tell me which of my friends were closest to me.

Now about 2 weeks into it, I have what I think is a nice app (considering my lacking design skills) that does all of the above, shows an actual map with pins, and also looks up all the NAPTR records so I can contact my friends directly.

Looking back, here's the work distribution:
- 5% of the work was to get a DNS library to work on the iPhone. Thanks to the free ldns library, that was just a matter porting the makefiles over to XCode and fixing them up for the iPhone ARM processor.

- a couple of hours only to hook up the LOC records from .tel

- About 5% of the work was to write the query and display structure for the NAPTRs

- 60% of time was spent learning Objective-C (my C skills were almost nonexistent) and the iPhone framework

- 30% of the time was spent banging my head on how to display a map with pins. Unfortunately the nice native Google Maps app on the iPhone does NOT accept KML files as input, which totally sucks. When that's fixed, I'll be able to cut out a good third of the codebase that right now just hacks things to go through a specially set up website that proxies the google maps.

All in all, a very good 2 weeks spent making sure the read apis (i.e. the DNS side of things) are working easily, as expected. The only missing stuff is the private data handling, but the SO Friending system isn't live yet to be able to hook into it.

Open Web Foundation

2008-07-25T19:43:00.002+01:00

Something called the Open Web Foundation just launched.
I really like the concept: creating a home for community-driven specifications, which will hopefully help them become more successfully adopted (and get to the holy grail of officialdom at IETF, W3C, etc...).
It's really hard to get a good spec structured with good intellectual property legalese early on, as one mostly focuses on the spec itself rather than its legal aspects. At Telnic most of our work is in fact defining policies and setting up this legal infrastructure so that the .tel ecosystem can independently thrive the way it should.
So I personally am very happy to see such a community-driven endeavor started. I'll try to contribute whatever meager knowledge I've got.

OpenID

2008-07-25T19:30:00.002+01:00

I don't know about your experiences, but I've been having a lot of trouble using OpenID on different sites.
I was just on the new Open Web Foundation site (more later on that) and you'd expect MovableType software to actually work with OpenID properly. Well it didn't, and not for lack of my trying.
I think OpenID solves a problem that must be solved, but it probably needs to be a little simpler to implement if it's going to be heavily used (as it should).

Speaking of OpenID, one of the questions we get a lot when we explain .tel is "can I use .tel instead of OpenID?"
In other words, people wonder if it might be possible to use .tel for identity authentication upon launch of the TLD.
The short answer is: no, the purpose of .tel is not to authenticate your identity.
The longish answer is that .tel puts you in control of your communications and allows you to centrally manage and securely publish all your means of communications. OpenID solves a totally different problem, which is cross-site authentication, otherwise called "single sign-on".

You can of course publish inside your .tel your OpenID authentication URL, making it easy for applications to discover that you own an OpenID. That's something I'd like to pursue at some point, so that in replacement to having to enter my "http://openid.aol.com/username" in the OpenID authentication field, I could simply write "henri.tel" and the website would pick up my OpenID url (assuming I want to have it public) from henri.tel. I can also encrypt my OpenID url on henri.tel, but then I'd have to give the website proper friending status to see it, which would make the system more complex. But having more options is always good. :)

Last stretch before ICANN

2008-06-20T13:51:00.002+01:00

Well that was a long week of final touches on our website before ICANN (and that's why I didn't update the blog). It will be released at http://www.telnic.org this weekend, with everything a registrar would ever want to know about how to gear up for .tel.

Next up, the ICANN conference, then the release of our NSP software and all the goodies for developers!

Unveiling the .tel

2008-06-13T12:52:00.002+01:00

We're getting ready to go "live" in a sense with the .tel, which will be unveiled at the ICANN conference in Paris on the week of June 23.

Before that however, our own Justin Hayward will be making a very quick presentation of the .tel at the Domainer Meeting in Paris as well, on June 19.

Don't expect much filler in the powerpoint presentations, we hate them as much as you do. All I want (remember though, on this blog I don't speak for the company) is for people to see the .tel as what we hope it will be. We're not in the kool-aid business.

One more thing... I've been reading the comments dating back to 2006 regarding the attribution of the .tel TLD, and I hope the "industry experts" will understand what we're looking to achieve here. If we do our job correctly, the answer won't be "just another TLD". :)

Privacy in .tel

2008-05-21T08:45:00.006+01:00

I've explained a bit what .tel means as well as its technical underpinnings. In effect, you can store in your .tel all your personal contact information and update it in real time. You'll have solved the problem of how people contact you by simply giving them your .tel.

The problem of course is that you don't want anyone to have access to your mobile phone number. Privacy is an absolute necessity! This problem is solved in a simple and open manner by enabling contact data (the NAPTR records that I talked about earlier) to be encrypted inside your .tel.

The technical solution we've adopted is as simple as we can make it. It consists of providing a free friending service whose job is two-fold:

upon signing up, it creates in the background a public/private key pair for you
it stores the friending relationships between you and other people

A picture to describe the friending system:

So now you've got a public and a private key (all done seamlessly behind the scenes), and you can decide who to (or not) friend.

The final step is to decide who gets to see what contact info of yours. Say for example that Adam decides that Carla can see his mobile number. The system will grab Carla's public key and encrypt Adam's mobile number with it. It will then store it in a special subdomain in the DNS. When at some later point Carla retrieves Adam's info, she will be able to automatically decrypt his mobile number with her private key (which is only known to and accessible by her).

From an engineering point of view, this technique can be used by anyone and could bypass the "official" .tel friending system altogether. As long as your friend knows how to decrypt what you encrypt, all is well.

Our job at Telnic is not nor will ever be to lock people into a proprietary system. Quite the opposite, in fact. We are looking to develop proper rules to help grow an ecosystem that will simplify communications.

.tel's record types

2008-05-20T11:27:00.005+01:00

In this post I'll talk about how .tel works but I won't get into the exact details and specifications. The full specs, policies, documents, howto's, etc... will be available on the telnic.org website in time for the ICANN meeting in Paris, France on June 23rd. Of course I'll post here the links as soon as the info is up on the official site. In the meantime, I'll write articles in this blog from the point of view of .tel owners, users and developers.

On to how .tel works:

From a technical perspective, the DNS specifications allow storing a staggering amount of different types of data in DNS zones. Traditional TLDs such as .com or even .name use in general the following types:

A : the standard name -> IP translation (give a name, return an IP)
CNAME: a name that points to another name (so you can have name -> name -> IP)
MX: "mail exchange", i.e. an email server for the zone
PTR: the opposite of A (IP -> name)

Those are the main "meat and potatoes" types of records that traditional TLDs use. Taken together, their main goal is to translate back and forth computer names to IP addresses.

.tel on the other hand focuses exclusively on three types of records:

NAPTR: your basic key/value pair, where the key is an Enumservice specification
TXT: text records, where you store keywords and other freeform text
LOC: location records comprised of latitude, longitude and altitude.

That's it. A .tel owner can only work with the above three types of records, but in this case less is more.

If you are proficient in UNIX command-line usage, you can look at my henri.tel domain's info for all three types of records using the following commands:

dig henri.tel NAPTR +bufsize=4000

dig henri.tel TXT

dig henri.tel LOC

Alternatively, use the following links to see the information: NAPTR, TXT, LOC

That's pretty much all there is to a .tel. Remember though that NAPTR records can accept any type of Enumservice, such as voice:tel, web:http or even extensions such as im:x-skype. In addition, NAPTRs can point to any other .tel domain or subdomain, which means that I can point from henri.tel to social.henri.tel.

.tel and the meanings of TLDs

2008-05-20T10:43:00.005+01:00

So we're working hard to release Yet Another top-level domain (TLD) to the world, named ".tel". I hear the moans already... Doesn't the world already have .com, .net, .us, .mobi, .name, .tv, etc... etc...? What's the point of having another one?

Well, .tel just isn't like the others. At all.

Up until .tel, all TLDs have been used to facilitate computer-to-computer communications. They are the user-friendly face of the DNS. Want to go hit google.com? Your browser will call your computer OS's networking library and ask "hey, can you tell me what is google.com"? Your OS will in turn communicate with a DNS server that's probably hosted at your internet provider's facility and ask it that same question. The DNS server will then look up the google.com zone and respond "hmmm... looks like google.com is actually the server 64.233.167.99" (you can try it yourself here). Once your browser gets that information back, it will then communicate directly with 64.233.167.99 and request the main web page.

Yes I know all the above is the true idiot's idiot guide to how DNS works, but I don't know yet how knowledgeable my readership will be (if any). Anyway, long story short: every single TLD today is focused on facilitating computer-to-computer communications. All information in the DNS is about and for computers: which machines are mail servers, which ones handle the DNS itself, which machine names are actually aliases to other machine names, etc...

.tel on the other hand is about people-to-people communications inasmuch as communicating does still generally necessitate communications devices.

I showed you what happens when you ask for info about google.com (you can try again here). Well, let's see what happens when we ask for a certain type of info (NAPTR records, but I'll explain those later) about henri.tel (go ahead, click).

Interesting, isn't it? Instead of learning about the IP address of the machine that hosts the henri.tel website, you learn all sorts of interesting things about me, namely in this case my phone numbers, email addresses, IM handles, etc... Oh, there are also links to websites and to some of my subdomains, such as social.henri.tel.

Once on the Net, always on the Net

2008-05-20T10:15:00.004+01:00

Okay. Time for some substance I guess. Otherwise what would have been the point of this blog?

A few years ago I was getting tired of co-location air conditioning issues, scalability challenges, APIs and language wars. I was thinking it was time for a change.

Fast forward a couple of years, and I'm smack in the middle of the buzzword-laden Web 2.0 "social networking" mesh stuff that every blogger feels she needs to discuss. I'd sworn off the Internet after selling Shopzilla, but I guess that just when I thought I was out.... they pull me back in.

Not really kicking and screaming though, because I think what we're building is a necessity. The company is called Telnic, and it is the registry for the .tel sponsored top-level domain (TLD). Quick primer: A registry manages the policies for a sponsored TLD and sells domains wholesale at the exact same terms to any accredited ICANN registrar (who then sells to resellers or individual customers).

So what is .tel? It could (and hopefully will) be many things, but at its core, .tel is a way to use the DNS as a key-value pair data store. For example, one could store in abcd.tel:

voice:tel, +1 (310) 555-1212
email:mailto, joe@joe.com

That's the most basic premise. More on subsequent posts.

Another beginning

2008-05-20T10:13:00.002+01:00

Hmm... Always tough to start a new blog. It's like a blank sheet of paper taking over the aspiring writer's vision.

Well then the best thing to do is to click on the "publish" button and put that first post behind me.