http://groups.google.com/group/webfinger/browse_thread/thread/4b367d78ef81c61d?hl=en&pli=1
i was just looking at webfinger the other day as it was mentioned on one of the threads on scripting.com about ids/usernames for rsscloud. i have interest in this topic right now and was leaning toward an email centric id and was studying the EAUT protocol – http://eaut.org -
webfinger made me actually lookup and read about the original finger protocol. yes, i am old enough to have used it as a kid (i am 34). it’s fun to remember those early days. so exciting, raw and simple. so the webfinger site was a bit quiet until the new talk today. this all shows how momentum behind ideas largely depends on who you are, where you work and who you know. will webfinger be the right focus? maybe. could be. or maybe something called called dottel (.tel – http://telnic.com).
after reading about EAUT, webfinger and even RWHOIS, i switched modes and got excited about the technology behind the .tel tld offering. i registered http://sull.tel. i also secured rsscloud.tel to test using it as an id infrastructure by utilizing folders/subdomains (ie. dave.rsscloud.tel). telnic is developer friendly with a variety of open source software and APIs so new services can be built with the hopes of more adoption of a .tel domain being your permanent and official digital identity that is accessible from not only the web but from mobile devices, CLI and any other number of ways of interfacing with DNS in new innovative ways. a .tel domain is not about a website. the domain does come with a web proxy service that outputs a simple template for displaying your contact info and links but the domain does not require the web, a web server or any additional service in order to run and be accessible to others. It uses direct DNS storage to organize types of text strings which server various purposes for profile building. technically, a .tel domain can be used as a replacement for a phone number (using soft phones and eventually more ways such as regular phone software that handles outoging calls.) the .tel domain lets you store many many records, has encrypted privacy features for controlling who can access certain info and allows you to create directories (subfolders/subdomains) so you can organize your info or even to provide a directory service.
i’m curious about issues regarding spam and abuse. granted, gmail and other email services do a much better job today filtering spam away from your inbox. yet, do i want to make aan email address my main digital id? would people end up using an email soley as a JID and not an actual receiving address? will that cause confusion? should you use a 3rd party domain or a domain that you own and control? would a simple .tel domain be a smarter choice? afterall, .tel was designed to be your digital identity system. email was designed to be a way to send and receive messages.
the problem might be the overlap of the fact that it is common to use your email address to login to web services (a form of digital id) and a more public usage where you are basically announcing that your email address is used to access your profile/identity record(s). the latter case may lead to the preference of using alt email addresses that may not be used for sending/receiving messages or if so, it may provide a forwarding option. regardless, therse issues bring a certain amount of complexity to the idea of email as id. i’m not convinced either way. like i said, i was just recently in favor of email centric ids (for rsscloud and in general). i seem to have more difficulty finding holes in the telnic service than with email as id. once i got past the marketing style and business endeavor of telnic, i was able to really appreciate the use of DNS technology to make this happen in a distributed manner where their is no single company involved nor a single point of failure. a .tel domain is essentially a very reliable and federated id.
the coming months are going to be very interesting as this issue accelerates.
sull
Related posts:
Trackbacks 8:47 AM on March 18, 2010 Permalink |