Privacy now available on vip.tel

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

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!

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

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

(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

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

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!

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

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

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

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

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

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

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

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

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

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

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:

1. upon signing up, it creates in the background a public/private key pair for you
2. 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

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

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

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

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.