Some issues tend to re-appear over and over... Twitter, Identi.ca, etc. implement the convention that @<local_username> is the way to address a reply. This works fine as long as you're only working within a single service, however, it will break down as we move to federated systems. The problem is, of course, that usernames are not unique across services, only within them. Thus, if I have incoming Tweets/Dents from both Identi.ca and Twitter, I can't really use the "@" convention without a good bit of intelligence built into my client or without expanding to something like: @[EMAIL PROTECTED] and @[EMAIL PROTECTED]
We went through this in email a long time ago. To make the interface "easy" to use, the old email systems (late 70's and early 80's) used to let you address messages without specifying the domain of the user. But, this turned out to be a nightmare once email systems started to connect to each other. This is why we invented the "@/AT" syntax in the first place. While you were originally known as "foobar", you could later be addressed as either "[EMAIL PROTECTED]" or "foobar AT domain". It was *really* hard to convince people who had gotten used to addressing by user name only to start including the domain or node as well. For a while, some email system developers tried to keep the easy to use method by saying that you only needed to use the domain part when sending to someone on a different service. But, that didn't work. Technically, it was an ok solution, but the problem was that people kept making mistakes and emails were getting routed to the wrong service. So, we now have a system that requires that domain name be part of EVERY email address and the system works much better. The growth of the @<username> convention seems to be a return to the innocent days of the late 70's when many people were building single domain, non-interconnected non-federated email systems. These were systems that assumed that served *all* interesting addressees... Not good. bob wyman
