At this point, I'm not sure what problem you're trying to address.  Too many
tangential discussions and not enough definition of key assumptions.

Are you trying to come up with a universal, user-friendly way to provided
unique identification for micro-blogging platforms that works across a
federated environment?  What protocol?  SMS?  XMPP?  HTML/HTTP? SMTP? All of
them?

If it's XMPP, it already exists and it works. And it works for SMS if you
don't care about how long it is.  It also works for HTML/HTTP.  And it also
works for SMTP.  It's [EMAIL PROTECTED] and the key assumption is name is
unique within a domain.



On Wed, Jul 30, 2008 at 4:28 PM, Bob Wyman <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 30, 2008 at 5:15 PM, Henry H <[EMAIL PROTECTED]> wrote:
> > 1) John memorizes the SMS number for
> > each service and knows 55131 is
> > twitter.com and 64333 is foo.com
>
> That only works if the SMS number can be considered a synonym for the
> "domain part" of the user's id and users have excellent memory... It won't
> work where you have a federated system or other aggregator that can forward
> messages from more than one domain. (e.g. A system might pass messages from
> both [EMAIL PROTECTED] and [EMAIL PROTECTED] -- the SMS number would be the 
> same
> for both Susans and thus provides no help in disambiguation.
>
> > 2) The SMS message contains identification
> > of sender (e.g. nickname assigned earlier,
> > qualified domain name, etc)
> This issue, of course, is potential truncation as a result of expanding the
> identifier to provide disambiguation.
>
> It should be noted that there are issues with "icon based" solutions even
> on non-SMS channels. For very good reasons, modern web browsers and email
> systems allow users to turn off image display. In some cases it is to adapt
> to low bandwidth communications paths, in other situations, it is to avoid
> the security problems that have often been discovered in image rendering
> code. There are also questions of "morality" with folk who are easily
> offended by objectionable images. We should also consider accessibility
> issues: Not all users can view images and may prefer or need to use
> Text-to-speech interfaces to "read" displayed data.
>
> An additional issue with icon based systems is that they mean that the
> display format for a name is not the same as the input format. This means
> that you may be able to distinguish [EMAIL PROTECTED] from [EMAIL PROTECTED] 
> on icon, however, the information you use to distinguish them is not
> useful if you are attempting to send them a message.
>
> bob wyman
>
>

Reply via email to