I think we need to clarify some of the assumptions in this discussion. Bob sends message from an IM client on his computer / phone. John receives message on his phone over SMS.
How does he know if it's [EMAIL PROTECTED] or [EMAIL PROTECTED] who sent the original? John cannot see "icons" on this phone. The SMS message limit is 140 characters. The sender is a 5 digit number. The client interface is the SMS interface on the phone. It's not a browser or IM client. Possible Answers: 1) John memorizes the SMS number for each service and knows 55131 is twitter.com and 64333 is foo.com and responds accordingly. 2) The SMS message contains identification of sender (e.g. nickname assigned earlier, qualified domain name, etc) Did I miss anything? On Wed, Jul 30, 2008 at 4:05 PM, Dave Cridland <[EMAIL PROTECTED]> wrote: > On Wed Jul 30 20:44:18 2008, Bob Wyman wrote: > >> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <[EMAIL PROTECTED]> >> wrote: >> > I'm not sure this is necessary. Or at least I don't see much >> > of a difference between a service that aliases your name >> > "Anders Conbere" to your email address "[EMAIL PROTECTED]". >> >> Imagine that you're using a federated system like Identi.ca rather than a >> walled-garden system like Twitter. Now, imagine that you subscribe to two >> different people: [EMAIL PROTECTED] and [EMAIL PROTECTED] (two people, same >> local name). Given this, what would a message look like if it is delivered >> to you via SMS? In that case, the alias "anders" wouldn't do you any good >> since you wouldn't know *which* anders was responsible for the message. >> Your >> SMS server would be forced to expand the alias out to include the domain >> in >> order to allow you to show you who sent the message. But, in doing so, it >> would lengthen the message and might, therefore, result in the message >> growing to more than the maximum number of characters for an SMS >> message... >> So, your SMS system might have to cut off the end of the message and thus, >> potentially lose important information. >> > > I agree it sucks, but I'm not convinced that it needs to be broken in the > way you suggest. > > Instead, you enter @anders into the interface at foo.com. > > foo.com knows you mean [EMAIL PROTECTED], because it's unqualified. > > foo.com tells me @aFoo, because it happens to know that I have expressed > an interest in referring to [EMAIL PROTECTED] as @aFoo. > > I reply to @aFoo, and the reply goes toModel, then interface - the Model is > that names are qualified by some namespace, but that does not follow that > the sole Interface technique allowable is to mandate that qualification on > the user. > > XMPP already has a concept of nicknames that works well for this kind of > case, and I think that's what we want to be using here. > > What I do think is important is to move away from the relative free-form of > profile URLs that Laconica and Twitter are using, and move toward a > qualification based on domain name, so we really can say "[EMAIL PROTECTED]" > where the interface demands, instead of "http://foo.com/anders"; - that > means we'd need to agree on the syntax of names, too. > > Dave. > -- > Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]<[EMAIL > PROTECTED]> > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
