.tel:
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.
Subscribe to:
Posts (Atom)