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?
Tuesday, October 27, 2009
Dumbing down
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.
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.
Thursday, October 22, 2009
.tel management app for iPhone: My.tel version 2
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:
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.
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.
Thursday, October 01, 2009
Mobile Advertising
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.
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:
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.
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.
Monday, September 21, 2009
RSSCloud
(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:
The DNS query to get the above is:
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:
Can't be much simpler than that...
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...
Friday, September 04, 2009
Apologies to my iPhone users
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.
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.
Monday, August 17, 2009
Saturday, August 15, 2009
At the cusp of contact info convergence
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.
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.
Wednesday, August 12, 2009
Commenting on an SEM Clubhouse post
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:
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:
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:
.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:
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.
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.
Saturday, August 01, 2009
Google SEO and .tel, again
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.
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.
Wednesday, July 08, 2009
Why .tel and not a free hcard microformat?
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).
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).
Saturday, May 30, 2009
Restrictions as a positive enabler
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
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
Sunday, April 26, 2009
Search and proxy stats
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.
Monday, April 20, 2009
promoting.tel
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.
promoting.tel
Check it out. One more example of what a .tel is: a personal, persistent and dynamic online contact data store.
Friday, April 17, 2009
The My.tel iPhone app is available
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.
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.
Tuesday, April 07, 2009
Navigation at the speed of DNS
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.
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.
Thursday, April 02, 2009
Response to shkspr.mobi
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:
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:
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!
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!
Wednesday, March 11, 2009
Submitting your new .tel domain to search engines
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
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
Tuesday, March 10, 2009
Privacy first? No thanks, give me the standard behavior
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.
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
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.
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.
Saturday, March 07, 2009
The new TLD .tel is LIVE!
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!
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!
Friday, February 27, 2009
More SEO/SEM comments
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:
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
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
Thursday, February 26, 2009
Telsters
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/
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/
Wednesday, February 18, 2009
The Facebook privacy conundrum
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:
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.
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.
Tuesday, February 17, 2009
.tel delegation policy: what it means
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:
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.
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.
Sunday, February 08, 2009
Backing up your .tel information
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.
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.
Wednesday, January 07, 2009
Manage your .tel from your iPhone
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
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
Subscribe to:
Posts (Atom)