...and I would argue that most folks probably would still prefer the simplest portrayal of a contact's name or username, regardless of collisions... If I have one contact named Sarah, and I type @Sarah, I know who I mean. If I see an @Sarah from someone else, I don't think that the assumption is going to be that it's the same Sarah that I know -- necessarily. Now, if the name is more obscure, like @daveman692, then there's a higher likelihood that it's the same person. But that's only because in that particular case, we're talking about the worst username evar.
Still, there's a balance to be found between specificity, clarity, intention and what the system needs to know in order to correctly link back to the intended message recipient. And that's where things get really hairy given the decentralized/no-central-registry model of Identica/Laconica, where you might type @Sarah in your local system intending to message twitter.com/sarah instead of identi.ca/sarah, even though you might follow both. That's really where I think we need some kind of universal type-ahead functionality, leaving the choice up to the poster to be specific and link correctly... or not. :-\ Chris On Wed, Jul 30, 2008 at 12:07 PM, Henry H <[EMAIL PROTECTED]> wrote: > 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 >> > > -- 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
