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
Wednesday, March 11, 2009
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!
Subscribe to:
Posts (Atom)