I think this type of convention permeates anything new. Take instant messaging and all the problems getting the IM protocols talking to each other. As a result, we need special IM gateways AND changes to IM clients to address this issue because of the original conventions.
It's the classic chicken / egg situation. When it comes to adoption, you need the interface to be simple. If twitter came out with a convention that required you to tack on @[EMAIL PROTECTED] without knowledge it would be something bigger - users would wonder at the inefficiency of adding an additional field just to reply to someone that's on the same platform. Hindsight is always 20/20, but its never black and white at the beginning because you never know how big something will become and if you want it to be big, you don't necessarily architect it that way because it takes a lot more thought, sometimes more money, may end up throwaway or sometimes prevent widespread adoption. On Wed, Jul 30, 2008 at 1:22 PM, Chris Messina <[EMAIL PROTECTED]>wrote: > Indeed. Add another service that supports the @reply convention: > http://blip.fm > > Chris > > > On Wed, Jul 30, 2008 at 10:26 AM, Bob Wyman <[EMAIL PROTECTED]> wrote: > >> 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 >> >> > > > -- > Chris Messina > Citizen-Participant & > Open Source Advocate-at-Large > factoryjoe.com # diso-project.org > citizenagency.com # vidoop.com > This email is: [ ] bloggable [X] ask first [ ] private >
