If you want type-ahead functionality, your XMPP client needs to do more than speak XMPP :-)
On Wed, Jul 30, 2008 at 2:38 PM, Chris Messina <[EMAIL PROTECTED]>wrote: > ...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 >
