[Social] "@" is evil... Namespace conflicts...

[Bob Wyman]

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: @foo (AT) twitter (DOT) com and @foo (AT) indenti (DOT) ca.

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
"foobar@domain" 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]

Indeed. Add another service that supports the @reply convention:
http://blip.fm

Chris

On Wed, Jul 30, 2008 at 10:26 AM, Bob Wyman <bob (AT) wyman (DOT) us> 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: @foo (AT) twitter (DOT) com and @foo (AT) indenti (DOT) ca.
>
> 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
> "foobar@domain" 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

[anders conbere]

On Wed, Jul 30, 2008 at 10:26 AM, Bob Wyman <bob (AT) wyman (DOT) us> 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: @foo (AT) twitter (DOT) com and @foo (AT) indenti (DOT) ca.
>
> 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
> "foobar@domain" 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.

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 "aconbere (AT) gmail (DOT) com". Certainly aliases have
existed for ages, it's only up to these services to translate those
internal id's into globally addressable ones.

~ Anders

>
> bob wyman
>
>

[Henry H]

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 @john@twitter 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 <chris.messina (AT) gmail (DOT) com>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 <bob (AT) wyman (DOT) us> 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: @foo (AT) twitter (DOT) com and @foo (AT) indenti (DOT) ca.
>>
>> 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 "foobar@domain" 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]

....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 <appleman (AT) gmail (DOT) com> 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 @john@twitter 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 <chris.messina (AT) gmail (DOT) com>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 <bob (AT) wyman (DOT) us> 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: @foo (AT) twitter (DOT) com and @foo (AT) indenti (DOT) ca.
>>>
>>> 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 "foobar@domain" 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

[Henry H]

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 <chris.messina (AT) gmail (DOT) com>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 <appleman (AT) gmail (DOT) com> 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 @john@twitter 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 <chris.messina (AT) gmail (DOT) com>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 <bob (AT) wyman (DOT) us> 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: @foo (AT) twitter (DOT) com and @foo (AT) indenti (DOT) ca.
>>>>
>>>> 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 "foobar@domain" 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
>

[Bob Wyman]

On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere (AT) gmail (DOT) com> 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 "aconbere (AT) gmail (DOT) com".

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: anders (AT) foo (DOT) com and anders (AT) example (DOT) com (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.

bob wyman

[anders conbere]

On Wed, Jul 30, 2008 at 12:44 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:
> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere (AT) gmail (DOT) com> 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 "aconbere (AT) gmail (DOT) com".
>
> 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: anders (AT) foo (DOT) com and anders (AT) example (DOT) com (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.

This seems to me like the fault of SMS not of aliasing. On the rest of
the web this kind of aliasing isn't a problem because we can markup
that text with extra data <a href="http://twitter.com/aconbere"
rel="me, that-xmpp-spec">@anders</a>, the problem you're bring up is
that we don't have a good way besides raw uri's to describe resources
(in this case people) in plain text. This is one of the whole points
of hypertext!

~ Anders

>
> bob wyman
>
>

[Henry H]

So what's the situation when you're following someone with a really long
name? Let's say I am following - AlexanderGrahamBell and Alex -- isn't that
the same issue?

If you just truncate the name when it is different (Alexa vs Alex), what
happens when you add Alexandria and so on?

These are limitations of the SMS protocol (140 character limit) bumping up
against limitations of uniquely identifying senders. If we weren't using an
SMTP to SMS gateway - the SMS number identifies the sender, but in Twitter's
case (and most cases) it's too expensive to have an SMS# assigned to every
user so identification is included in the message body.

There are several possible solutions to this, but unless there are plans to
change the SMS protocol (not likely) it will be up to the service to
determine how they want to handle this (e.g. let users assign nicknames to
people they follow up to a certain # of characters - say 5, and limit
messages to 135 characters). This will get truncated, but Twitter basically
built a model around the "legacy" constraints of the SMS protocol and used
it in their positioning (e.g. Microblogging). It's pretty clever because
the limitations of SMS are actually marketed as a "benefit" (get your
updates in bite-size chunks).

Fun stuff.

On Wed, Jul 30, 2008 at 2:44 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:

> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere (AT) gmail (DOT) com>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 "aconbere (AT) gmail (DOT) com".
>
> 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: anders (AT) foo (DOT) com and anders (AT) example (DOT) com (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.
>
> bob wyman
>
>

[Bob Wyman]

On Wed, Jul 30, 2008 at 3:57 PM, Henry H <appleman (AT) gmail (DOT) com> wrote:
> (e.g. let users assign nicknames to people
> they follow up to a certain # of characters
> - say 5, and limit messages to 135 characters)

But, what would you do if you're using a "tracking" service that does
real-time prospective search within the stream of all public messages
published in a federated network. With such a service, you can't know in
advance which user ids you will see. Thus, you can't rely on learning that
the prefix "Alex" is different from "Alexa."

On Wed, Jul 30, 2008 at 3:56 PM, anders conbere <aconbere (AT) gmail (DOT) com> wrote:
> On the rest of the web this kind of aliasing isn't
> a problem because we can markup that text with
> extra data <a href="http://twitter.com/aconbere" rel="me,
> that-xmpp-spec">@anders</a>, the problem you're bring up is
> that we don't have a good way besides raw uri's to
> describe resources (in this case people) in plain text.

Being able to hide data behind the interface in hyperlinks may solve the
machine's problem, but it doesn't solve the human interface problem. Imagine
that there are two Susan's who might send you Tweets/Dents or whatever. They
are: susan (AT) nice (DOT) com and susan (AT) bad (DOT) com. Now, you get a message that looks
like this in your IM client:

Susan <http://bad.com/susan>: Shall we have dinner tonight?

How do you know what answer to give or to whom your answer will be sent?
Will you *always* remember to check? How would a non-technical person solve
this problem?

bob wyman

[Ayende Rahien]

At the end user UI, this is a simple issue, associate an icon with each
service, which doesn't take a lot of room.Or use Susan (twitter.com)

On Wed, Jul 30, 2008 at 11:23 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:

> On Wed, Jul 30, 2008 at 3:57 PM, Henry H <appleman (AT) gmail (DOT) com> wrote:
> > (e.g. let users assign nicknames to people
> > they follow up to a certain # of characters
> > - say 5, and limit messages to 135 characters)
>
> But, what would you do if you're using a "tracking" service that does
> real-time prospective search within the stream of all public messages
> published in a federated network. With such a service, you can't know in
> advance which user ids you will see. Thus, you can't rely on learning that
> the prefix "Alex" is different from "Alexa."
>
> On Wed, Jul 30, 2008 at 3:56 PM, anders conbere <aconbere (AT) gmail (DOT) com>wrote:
> > On the rest of the web this kind of aliasing isn't
> > a problem because we can markup that text with
> > extra data <a href="http://twitter.com/aconbere" rel="me,
> > that-xmpp-spec">@anders</a>, the problem you're bring up is
> > that we don't have a good way besides raw uri's to
> > describe resources (in this case people) in plain text.
>
> Being able to hide data behind the interface in hyperlinks may solve the
> machine's problem, but it doesn't solve the human interface problem. Imagine
> that there are two Susan's who might send you Tweets/Dents or whatever. They
> are: susan (AT) nice (DOT) com and susan (AT) bad (DOT) com. Now, you get a message that looks
> like this in your IM client:
>
> Susan <http://bad.com/susan>: Shall we have dinner tonight?
>
> How do you know what answer to give or to whom your answer will be sent?
> Will you *always* remember to check? How would a non-technical person solve
> this problem?
>
> bob wyman
>
>

[Bob Wyman]

On Wed, Jul 30, 2008 at 4:37 PM, Ayende Rahien <ayende (AT) ayende (DOT) com> wrote:
> At the end user UI, this is a simple issue,
> associate an icon with each service, which
> doesn't take a lot of room.
> Or use Susan (twitter.com)

To associate an icon with each service, you would first need to know all
possible services. But, in a federated system, it is unlikely that you could
know this since not everyone will know all services that are federating at
any one moment. Can you imagine that your idea of using icons would work for
email? (I don't think so.) You might build some sort of "icon fetching
service" but that would be a mess. (You'd have connectivity issues, problem
with unregistered icons, etc.) As a result, what you're probably forced to
do is something like what we have in email today:

Susan <susan (AT) good (DOT) com>

But, since that is the display convention, why not use it as the input
convention as well? Users will appreciate the symmetry.

bob wyman

[Ayende Rahien]

twitter.com/favicon.gif solve this issue.
On Wed, Jul 30, 2008 at 11:50 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:

> On Wed, Jul 30, 2008 at 4:37 PM, Ayende Rahien <ayende (AT) ayende (DOT) com> wrote:
> > At the end user UI, this is a simple issue,
> > associate an icon with each service, which
> > doesn't take a lot of room.
> > Or use Susan (twitter.com)
>
> To associate an icon with each service, you would first need to know all
> possible services. But, in a federated system, it is unlikely that you could
> know this since not everyone will know all services that are federating at
> any one moment. Can you imagine that your idea of using icons would work for
> email? (I don't think so.) You might build some sort of "icon fetching
> service" but that would be a mess. (You'd have connectivity issues, problem
> with unregistered icons, etc.) As a result, what you're probably forced to
> do is something like what we have in email today:
>
> Susan <susan (AT) good (DOT) com>
>
> But, since that is the display convention, why not use it as the input
> convention as well? Users will appreciate the symmetry.
>
> bob wyman
>
>

[Dave Cridland]

On Wed Jul 30 20:44:18 2008, Bob Wyman wrote:
> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere
> <aconbere (AT) gmail (DOT) com> 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 "aconbere (AT) gmail (DOT) com".
>
> 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: anders (AT) foo (DOT) com and anders (AT) example (DOT) com (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 anders (AT) foo (DOT) com, because it's unqualified.

foo.com tells me @aFoo, because it happens to know that I have
expressed an interest in referring to anders (AT) foo (DOT) com as @aFoo.

I reply to @aFoo, and the reply goes to
Model, 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 "anders (AT) foo (DOT) com" 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:dave (AT) cridland (DOT) net - xmpp:dwd (AT) dave (DOT) cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Henry H]

I thought the original problem was the truncation of the limited message
size due to dealing with identifying the sender.

You can add whatever you want to the end (e.g. the domain name) and that
will resolve your identification issue. This won't solve the truncation
issue in anyway so I'm not sure what we're trying to solve here.

SMS limits you to 140 characters.
You can use some of those characters to identify a sender - I think you want
to use the least amount of characters to do this. Whatever your solution
entails will result in 140 - (# of characters needed to identify user) = #
of characters leftover for message

If we start bringing in icons - we're talking about things that are totally
out of the realm of SMS messaging. Can you pass icons in SMS messages?
No. We're now meshing a solution which assumes a certain client into the
discussion which distracts from the constraint of the SMS message. If you
wanted to have icons - then how would a client know which icon to display?
If you were using the SMS message as the transport, you would have to use
part of the 140 message limit to pass some identification. Same issue as
before.

If you want to solve the issue - lose the SMS constraint. Otherwise it's
just a discussion on trade-offs in usability (how user-friendly is it?)
versus functionality (how many characters can I have in a message? How do I
deal with truncation of messages?)

At some points given the length of usernames and domains, you'll have to
place SOME limit on it or you may find yourself without space for your
message (again if you want to stick to the 140 character world of SMS).


Need to rewire the context (e.g. not SMS) if you want to talk about better
solutions than what's been discussed.

On Wed, Jul 30, 2008 at 3:50 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:

> On Wed, Jul 30, 2008 at 4:37 PM, Ayende Rahien <ayende (AT) ayende (DOT) com> wrote:
> > At the end user UI, this is a simple issue,
> > associate an icon with each service, which
> > doesn't take a lot of room.
> > Or use Susan (twitter.com)
>
> To associate an icon with each service, you would first need to know all
> possible services. But, in a federated system, it is unlikely that you could
> know this since not everyone will know all services that are federating at
> any one moment. Can you imagine that your idea of using icons would work for
> email? (I don't think so.) You might build some sort of "icon fetching
> service" but that would be a mess. (You'd have connectivity issues, problem
> with unregistered icons, etc.) As a result, what you're probably forced to
> do is something like what we have in email today:
>
> Susan <susan (AT) good (DOT) com>
>
> But, since that is the display convention, why not use it as the input
> convention as well? Users will appreciate the symmetry.
>
> bob wyman
>
>

[Henry H]

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 Bob (AT) twitter (DOT) com or Bob (AT) foo (DOT) com 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 <dave (AT) cridland (DOT) net> wrote:

> On Wed Jul 30 20:44:18 2008, Bob Wyman wrote:
>
>> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere (AT) gmail (DOT) com>
>> 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 "aconbere (AT) gmail (DOT) com".
>>
>> 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: anders (AT) foo (DOT) com and anders (AT) example (DOT) com (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 anders (AT) foo (DOT) com, because it's unqualified.
>
> foo.com tells me @aFoo, because it happens to know that I have expressed
> an interest in referring to anders (AT) foo (DOT) com 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 "anders (AT) foo (DOT) com"
> 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:dave (AT) cridland (DOT) net - xmpp:dwd (AT) dave (DOT) cridland.net<xmpp%3Adwd (AT) dave (DOT) cridland.net>
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>

[Bob Wyman]

On Wed, Jul 30, 2008 at 5:15 PM, Henry H <appleman (AT) gmail (DOT) com> 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 Susan (AT) good (DOT) com and Susan (AT) bad (DOT) com -- 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 Susan (AT) bad (DOT) com from Susan (AT) good (DOT) com based
on icon, however, the information you use to distinguish them is not useful
if you are attempting to send them a message.

bob wyman

[Henry H]

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 name (AT) domain (DOT) com and the key assumption is name is
unique within a domain.



On Wed, Jul 30, 2008 at 4:28 PM, Bob Wyman <bob (AT) wyman (DOT) us> wrote:

> On Wed, Jul 30, 2008 at 5:15 PM, Henry H <appleman (AT) gmail (DOT) com> 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 Susan (AT) good (DOT) com and Susan (AT) bad (DOT) com -- 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 Susan (AT) bad (DOT) com from Susan (AT) good (DOT) combased on icon, however, the information you use to distinguish them is not
> useful if you are attempting to send them a message.
>
> bob wyman
>
>

[Adam Fields]

On Wed, Jul 30, 2008 at 05:46:02PM -0500, Henry H wrote:
> 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 name (AT) domain (DOT) com and the key assumption is name is
> unique within a domain.

There are actually two problems here:

1) How to indicate that an otherwise unformatted message is a "reply"
instead of a standalone pronouncement.

2) How to address that reply.

I think the twitter solution of @replies isn't bad for #1. For #2, it
clearly suffers from the domain problems we've discussed, but also
suffers internally to twitter in that you can't address a reply to a
specific message but only to a specific person. As an outsider to the
conversation, I'm often left wondering what any given reply is in
reference to, and also often finding that I don't care enough to dig
through the entire stream to find out.

--
- Adam

** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.adamfields.com ]

[ http://www.morningside-analytics.com ] .. Latest Venture
[ http://www.confabb.com ] ................ Founder
[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki

[Henry H]

I don't think that was the original problem that kicked off this discussion,
but perhaps we can go down those rabbit holes in a different thread :-)

On Wed, Jul 30, 2008 at 6:44 PM, Adam Fields <sociallist45098 (AT) aquick (DOT) org>wrote:

> On Wed, Jul 30, 2008 at 05:46:02PM -0500, Henry H wrote:
> > 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 name (AT) domain (DOT) com and the key assumption is name is
> > unique within a domain.
>
> There are actually two problems here:
>
> 1) How to indicate that an otherwise unformatted message is a "reply"
> instead of a standalone pronouncement.
>
> 2) How to address that reply.
>
> I think the twitter solution of @replies isn't bad for #1. For #2, it
> clearly suffers from the domain problems we've discussed, but also
> suffers internally to twitter in that you can't address a reply to a
> specific message but only to a specific person. As an outsider to the
> conversation, I'm often left wondering what any given reply is in
> reference to, and also often finding that I don't care enough to dig
> through the entire stream to find out.
>
> --
> - Adam
>
> ** Expert Technical Project and Business Management
> **** System Performance Analysis and Architecture
> ****** [ http://www.adamfields.com ]
>
> [ http://www.morningside-analytics.com ] .. Latest Venture
> [ http://www.confabb.com ] ................ Founder
> [ http://www.aquick.org/blog ] ............ Blog
> [ http://www.adamfields.com/resume.html ].. Experience
> [ http://www.flickr.com/photos/fields ] ... Photos
> [ http://www.aquicki.com/wiki ].............Wiki
>

[fireun ukobach]

My original impression of user (AT) jabber (DOT) com/resource was that the
/resource designated what kind of service you were requesting a dialog
with. So maybe I dont see the real question here, but wouldnt
user (AT) jabber (DOT) org/twitter be a way to handshake through to the right
kind of subscription service? Sorry if I'm off the idea, I'm not sure
what I've read so far really states the problem succinctly.

user@system (AT) domain (DOT) com is really, really stupid. IMHO. You will never
get user conformity on that.

cheers,
-=C=-

[Steve Ivy]

A couple other thoughts:

* the format needs to be easy to *type*, especially on a phone.
* the user may not remember where their contact originated - i.e.,
I may not remember if I subscribed to factoryjoe (AT) twitter (DOT) com or
factoryjoe (AT) factoryjoe (DOT) com.

--Steve


On Wed, Jul 30, 2008 at 4:44 PM, Adam Fields <sociallist45098 (AT) aquick (DOT) org> wrote:
> On Wed, Jul 30, 2008 at 05:46:02PM -0500, Henry H wrote:
>> 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 name (AT) domain (DOT) com and the key assumption is name is
>> unique within a domain.
>
> There are actually two problems here:
>
> 1) How to indicate that an otherwise unformatted message is a "reply"
> instead of a standalone pronouncement.
>
> 2) How to address that reply.
>
> I think the twitter solution of @replies isn't bad for #1. For #2, it
> clearly suffers from the domain problems we've discussed, but also
> suffers internally to twitter in that you can't address a reply to a
> specific message but only to a specific person. As an outsider to the
> conversation, I'm often left wondering what any given reply is in
> reference to, and also often finding that I don't care enough to dig
> through the entire stream to find out.
>
> --
> - Adam
>
> ** Expert Technical Project and Business Management
> **** System Performance Analysis and Architecture
> ****** [ http://www.adamfields.com ]
>
> [ http://www.morningside-analytics.com ] .. Latest Venture
> [ http://www.confabb.com ] ................ Founder
> [ http://www.aquick.org/blog ] ............ Blog
> [ http://www.adamfields.com/resume.html ].. Experience
> [ http://www.flickr.com/photos/fields ] ... Photos
> [ http://www.aquicki.com/wiki ].............Wiki
>



--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Lachlan Hardy]

I don't have a solution to federated identity referencing (yet), but there
are a bunch of historical and technical misconceptions here that I think
might be muddying things a bit. I'm a bit pushed today so this is off the
top of the head, rather than referenced - some timings might be a little off
etc.

The standard character limit for SMSes in Latin alphabet is 160 characters.
(I think it's 70 characters in Chinese - not sure about other languages.)

Sometime in late 2006, Twitter changed their character limits to allow for
additional flexibility. They had been reserving 5 characters for application
commands, but they increased that to 20 to encapsulate usernames (which they
simultaneously limited to a maximum of 15 characters). This is what gives us
the 140 character limit.

When building systems that similarly allow SMS communication, I think that's
a pretty good model.

The other major factor misconception I think folks in this thread have been
missing is this:
Twitter didn't invent the @ convention. They simply codified it (literally).

Late 2006 - early 2007, my circle of folks on Twitter expanded to such a
size that the nature of our communications changed. There began to be
multiple discrete conversations at once (rather than one group conversation)
and people started looking for methods to make sense of it. They adopted the
@ reply convention (which has been used in many other places as an
identifier - certainly Flickr and many forums I've seen. And email in the
70s, apparently - cool, I didn't know that!).

In February or so of 2007, Twitter started linking those @ replies to the
most recent tweet by that person. I can't remember if they started linking
in-body references at the same time or not.

The point is this: @ replies are not an arbitrary innovation by Twitter -
they simply paved the cowpaths. I'd suggest we're pretty stuck with that
format for now.

Having said all of that, I'm currently most interested in the feasibility of
individual aliasing á la XMPP nicknames. If my client/service abstracts that
alias for me, but uses the full XMPP address to communicate with other
services (which then need to translate the address to the appropriate local
alias), what are the problems with that?

I already see a few, such as the one Bob mentions above with previosuly
unknown IDs, but so far it seems the most workable option of those mentioned
here.

Lachlan Hardy

[Sylvain Hellegouarch]

> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere (AT) gmail (DOT) com>
> 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 "aconbere (AT) gmail (DOT) com".
>
> 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: anders (AT) foo (DOT) com and anders (AT) example (DOT) com (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.
>
> bob wyman
>

I've read the whole thread and tried to understand the problem at hand but
still failing. How is the use case above different from having two mobile
numbers associated with your alias Anders? When replying you, as a user,
make the decision to which number respond if you will.

In any case if the user just hit reply, it'll go back to the SMS server
that would know what was the originating service of the first message and
thus would be able to route the response accordingly.

- Sylvain

--
Sylvain Hellegouarch
http://www.defuze.org

[Alexander Gnauck]

> I've read the whole thread and tried to understand the problem at hand
but
> still failing. How is the use case above different from having two mobile
> numbers associated with your alias Anders? When replying you, as a user,
> make the decision to which number respond if you will.
>
> In any case if the user just hit reply, it'll go back to the SMS server
> that would know what was the originating service of the first message and
> thus would be able to route the response accordingly.

no, there is running one SMS service/gateway on the xmpp server which is
sending all the SMS messages on behalf of the users. So the sender will be
always the same number.

Alex

[Pedro Melo]

On Jul 30, 2008, at 8:44 PM, Bob Wyman wrote:

> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere
> <aconbere (AT) gmail (DOT) com> 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 "aconbere (AT) gmail (DOT) com".
>
> 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: anders (AT) foo (DOT) com and
> anders (AT) example (DOT) com (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 understand you original problem but in this case I expect to
receive the SMS with the @alias I gave to each of those users in my
address book, falling back to the full address if none was set. I
would also expect the phone number from which the SMS was sent to be
unique and tied to that address entry so that a simple SMS reply
would send it to the proper recipient.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!

[Jean-Marc Liotier]

Also sprach Henry H [Wed, Jul 30, 2008 at 02:57:50PM -0500] :
>
> These are limitations of the SMS protocol (140 character limit)
> [..]

Actually the GSM specification is 160 characters per message. And that
is merely a restriction at protocol level : at the application level,
most modern GSM terminals are capable of slicing a message of usually up
to 800 characters in up to five messages as necessary, and that is
transparent to users at both ends. Of course there is the issue that SMS
is still often billed according to usage - but that is not a technical
issue.

[Sylvain Hellegouarch]

>> I've read the whole thread and tried to understand the problem at hand
> but
>> still failing. How is the use case above different from having two
>> mobile
>> numbers associated with your alias Anders? When replying you, as a user,
>> make the decision to which number respond if you will.
>>
>> In any case if the user just hit reply, it'll go back to the SMS server
>> that would know what was the originating service of the first message
>> and
>> thus would be able to route the response accordingly.
>
> no, there is running one SMS service/gateway on the xmpp server which is
> sending all the SMS messages on behalf of the users. So the sender will be
> always the same number.
>

I'm not fluent with the SMS protocol but aren't SMS tagged with a unique
id for each message? In such case the SMS gateway knows which reply goes
to which originating SMS message. Couldn't the SMS gateway also track
which was the JID associated with the originating SMS? It seems to me that
if the SMS gateway can translate a XMPP message to a SMS it can do the
other way around and probably has all the cards to perform the mapping
both ways.

- Sylvain

--
Sylvain Hellegouarch
http://www.defuze.org

[Jean-Marc Liotier]

Also sprach Bob Wyman [Wed, Jul 30, 2008 at 01:26:13PM -0400] :
>
> So, we now have a system that requires that domain name be part of
> EVERY email address

Actually it is only required for domain routing. Locally, domainless adresses
remain accepted by most mail transfer agents. For example, by default Postfix
is configured with append_dot_mydomain=yes so that the local domain name is
appended to the recipient of locally submitted mail with no domain information.

Local mail routing with just the user name has survived to this day - people
who need it use it happily and the immense majority of the other users is
blissfuly unaware of it. It worked for email - I believe it could work for
other messaging protocols too.

[Jean-Marc Liotier]

Also sprach Sylvain Hellegouarch [Thu, Jul 31, 2008 at 11:03:29AM +0200] :
>
> I'm not fluent with the SMS protocol but aren't SMS tagged with a unique
> id for each message ?

No - nothing like that.

cf. http://www.dreamfabric.com/sms/

[Jean-Marc Liotier]

Also sprach Jean-Marc Liotier [Thu, Jul 31, 2008 at 11:08:42AM +0200] :
> Also sprach Henry H [Wed, Jul 30, 2008 at 02:57:50PM -0500] :
> >
> > These are limitations of the SMS protocol (140 character limit)
> > [..]
>
> Actually the GSM specification is 160 characters per message. And that
> is merely a restriction at protocol level : at the application level,
> most modern GSM terminals are capable of slicing a message of usually up
> to 800 characters in up to five messages as necessary, and that is
> transparent to users at both ends. Of course there is the issue that SMS
> is still often billed according to usage - but that is not a technical
> issue.

Ok - before anyone nitpicks... It is 160 if you encode on seven bit, but
if you want eight bit encoding then it is 140... So let's say 140 since
I guess we want support of alphabets other than latin...

[Sylvain Hellegouarch]

> Also sprach Sylvain Hellegouarch [Thu, Jul 31, 2008 at 11:03:29AM +0200] :
>>
>> I'm not fluent with the SMS protocol but aren't SMS tagged with a unique
>> id for each message ?
>
> No - nothing like that.
>
> cf. http://www.dreamfabric.com/sms/
>

Thanks for the link. I wasn't aware of that. Well there goes my theory of
tracking messages.

- Sylvain

--
Sylvain Hellegouarch
http://www.defuze.org

[Pedro Melo]

Hi,

On Jul 31, 2008, at 9:15 AM, Alexander Gnauck wrote:

>> I've read the whole thread and tried to understand the problem at
>> hand
> but
>> still failing. How is the use case above different from having two
>> mobile
>> numbers associated with your alias Anders? When replying you, as a
>> user,
>> make the decision to which number respond if you will.
>>
>> In any case if the user just hit reply, it'll go back to the SMS
>> server
>> that would know what was the originating service of the first
>> message and
>> thus would be able to route the response accordingly.
>
> no, there is running one SMS service/gateway on the xmpp server
> which is
> sending all the SMS messages on behalf of the users. So the sender
> will be
> always the same number.

That's implementation dependent. For example, SAPO SMS gateway gives
one SMS number per JID. You can reply to the SMSs and they will show
up in the XMPP client.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!

[Pedro Melo]

Hi,

On Jul 30, 2008, at 6:26 PM, Bob Wyman 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: @foo (AT) twitter (DOT) com and @foo (AT) indenti (DOT) ca.

I've though more about this. I don't think @nick will break, *if* we
accept that @nick is a local dialog between a user and its uBSP (micro-
blogging service provider).

In a federated world clearly the full address, like pedromelo (AT) twitter (DOT) com
, must be used to identify the source. But uBSP's should have the
ability to rewrite messages transforming those addresses to local
aliases in the form of @nick.

If I receive a uB notification from bwyman (AT) some (DOT) provider.com at my
twitter account, and I have a uB buddy with that address named "bob",
is that such a no-no-don't-do-that action to rewrite the message to
@bob when I get it?

This seems to me as a local decision.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!

[Henry H]

For late joiners THREAD SUMMARY

We need a way to identify people across a federated microblogging /
messaging platform (e.g across Twitter, Identica, etc.)
@name convention is too limiting - only works in a single platform /
truncates messages in SMS
Why not use aliases? They are user friendly and assignable by the user
Aliases doesn't take care of new people trying to send you messages
@name convention is not the limitation, SMS protocol is (140 characters)
Well what about tracking people across a federated environment? Can't do
that with aliases!
<insert tangential conversations about using icons + attempt to bring
conversation back to original question>
SMS number could be used but painful for users to memorize; also given
expense of assigning SMS number for every userID - not viable
No - the real problem is being able to do replies to the correct thread.
It would be nice to have the something user friendly
name@domain is a good way to identify people
@name@domain is ugly
Can you use SMS headers to identify replies? No. Okay, thanks!
@name convention doesn't belong to Twitter, but they started using it so
we're stuck with it (are we?)
SMS limit is 160 characters in Latin
SMS messages can actually be up to 800 characters and broken across 5
messages
SMS limit is 140 for all practical purposes unless everyone wants to speak
in latin
There is an SMS gateway that can assign an SMS per JID - not a technology
limitation
Use name@domain under the covers to identify and let the local service
handle translations to aliases, shorter names, etc.

Did I miss anything? Aren't email threads great?

[Blaine Cook]

I've been following the thread, but this seems like an appropriate place to
jump in.

On Thu, Jul 31, 2008 at 5:34 AM, Henry H <appleman (AT) gmail (DOT) com> wrote:
>
> For late joiners THREAD SUMMARY
>
> We need a way to identify people across a federated microblogging /
> messaging platform (e.g across Twitter, Identica, etc.)
>

This assumes that we already have a method for identifying people across
networks (e.g., using email / jid semantics). To rephrase the goal, we need
a way to *reply* to people across federated networks.

I'll argue that until we have said federated networks, this is a moot point
(c.f., the @reply convention in twitter was, as Lachlan said, only codified
once people using the service had actually used @replies. Alternative forms
that were (possibly still are) accepted by twitter are "name: " and "r name
"). My claim is that emergent behaviour should be observed and codified once
a federated system exists, not before.

@name convention is too limiting - only works in a single platform /
> truncates messages in SMS
> Why not use aliases? They are user friendly and assignable by the user
> Aliases doesn't take care of new people trying to send you messages
> @name convention is not the limitation, SMS protocol is (140 characters)
> Well what about tracking people across a federated environment? Can't do
> that with aliases!
> <insert tangential conversations about using icons + attempt to bring
> conversation back to original question>
>

I will point out that we should build the basics, and then expand upon ideas
once we have groundwork to expand upon. All of this is pure speculation.

SMS number could be used but painful for users to memorize; also given
> expense of assigning SMS number for every userID - not viable
>

Note that users are never referred to by their phone numbers in Twitter. I
don't even know the phone numbers of my closest friends and co-workers any
more (my phone and twitter does, though).

No - the real problem is being able to do replies to the correct thread.
> It would be nice to have the something user friendly
> name@domain is a good way to identify people
>

Agreed.

@name@domain is ugly
>

Agreed.

@name convention doesn't belong to Twitter, but they started using it so
> we're stuck with it (are we?)
>

No, we're not. Usage of @name is very limited compared to total usage. @name
could have been implemented with a simple "reply" button (and I think this
is actually done now, albeit by cheating and using javascript to fill in
@name at the beginning of an update).


> SMS limit is 160 characters in Latin
> SMS messages can actually be up to 800 characters and broken across 5
> messages
> SMS limit is 140 for all practical purposes unless everyone wants to speak
> in latin
>

Some clarification on this. SMS messages are limited to 140 bytes. The ETSI
GSM 03.38 character set specifies a 7-bit partial latin encoding (160
characters), with an "extended bit" to get some additional characters
(potentially limiting the message to 140 characters when using GSM 03.38).
It's also possible to send SMS messages using the UCS-2 encoding (UTF-16),
which allows for 67 characters per message. However, it's also possible to
concatenate messages using the User Data Header, which allows for
potentially unlimited length messages, but phone / carrier support for
concatenated messages is spotty. There's a good write-up on this topic here:

http://blog.nowsms.com/2007/06/long-sms-text-messages-and-160.html

FWIW, twitter's decision to do 140 characters was based on:

18 characters for username (now 15) + 1 character for the ":" + 1 character
for the space " " + 140 characters for the update = 160 characters.

There is an SMS gateway that can assign an SMS per JID - not a technology
> limitation
>

Probably easier would be JID to SMS --- any Jabber server can do it, and
generally you only need to do SMS to email for an individual's purposes.

b.

[Henry H]

I'm of the opinion that all devices will come with IM clients supporting
XMPP with always on Internet connectivity so collectively we're spending WAY
too much time discussion solutions in the SMS constraint of 140 bytes.

SMS is the new carrier pigeon. Everything else Blaine wrote is right on
with how I think about it.

On Thu, Jul 31, 2008 at 12:13 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:

> I've been following the thread, but this seems like an appropriate place to
> jump in.
>
> On Thu, Jul 31, 2008 at 5:34 AM, Henry H <appleman (AT) gmail (DOT) com> wrote:
>
>> For late joiners THREAD SUMMARY
>>
>> We need a way to identify people across a federated microblogging /
>> messaging platform (e.g across Twitter, Identica, etc.)
>>
>
> This assumes that we already have a method for identifying people across
> networks (e.g., using email / jid semantics). To rephrase the goal, we need
> a way to *reply* to people across federated networks.
>
> I'll argue that until we have said federated networks, this is a moot point
> (c.f., the @reply convention in twitter was, as Lachlan said, only codified
> once people using the service had actually used @replies. Alternative forms
> that were (possibly still are) accepted by twitter are "name: " and "r name
> "). My claim is that emergent behaviour should be observed and codified once
> a federated system exists, not before.
>
> @name convention is too limiting - only works in a single platform /
>> truncates messages in SMS
>> Why not use aliases? They are user friendly and assignable by the user
>> Aliases doesn't take care of new people trying to send you messages
>> @name convention is not the limitation, SMS protocol is (140 characters)
>> Well what about tracking people across a federated environment? Can't do
>> that with aliases!
>> <insert tangential conversations about using icons + attempt to bring
>> conversation back to original question>
>>
>
> I will point out that we should build the basics, and then expand upon
> ideas once we have groundwork to expand upon. All of this is pure
> speculation.
>
> SMS number could be used but painful for users to memorize; also given
>> expense of assigning SMS number for every userID - not viable
>>
>
> Note that users are never referred to by their phone numbers in Twitter. I
> don't even know the phone numbers of my closest friends and co-workers any
> more (my phone and twitter does, though).
>
> No - the real problem is being able to do replies to the correct thread.
>> It would be nice to have the something user friendly
>> name@domain is a good way to identify people
>>
>
> Agreed.
>
> @name@domain is ugly
>>
>
> Agreed.
>
> @name convention doesn't belong to Twitter, but they started using it so
>> we're stuck with it (are we?)
>>
>
> No, we're not. Usage of @name is very limited compared to total usage.
> @name could have been implemented with a simple "reply" button (and I think
> this is actually done now, albeit by cheating and using javascript to fill
> in @name at the beginning of an update).
>
>
>> SMS limit is 160 characters in Latin
>> SMS messages can actually be up to 800 characters and broken across 5
>> messages
>> SMS limit is 140 for all practical purposes unless everyone wants to speak
>> in latin
>>
>
> Some clarification on this. SMS messages are limited to 140 bytes. The ETSI
> GSM 03.38 character set specifies a 7-bit partial latin encoding (160
> characters), with an "extended bit" to get some additional characters
> (potentially limiting the message to 140 characters when using GSM 03.38).
> It's also possible to send SMS messages using the UCS-2 encoding (UTF-16),
> which allows for 67 characters per message. However, it's also possible to
> concatenate messages using the User Data Header, which allows for
> potentially unlimited length messages, but phone / carrier support for
> concatenated messages is spotty. There's a good write-up on this topic here:
>
> http://blog.nowsms.com/2007/06/long-sms-text-messages-and-160.html
>
> FWIW, twitter's decision to do 140 characters was based on:
>
> 18 characters for username (now 15) + 1 character for the ":" + 1 character
> for the space " " + 140 characters for the update = 160 characters.
>
> There is an SMS gateway that can assign an SMS per JID - not a technology
>> limitation
>>
>
> Probably easier would be JID to SMS --- any Jabber server can do it, and
> generally you only need to do SMS to email for an individual's purposes.
>
> b.
>

[Blaine Cook]

Agreed ;-) I argued that SMS would be dead by 2008. That certainly hasn't
happened yet, but it's on its way with the iPhone, particularly in Canada
and other countries where SMS charges are high and getting more expensive,
and data charges are trending towards low capped limits.
b.

On Thu, Jul 31, 2008 at 11:32 AM, Henry H <appleman (AT) gmail (DOT) com> wrote:

> I'm of the opinion that all devices will come with IM clients supporting
> XMPP with always on Internet connectivity so collectively we're spending WAY
> too much time discussion solutions in the SMS constraint of 140 bytes.
>
> SMS is the new carrier pigeon. Everything else Blaine wrote is right on
> with how I think about it.
>
>
> On Thu, Jul 31, 2008 at 12:13 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
>
>> I've been following the thread, but this seems like an appropriate place
>> to jump in.
>>
>> On Thu, Jul 31, 2008 at 5:34 AM, Henry H <appleman (AT) gmail (DOT) com> wrote:
>>
>>> For late joiners THREAD SUMMARY
>>>
>>> We need a way to identify people across a federated microblogging /
>>> messaging platform (e.g across Twitter, Identica, etc.)
>>>
>>
>> This assumes that we already have a method for identifying people across
>> networks (e.g., using email / jid semantics). To rephrase the goal, we need
>> a way to *reply* to people across federated networks.
>>
>> I'll argue that until we have said federated networks, this is a moot
>> point (c.f., the @reply convention in twitter was, as Lachlan said, only
>> codified once people using the service had actually used @replies.
>> Alternative forms that were (possibly still are) accepted by twitter are
>> "name: " and "r name "). My claim is that emergent behaviour should be
>> observed and codified once a federated system exists, not before.
>>
>> @name convention is too limiting - only works in a single platform /
>>> truncates messages in SMS
>>> Why not use aliases? They are user friendly and assignable by the user
>>> Aliases doesn't take care of new people trying to send you messages
>>> @name convention is not the limitation, SMS protocol is (140 characters)
>>> Well what about tracking people across a federated environment? Can't do
>>> that with aliases!
>>> <insert tangential conversations about using icons + attempt to bring
>>> conversation back to original question>
>>>
>>
>> I will point out that we should build the basics, and then expand upon
>> ideas once we have groundwork to expand upon. All of this is pure
>> speculation.
>>
>> SMS number could be used but painful for users to memorize; also given
>>> expense of assigning SMS number for every userID - not viable
>>>
>>
>> Note that users are never referred to by their phone numbers in Twitter. I
>> don't even know the phone numbers of my closest friends and co-workers any
>> more (my phone and twitter does, though).
>>
>> No - the real problem is being able to do replies to the correct thread.
>>> It would be nice to have the something user friendly
>>> name@domain is a good way to identify people
>>>
>>
>> Agreed.
>>
>> @name@domain is ugly
>>>
>>
>> Agreed.
>>
>> @name convention doesn't belong to Twitter, but they started using it so
>>> we're stuck with it (are we?)
>>>
>>
>> No, we're not. Usage of @name is very limited compared to total usage.
>> @name could have been implemented with a simple "reply" button (and I think
>> this is actually done now, albeit by cheating and using javascript to fill
>> in @name at the beginning of an update).
>>
>>
>>> SMS limit is 160 characters in Latin
>>> SMS messages can actually be up to 800 characters and broken across 5
>>> messages
>>> SMS limit is 140 for all practical purposes unless everyone wants to
>>> speak in latin
>>>
>>
>> Some clarification on this. SMS messages are limited to 140 bytes. The
>> ETSI GSM 03.38 character set specifies a 7-bit partial latin encoding (160
>> characters), with an "extended bit" to get some additional characters
>> (potentially limiting the message to 140 characters when using GSM 03.38).
>> It's also possible to send SMS messages using the UCS-2 encoding (UTF-16),
>> which allows for 67 characters per message. However, it's also possible to
>> concatenate messages using the User Data Header, which allows for
>> potentially unlimited length messages, but phone / carrier support for
>> concatenated messages is spotty. There's a good write-up on this topic here:
>>
>> http://blog.nowsms.com/2007/06/long-sms-text-messages-and-160.html
>>
>> FWIW, twitter's decision to do 140 characters was based on:
>>
>> 18 characters for username (now 15) + 1 character for the ":" + 1
>> character for the space " " + 140 characters for the update = 160
>> characters.
>>
>> There is an SMS gateway that can assign an SMS per JID - not a
>>> technology limitation
>>>
>>
>> Probably easier would be JID to SMS --- any Jabber server can do it, and
>> generally you only need to do SMS to email for an individual's purposes.
>>
>> b.
>>
>
>

[Dave Cridland]

On Thu Jul 31 18:13:47 2008, Blaine Cook wrote:
> I'll argue that until we have said federated networks, this is a
> moot point
> (c.f., the @reply convention in twitter was, as Lachlan said, only
> codified
> once people using the service had actually used @replies.
> Alternative forms
> that were (possibly still are) accepted by twitter are "name: " and
> "r name
> "). My claim is that emergent behaviour should be observed and
> codified once
> a federated system exists, not before.
>
>
I'll go along with that - you're essentially saying that the
user-driven syntax of replies is a property of the interface, not the
protocol, so really, whether we choose @...@... or [http://...] or
BANANA! BANANA! YIMBO! PITOW! ... BANANA! (the latter being, frankly,
my personal favourite based on æsthetic reasons) matters little to
the protocol. At the protocol level, we simply need fully qualified,
globally unique, names - we need to agree on the form of those names,
and how to encode them for machine readability, but otherwise how
they're formatted to the end-user has no impact to the protocol.

There's a thumping great impact on the interface, of course, and user
expectation will lean toward consistent interfaces, but this will, as
Blaine says, come out in the wash, and meanwhile, interface ease of
use will be a strong differentiating factor.

I mean, sorry, lightweight semantic markups used by user interfaces
to instances of the federated microblogosphere are a clear instance
of emergent behaviour. (Do I get a prize for that many buzzwords?)

> I will point out that we should build the basics, and then expand
> upon ideas
> once we have groundwork to expand upon. All of this is pure
> speculation.

Which is why anyone can have an opinion, even me. :-)

> No - the real problem is being able to do replies to the correct
> thread.

Impractical, or impossible, for some interfaces, including SMS. But
this is okay, this is why we have XMPP user interfaces, and tell
people to use XMPP clients on their phones. Or email. Or whatever.

Or, maybe there's a really clever classifier handling incoming SMS
messages and matching them up by subject material to SMS messages
it's sent the user.

Or maybe someone decides that telling users how to use a bunch of
cryptic symbols in SMS messages is going to be more fun.

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) dave (DOT) cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Nick Vidal]

Ideally the namespace will be very personal.

And you'll be connected peer-to-peer style.

Example:

In my contacts there will simply be:

debbie
alias debbie (AT) iss (DOT) im

If debbie changes to new.im, it isn't a problem. I simply update:

debbie
alias debbie (AT) new (DOT) im

I'm subscribed to a stream of information from friends.
These reside in my own domain and devices.

If I change domain, this ain't a problem neither. My peers are kept aware.
Everyone updates:

nick
alias nick (AT) new (DOT) im

The key concept is this: my identity is my network. This is what works in
the real world. What identifies you is your friends and family.

Your identity and your information is preserved.

It doesn't matter if you are @iss.im, @new.im, @whatever.im

You will still be just "nick" in your personal network.

Best regards,
Nick Vidal

On Thu, Jul 31, 2008 at 4:06 PM, Dave Cridland <dave (AT) cridland (DOT) net> wrote:

> On Thu Jul 31 18:13:47 2008, Blaine Cook wrote:
>
>> I'll argue that until we have said federated networks, this is a moot
>> point
>> (c.f., the @reply convention in twitter was, as Lachlan said, only
>> codified
>> once people using the service had actually used @replies. Alternative
>> forms
>> that were (possibly still are) accepted by twitter are "name: " and "r
>> name
>> "). My claim is that emergent behaviour should be observed and codified
>> once
>> a federated system exists, not before.
>>
>>
>> I'll go along with that - you're essentially saying that the user-driven
> syntax of replies is a property of the interface, not the protocol, so
> really, whether we choose @...@... or [http://...] or BANANA! BANANA!
> YIMBO! PITOW! ... BANANA! (the latter being, frankly, my personal favourite
> based on æsthetic reasons) matters little to the protocol. At the protocol
> level, we simply need fully qualified, globally unique, names - we need to
> agree on the form of those names, and how to encode them for machine
> readability, but otherwise how they're formatted to the end-user has no
> impact to the protocol.
>
> There's a thumping great impact on the interface, of course, and user
> expectation will lean toward consistent interfaces, but this will, as Blaine
> says, come out in the wash, and meanwhile, interface ease of use will be a
> strong differentiating factor.
>
> I mean, sorry, lightweight semantic markups used by user interfaces to
> instances of the federated microblogosphere are a clear instance of emergent
> behaviour. (Do I get a prize for that many buzzwords?)
>
> I will point out that we should build the basics, and then expand upon
>> ideas
>> once we have groundwork to expand upon. All of this is pure speculation.
>>
>
> Which is why anyone can have an opinion, even me. :-)
>
> No - the real problem is being able to do replies to the correct thread.
>>
>
> Impractical, or impossible, for some interfaces, including SMS. But this is
> okay, this is why we have XMPP user interfaces, and tell people to use XMPP
> clients on their phones. Or email. Or whatever.
>
> Or, maybe there's a really clever classifier handling incoming SMS messages
> and matching them up by subject material to SMS messages it's sent the user.
>
> Or maybe someone decides that telling users how to use a bunch of cryptic
> symbols in SMS messages is going to be more fun.
>
>
> Dave.
> --
> Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) dave (DOT) cridland.net<xmpp%3Adwd (AT) dave (DOT) cridland.net>
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>

[Adam Fields]

On Thu, Jul 31, 2008 at 08:06:10PM +0100, Dave Cridland wrote:
[...]
> >No - the real problem is being able to do replies to the correct
> >thread.
>
> Impractical, or impossible, for some interfaces, including SMS. But
> this is okay, this is why we have XMPP user interfaces, and tell
> people to use XMPP clients on their phones. Or email. Or whatever.
>
> Or, maybe there's a really clever classifier handling incoming SMS
> messages and matching them up by subject material to SMS messages
> it's sent the user.
>
> Or maybe someone decides that telling users how to use a bunch of
> cryptic symbols in SMS messages is going to be more fun.

This was my point originally, and I really think it's critical to the
scaling/federation discussion. Imagine email with no subject lines
(and secondarily, with no In-Reply-To header, though I'm given to
believe that there are still people who don't use threaded
mailreaders). Using that to communicate with more than a handful of
people would very quickly become unmanageable.

There's a difference between enforcing a micromessaging format as an
explicit constraint on users for brevity and trying to shoehorn decent
metadata into a message size that's too small to practically support
modern constructs while maintaining compatibility with outdated
applications.

Protocol designers can go far to try to accomodate everyone, but at a
certain point, users have to be punished for trying to fit their
outdated clients into the context of the larger conversation. I'm
willing to bet that the number of people complaining that they can't
get twitter updates on their beepers is small. "Plain" SMS devices
will eventually go the same way.

--
- Adam

** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.adamfields.com ]

[ http://www.morningside-analytics.com ] .. Latest Venture
[ http://www.confabb.com ] ................ Founder
[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki

[Lachlan Hardy]

> Agreed ;-) I argued that SMS would be dead by 2008. That certainly hasn't
> happened yet, but it's on its way with the iPhone, particularly in Canada
> and other countries where SMS charges are high and getting more expensive,
> and data charges are trending towards low capped limits.

That may be true of North America, but y'all never really got into the
whole SMS thing. Take a look at Australia or New Zealand where text
messages have replaced phone calls between friends in many instances
and data costs more than its worth (there is *no* such thing as
unlimited data or even cheap data in Australia - certainly not over
mobile). Or some parts of Africa where folks don't own chargers, just
phones - to preserve battery life they leave their phones off and only
turn them on periodically to check for texts and reply.

Whether SMS is relevant to this discussion is a different matter, but
SMS isn't going anywhere for a long time.

Lachlan Hardy

[Peter Saint-Andre]

Lachlan Hardy wrote:
>> Agreed ;-) I argued that SMS would be dead by 2008. That certainly hasn't
>> happened yet, but it's on its way with the iPhone, particularly in Canada
>> and other countries where SMS charges are high and getting more expensive,
>> and data charges are trending towards low capped limits.
>
> That may be true of North America, but y'all never really got into the
> whole SMS thing. Take a look at Australia or New Zealand where text
> messages have replaced phone calls between friends in many instances
> and data costs more than its worth (there is *no* such thing as
> unlimited data or even cheap data in Australia - certainly not over
> mobile). Or some parts of Africa where folks don't own chargers, just
> phones - to preserve battery life they leave their phones off and only
> turn them on periodically to check for texts and reply.
>
> Whether SMS is relevant to this discussion is a different matter, but
> SMS isn't going anywhere for a long time.

Agreed. That and it's a $100 billion a year money-maker for the telcos.
SMS is here to stay.

But what the heck is this thread about anyway? I don't see a problem for
us to solve here, but maybe I'm missing something. :)

/psa

[Adam Fields]

On Thu, Jul 31, 2008 at 03:07:18PM -0600, Peter Saint-Andre wrote:
[...]
> But what the heck is this thread about anyway? I don't see a problem for
> us to solve here, but maybe I'm missing something. :)

I think the core question was "how do we build a unified addressing
scheme to use when every micro siloed messaging system can eventually
talk to every other one, while still taking into consideration the
limitations of all of them?".

--
- Adam

** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.adamfields.com ]

[ http://www.morningside-analytics.com ] .. Latest Venture
[ http://www.confabb.com ] ................ Founder
[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki

[Jean-Marc Liotier]

Also sprach Henry H [Thu, Jul 31, 2008 at 01:32:25PM -0500] :
> I'm of the opinion that all devices will come with IM clients
> supporting XMPP with always on Internet connectivity so collectively
> we're spending WAY too much time discussion solutions in the SMS
> constraint of 140 bytes.

Technically, I agree wholeheartedly. From a business point of view, I
work with operators and I they looove the ludicruous margins they make
on SMS, so even though in the age of ubiquitous GPRS, UMTS, Wifi and
Wimax they will still appreciate an infrastructure that encourages SMS
use even though it is an usability disaster. I would be in favor of
letting SMS service providers fend for themselves with whatever hack
they can come with to bridge SMS to the IM world, but if for strategic
business reason we need the specification to be mobile operator
friendly, thinking about SMS is not a bad idea. IMS is just now
beginning to take mindshare, and deployments will take years at least -
so for now we still have to accomodate the telco world.

[Henry H]

I still think we're spending way too much time discussing things in the
context of SMS. We understand the limitations of the protocol and we're not
going to be changing the underlying protocol so what more is there to talk
about it?

I'm not saying to ignore SMS - let's just stop trying to use all our brain
cells for fitting a square peg into a round hole. So messages over SMS
should be broken apart or truncated. Users can choose to send less than 140
character messages, but there is no point is limiting messaging platforms
for that or spending inordinate amounts of time coming up with solutions for
identification within that limit. Accept it and move on.

I vote we close this thread unless parties wish to continue talking about
the economic benefits of SMS to the telco companies :-)

OR

If people want to continue talking about how to handle namespace conflicts
and replies within the SMS world - add that to the subject :-)

On Fri, Aug 1, 2008 at 3:12 AM, Jean-Marc Liotier <jm (AT) liotier (DOT) org> wrote:

> Also sprach Henry H [Thu, Jul 31, 2008 at 01:32:25PM -0500] :
> > I'm of the opinion that all devices will come with IM clients
> > supporting XMPP with always on Internet connectivity so collectively
> > we're spending WAY too much time discussion solutions in the SMS
> > constraint of 140 bytes.
>
> Technically, I agree wholeheartedly. From a business point of view, I
> work with operators and I they looove the ludicruous margins they make
> on SMS, so even though in the age of ubiquitous GPRS, UMTS, Wifi and
> Wimax they will still appreciate an infrastructure that encourages SMS
> use even though it is an usability disaster. I would be in favor of
> letting SMS service providers fend for themselves with whatever hack
> they can come with to bridge SMS to the IM world, but if for strategic
> business reason we need the specification to be mobile operator
> friendly, thinking about SMS is not a bad idea. IMS is just now
> beginning to take mindshare, and deployments will take years at least -
> so for now we still have to accomodate the telco world.
>

[Peter Saint-Andre]

Henry H wrote:

> I vote we close this thread

+1. I'm feeling more heat than light, here. :)

/psa

[Bill de hOra]

> Being able to hide data behind the interface in hyperlinks may solve the
> machine's problem, but it doesn't solve the human interface problem.
> Imagine that there are two Susan's who might send you Tweets/Dents or
> whatever. They are: susan (AT) nice (DOT) com <mailto:susan (AT) nice (DOT) com> and
> susan (AT) bad (DOT) com <mailto:susan (AT) bad (DOT) com>. Now, you get a message that looks
> like this in your IM client:
>
> Susan <http://bad.com/susan>: Shall we have dinner tonight?
>
> How do you know what answer to give or to whom your answer will be sent?
> Will you *always* remember to check? How would a non-technical person
> solve this problem?

For SMS - you allow people to give other people (or accounts) aliases.
It's a bit like speedial.

As for message truncation; some services can remap an SMS to a multipart
MMS; the problem in doing so is that you can affect message payments.

Bill