From ehn at spotify.com  Tue Jul  1 13:50:51 2008
From: ehn at spotify.com (Andreas Ehn)
Date: Tue, 1 Jul 2008 20:50:51 +0200
Subject: [Social] Gnip
Message-ID: <242f5bb80807011150v4ad084edl381a06cb3c77bdf3@mail.gmail.com>

Hi,

Gnip, a startup company, is building a service that will enable you to
get HTTP feeds from a bunch of services over XMPP (among other
things):

http://www.techcrunch.com/2008/07/01/gnip-launches-to-ease-the-strain-on-web-services/

http://www.gnipcentral.com/

Looking at the API documentation, though, it seems that the XMPP part
is not there yet:

http://docs.google.com/View?docid=dgkhvp8s_3hhwdmdfb

Is anyone on the list involved with the company or does anyone happen
to know more about what there plans are?

Cheers,
Andreas

From chris.messina at gmail.com  Tue Jul  1 14:54:43 2008
From: chris.messina at gmail.com (Chris Messina)
Date: Tue, 1 Jul 2008 12:54:43 -0700
Subject: [Social] Gnip
In-Reply-To: <242f5bb80807011150v4ad084edl381a06cb3c77bdf3@mail.gmail.com>
References: <242f5bb80807011150v4ad084edl381a06cb3c77bdf3@mail.gmail.com>
Message-ID: <1bc4603e0807011254t6e2b4825qe8abb9da0eb4ece0@mail.gmail.com>

I've been in conversations with these guys for a while -- they're
certainly on the XMPP bandwagon, but I think they're starting a little
more basic first.

I've CC'd the guys behind the project. Perhaps they can elaborate (I
imagine once the hype settles down a bit).

Chris

On Tue, Jul 1, 2008 at 11:50 AM, Andreas Ehn <ehn at spotify.com> wrote:
> Hi,
>
> Gnip, a startup company, is building a service that will enable you to
> get HTTP feeds from a bunch of services over XMPP (among other
> things):
>
> http://www.techcrunch.com/2008/07/01/gnip-launches-to-ease-the-strain-on-web-services/
>
> http://www.gnipcentral.com/
>
> Looking at the API documentation, though, it seems that the XMPP part
> is not there yet:
>
> http://docs.google.com/View?docid=dgkhvp8s_3hhwdmdfb
>
> Is anyone on the list involved with the company or does anyone happen
> to know more about what there plans are?
>
> Cheers,
> Andreas
>



-- 
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

From stpeter at stpeter.im  Tue Jul  1 16:08:07 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 01 Jul 2008 15:08:07 -0600
Subject: [Social] Gnip
In-Reply-To: <1bc4603e0807011254t6e2b4825qe8abb9da0eb4ece0@mail.gmail.com>
References: <242f5bb80807011150v4ad084edl381a06cb3c77bdf3@mail.gmail.com>
	<1bc4603e0807011254t6e2b4825qe8abb9da0eb4ece0@mail.gmail.com>
Message-ID: <486A9CB7.6000004@stpeter.im>

Chris Messina wrote:
> I've been in conversations with these guys for a while -- they're
> certainly on the XMPP bandwagon, but I think they're starting a little
> more basic first.
> 
> I've CC'd the guys behind the project. Perhaps they can elaborate (I
> imagine once the hype settles down a bit).

Eric and/or Jud from Gnip said they'd be at the XMPP Summit in July, but 
with all the hype perhaps they'll be too busy. ;-)

/psa


From stpeter at stpeter.im  Wed Jul  2 12:43:17 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 02 Jul 2008 11:43:17 -0600
Subject: [Social] Identi.ca Microblogger Launches
Message-ID: <486BBE35.2020802@stpeter.im>

http://www.freeculturenews.com/?p=63 says:

***

Identi.ca has launched.  It's a microblogging service that runs on AGPL 
software and content posted is considered CC BY.

     Identi.ca is a microblogging service brought to you by Control 
Yourself, Inc.. It runs the Laconica microblogging software, version 
0.4.0, available under the GNU Affero General Public License.

     Unless otherwise specified, contents of this site are copyright by 
the contributors and available under the Creative Commons Attribution 
3.0. Contributors should be attributed by full name or nickname.

They've even implemented OpenID right, so that you don't need an 
account.  And you can post with XMPP! Very free indeed.  Goodbye Twitter.

***

From chris.messina at gmail.com  Wed Jul  2 20:24:48 2008
From: chris.messina at gmail.com (Chris Messina)
Date: Wed, 2 Jul 2008 18:24:48 -0700
Subject: [Social] Identi.ca Microblogger Launches
In-Reply-To: <486BBE35.2020802@stpeter.im>
References: <486BBE35.2020802@stpeter.im>
Message-ID: <1bc4603e0807021824v685b5502hbada40095483fa6f@mail.gmail.com>

Of to auth against any kind of API for OpenID users they're going to need
tokens... or preferrably OAuth...! ;)

Oh, and here's a Fail Whale for your enjoyment:

http://www.flickr.com/photos/factoryjoe/2631958063/

Chris

On Wed, Jul 2, 2008 at 10:43 AM, Peter Saint-Andre <stpeter at stpeter.im>
wrote:

> http://www.freeculturenews.com/?p=63 says:
>
> ***
>
> Identi.ca has launched.  It's a microblogging service that runs on AGPL
> software and content posted is considered CC BY.
>
>    Identi.ca is a microblogging service brought to you by Control Yourself,
> Inc.. It runs the Laconica microblogging software, version 0.4.0, available
> under the GNU Affero General Public License.
>
>    Unless otherwise specified, contents of this site are copyright by the
> contributors and available under the Creative Commons Attribution 3.0.
> Contributors should be attributed by full name or nickname.
>
> They've even implemented OpenID right, so that you don't need an account.
>  And you can post with XMPP! Very free indeed.  Goodbye Twitter.
>
> ***
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080702/a307a7e3/attachment.htm 

From stpeter at stpeter.im  Wed Jul  2 21:24:57 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 02 Jul 2008 20:24:57 -0600
Subject: [Social] Identi.ca Microblogger Launches
In-Reply-To: <1bc4603e0807021824v685b5502hbada40095483fa6f@mail.gmail.com>
References: <486BBE35.2020802@stpeter.im>
	<1bc4603e0807021824v685b5502hbada40095483fa6f@mail.gmail.com>
Message-ID: <486C3879.1020909@stpeter.im>

Chris Messina wrote:
> Of to auth against any kind of API for OpenID users they're going to 
> need tokens... or preferrably OAuth...! ;)

I'll be interested to see how they handle federation of Laconica 
instances...

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080702/ecfd9f5c/attachment.bin 

From melo at simplicidade.org  Thu Jul  3 01:00:34 2008
From: melo at simplicidade.org (Pedro Melo)
Date: Thu, 3 Jul 2008 07:00:34 +0100
Subject: [Social] Identi.ca Microblogger Launches
In-Reply-To: <486BBE35.2020802@stpeter.im>
References: <486BBE35.2020802@stpeter.im>
Message-ID: <1E86E9CB-1765-4336-8C64-57AA9D8B1F13@simplicidade.org>

Hey,

On Jul 2, 2008, at 6:43 PM, Peter Saint-Andre wrote:

> http://www.freeculturenews.com/?p=63 says:
>
> ***
>
> Identi.ca has launched.  It's a microblogging service that runs on  
> AGPL software and content posted is considered CC BY.
>
>     Identi.ca is a microblogging service brought to you by Control  
> Yourself, Inc.. It runs the Laconica microblogging software,  
> version 0.4.0, available under the GNU Affero General Public License.
>
>     Unless otherwise specified, contents of this site are copyright  
> by the contributors and available under the Creative Commons  
> Attribution 3.0. Contributors should be attributed by full name or  
> nickname.
>
> They've even implemented OpenID right, so that you don't need an  
> account.  And you can post with XMPP! Very free indeed.  Goodbye  
> Twitter.

Well, the IM interface is a bit off. They didn't setup the proper SRV  
records yet.

I've sent them an email, but if someone knows someone there, they  
might give them a nudge?

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



From cshelamer at gmail.com  Thu Jul  3 02:44:49 2008
From: cshelamer at gmail.com (Chris Shelamer-Terry)
Date: Thu, 3 Jul 2008 00:44:49 -0700
Subject: [Social] giving my email address
Message-ID: <b5839ee90807030044vd9938d1sd5cc16171805e0d8@mail.gmail.com>

cshelamer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080703/4e9d39be/attachment.htm 

From stpeter at stpeter.im  Thu Jul  3 11:34:33 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 03 Jul 2008 10:34:33 -0600
Subject: [Social] Identi.ca Microblogger Launches
In-Reply-To: <1E86E9CB-1765-4336-8C64-57AA9D8B1F13@simplicidade.org>
References: <486BBE35.2020802@stpeter.im>
	<1E86E9CB-1765-4336-8C64-57AA9D8B1F13@simplicidade.org>
Message-ID: <486CFF99.20803@stpeter.im>

Pedro Melo wrote:
> Hey,
> 
> On Jul 2, 2008, at 6:43 PM, Peter Saint-Andre wrote:
> 
>> http://www.freeculturenews.com/?p=63 says:
>>
>> ***
>>
>> Identi.ca has launched.  It's a microblogging service that runs on 
>> AGPL software and content posted is considered CC BY.
>>
>>     Identi.ca is a microblogging service brought to you by Control 
>> Yourself, Inc.. It runs the Laconica microblogging software, version 
>> 0.4.0, available under the GNU Affero General Public License.
>>
>>     Unless otherwise specified, contents of this site are copyright by 
>> the contributors and available under the Creative Commons Attribution 
>> 3.0. Contributors should be attributed by full name or nickname.
>>
>> They've even implemented OpenID right, so that you don't need an 
>> account.  And you can post with XMPP! Very free indeed.  Goodbye Twitter.
> 
> Well, the IM interface is a bit off. They didn't setup the proper SRV 
> records yet.
> 
> I've sent them an email, but if someone knows someone there, they might 
> give them a nudge?

What's wrong with the SRV records? The guy to ping is Evan:

http://identi.ca/evan

But he's pretty busy right now. ;-)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080703/b1999a4c/attachment-0001.bin 

From melo at simplicidade.org  Thu Jul  3 12:26:03 2008
From: melo at simplicidade.org (Pedro Melo)
Date: Thu, 3 Jul 2008 18:26:03 +0100
Subject: [Social] Identi.ca Microblogger Launches
In-Reply-To: <486CFF99.20803@stpeter.im>
References: <486BBE35.2020802@stpeter.im>
	<1E86E9CB-1765-4336-8C64-57AA9D8B1F13@simplicidade.org>
	<486CFF99.20803@stpeter.im>
Message-ID: <2168BA94-3984-4CBA-8A70-EFA76C559556@simplicidade.org>

Hi,

On Jul 3, 2008, at 5:34 PM, Peter Saint-Andre wrote:

> Pedro Melo wrote:
>> Hey,
>> On Jul 2, 2008, at 6:43 PM, Peter Saint-Andre wrote:
>>> http://www.freeculturenews.com/?p=63 says:
>>>
>>> ***
>>>
>>> Identi.ca has launched.  It's a microblogging service that runs  
>>> on AGPL software and content posted is considered CC BY.
>>>
>>>     Identi.ca is a microblogging service brought to you by  
>>> Control Yourself, Inc.. It runs the Laconica microblogging  
>>> software, version 0.4.0, available under the GNU Affero General  
>>> Public License.
>>>
>>>     Unless otherwise specified, contents of this site are  
>>> copyright by the contributors and available under the Creative  
>>> Commons Attribution 3.0. Contributors should be attributed by  
>>> full name or nickname.
>>>
>>> They've even implemented OpenID right, so that you don't need an  
>>> account.  And you can post with XMPP! Very free indeed.  Goodbye  
>>> Twitter.
>> Well, the IM interface is a bit off. They didn't setup the proper  
>> SRV records yet.
>> I've sent them an email, but if someone knows someone there, they  
>> might give them a nudge?
>
> What's wrong with the SRV records? The guy to ping is Evan:

They where missing. Evan contacted me in the morning and it got  
sorted out.

> http://identi.ca/evan
>
> But he's pretty busy right now. ;-)

I got lucky.

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



From stpeter at stpeter.im  Thu Jul  3 12:28:47 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 03 Jul 2008 11:28:47 -0600
Subject: [Social] Identi.ca Microblogger Launches
In-Reply-To: <2168BA94-3984-4CBA-8A70-EFA76C559556@simplicidade.org>
References: <486BBE35.2020802@stpeter.im>	<1E86E9CB-1765-4336-8C64-57AA9D8B1F13@simplicidade.org>	<486CFF99.20803@stpeter.im>
	<2168BA94-3984-4CBA-8A70-EFA76C559556@simplicidade.org>
Message-ID: <486D0C4F.40209@stpeter.im>

Pedro Melo wrote:

> On Jul 3, 2008, at 5:34 PM, Peter Saint-Andre wrote:
>> What's wrong with the SRV records? The guy to ping is Evan:
> 
> They where missing. Evan contacted me in the morning and it got sorted out.

Well I think he's on this list so don't say anything nasty. :) He's 
doing a great job so far, I think, given the traffic he's seeing.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080703/ea090534/attachment.bin 

From jud at gnipcentral.com  Mon Jul  7 17:06:49 2008
From: jud at gnipcentral.com (Jud Valeski)
Date: Mon, 07 Jul 2008 16:06:49 -0600
Subject: [Social] Gnip
In-Reply-To: <1bc4603e0807011254t6e2b4825qe8abb9da0eb4ece0@mail.gmail.com>
References: <242f5bb80807011150v4ad084edl381a06cb3c77bdf3@mail.gmail.com>
	<1bc4603e0807011254t6e2b4825qe8abb9da0eb4ece0@mail.gmail.com>
Message-ID: <48729379.3070805@gnipcentral.com>

An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080707/3e6e2f3e/attachment.htm 

From apisoni at geni.com  Tue Jul  8 17:34:06 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Tue, 8 Jul 2008 15:34:06 -0700
Subject: [Social] Federated PubSub
Message-ID: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>

This topic has been covered before loosely, but I have some questions  
I was hoping people could opine on as far as how they see the future  
working out.  I'm currently working on a messaging product which  
relies heavily on XMPP and eventually PubSub.   We're also looking at  
PEP and other ways to consume/expose our data in a brave new PubSub  
world of federated social networks.  This has led to a lot of  
interesting questions.

Imagine bob at somejabberhost.com posts an image to flickr.    Bob has  
many friends who might be interested in that.  In a PubSub world,  
those friends would subscribe to a node somewhere which flickr would  
publish to.   Bob's friends would subscribe to that node.   Here's  
where the questions start.    Do people imagine that node living on  
flickr or on somejabberhost.com?   There are benefits to both.    
Imagine this particular node of Bob's is private.  He only wants to  
allow a subset of his roster to have permission to subscribe to that  
node.    Lets say, from Bob's point of view, he has a roster group  
called Family who he wants to give permission to.  If  
somejabberhost.com hosts that node then it would be easy for Bob to  
say he only wants his Family roster group to have access to his  
images_stream node.  He also would need a way of authorizing flickr to  
publish to that node on his behalf (OAuth)    Of course now Flickr  
can't further authenticate users for Bob since flickr doesn't know or  
have access to Bob's roster. Nor would Bob want flickr poking in his  
roster.

We tried to imagine a scenario where Bob could give Flickr permission  
(perhaps using OAuth) to authenticate people against his roster  
(without flickr being able to read his roster fully).  All of that  
seems complicated though.

If Flickr keeps the node, then you have the same issues of Flickr not  
having any knowledge of Bob's roster.

I know there may not be answers for these questions yet.  I guess I'm  
just wondering what people think logical solutions might be.  Or maybe  
there are answers.

Thanks,
adam


From nathanfritz at gmail.com  Tue Jul  8 18:24:50 2008
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Tue, 8 Jul 2008 16:24:50 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
Message-ID: <182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>

It's simpler than that.  You would "affiliate" Flickr's XMPP
bot/component/whatever as "publisher" to the node (
http://www.xmpp.org/extensions/xep-0060.html#owner-affiliations-modify).  Of
course you don't want Flickr controlling your roster!  And so if you want
Flickr to be able to control which JIDs are subscribed to this node (you
wouldn't want to do that, would you?), then you'd have to make flickr an
administrator of the node and use whitelist or authitication access models.
However, I wouldn't see any need for Flickr to control who subscribes to
this node and not, as it is your business.

On Tue, Jul 8, 2008 at 3:34 PM, Adam Pisoni <apisoni at geni.com> wrote:

> This topic has been covered before loosely, but I have some questions I was
> hoping people could opine on as far as how they see the future working out.
>  I'm currently working on a messaging product which relies heavily on XMPP
> and eventually PubSub.   We're also looking at PEP and other ways to
> consume/expose our data in a brave new PubSub world of federated social
> networks.  This has led to a lot of interesting questions.
>
> Imagine bob at somejabberhost.com posts an image to flickr.    Bob has many
> friends who might be interested in that.  In a PubSub world, those friends
> would subscribe to a node somewhere which flickr would publish to.   Bob's
> friends would subscribe to that node.   Here's where the questions start.
>  Do people imagine that node living on flickr or on somejabberhost.com?
> There are benefits to both.   Imagine this particular node of Bob's is
> private.  He only wants to allow a subset of his roster to have permission
> to subscribe to that node.    Lets say, from Bob's point of view, he has a
> roster group called Family who he wants to give permission to.  If
> somejabberhost.com hosts that node then it would be easy for Bob to say he
> only wants his Family roster group to have access to his images_stream node.
>  He also would need a way of authorizing flickr to publish to that node on
> his behalf (OAuth)    Of course now Flickr can't further authenticate users
> for Bob since flickr doesn't know or have access to Bob's roster. Nor would
> Bob want flickr poking in his roster.
>
> We tried to imagine a scenario where Bob could give Flickr permission
> (perhaps using OAuth) to authenticate people against his roster (without
> flickr being able to read his roster fully).  All of that seems complicated
> though.
>
> If Flickr keeps the node, then you have the same issues of Flickr not
> having any knowledge of Bob's roster.
>
> I know there may not be answers for these questions yet.  I guess I'm just
> wondering what people think logical solutions might be.  Or maybe there are
> answers.
>
> Thanks,
> adam
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080708/cd36d248/attachment.htm 

From nick at iss.im  Tue Jul  8 19:41:42 2008
From: nick at iss.im (Nick Vidal)
Date: Tue, 8 Jul 2008 21:41:42 -0300
Subject: [Social] Federated PubSub
In-Reply-To: <182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
Message-ID: <26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>

Hi,

Adam Pisoni wrote:
>> He also would need a way of authorizing flickr to publish to that node on
>> his behalf (OAuth)

For this, Nathan's response is perfect:

> It's simpler than that.  You would "affiliate" Flickr's XMPP
> bot/component/whatever as "publisher" to the node

Much simpler indeed. This skips OAuth entirely. XMPP controls your
roster, your nodes, and who has access to these (read/write
privileges).

However, if the photos are hosted in Flickr *and* you want to restrict
this access to some groups, then you have to delegate access control
to Flickr some way. In this case, OAuth would be recommend.

Best regards,
Nick

On Tue, Jul 8, 2008 at 8:24 PM, Nathan Fritz <nathanfritz at gmail.com> wrote:
> It's simpler than that.  You would "affiliate" Flickr's XMPP
> bot/component/whatever as "publisher" to the node
> (http://www.xmpp.org/extensions/xep-0060.html#owner-affiliations-modify).
> Of course you don't want Flickr controlling your roster!  And so if you want
> Flickr to be able to control which JIDs are subscribed to this node (you
> wouldn't want to do that, would you?), then you'd have to make flickr an
> administrator of the node and use whitelist or authitication access models.
> However, I wouldn't see any need for Flickr to control who subscribes to
> this node and not, as it is your business.
>
> On Tue, Jul 8, 2008 at 3:34 PM, Adam Pisoni <apisoni at geni.com> wrote:
>>
>> This topic has been covered before loosely, but I have some questions I
>> was hoping people could opine on as far as how they see the future working
>> out.  I'm currently working on a messaging product which relies heavily on
>> XMPP and eventually PubSub.   We're also looking at PEP and other ways to
>> consume/expose our data in a brave new PubSub world of federated social
>> networks.  This has led to a lot of interesting questions.
>>
>> Imagine bob at somejabberhost.com posts an image to flickr.    Bob has many
>> friends who might be interested in that.  In a PubSub world, those friends
>> would subscribe to a node somewhere which flickr would publish to.   Bob's
>> friends would subscribe to that node.   Here's where the questions start.
>>  Do people imagine that node living on flickr or on somejabberhost.com?
>> There are benefits to both.   Imagine this particular node of Bob's is
>> private.  He only wants to allow a subset of his roster to have permission
>> to subscribe to that node.    Lets say, from Bob's point of view, he has a
>> roster group called Family who he wants to give permission to.  If
>> somejabberhost.com hosts that node then it would be easy for Bob to say he
>> only wants his Family roster group to have access to his images_stream node.
>>  He also would need a way of authorizing flickr to publish to that node on
>> his behalf (OAuth)    Of course now Flickr can't further authenticate users
>> for Bob since flickr doesn't know or have access to Bob's roster. Nor would
>> Bob want flickr poking in his roster.
>>
>> We tried to imagine a scenario where Bob could give Flickr permission
>> (perhaps using OAuth) to authenticate people against his roster (without
>> flickr being able to read his roster fully).  All of that seems complicated
>> though.
>>
>> If Flickr keeps the node, then you have the same issues of Flickr not
>> having any knowledge of Bob's roster.
>>
>> I know there may not be answers for these questions yet.  I guess I'm just
>> wondering what people think logical solutions might be.  Or maybe there are
>> answers.
>>
>> Thanks,
>> adam
>>
>
>

From apisoni at geni.com  Tue Jul  8 20:16:35 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Tue, 8 Jul 2008 18:16:35 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
Message-ID: <78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>

>
> Much simpler indeed. This skips OAuth entirely. XMPP controls your
> roster, your nodes, and who has access to these (read/write
> privileges).
>
> However, if the photos are hosted in Flickr *and* you want to restrict
> this access to some groups, then you have to delegate access control
> to Flickr some way. In this case, OAuth would be recommend.

Right, but I don't believe there's a mechanism for this.  Really what  
I'm saying is, I have a roster group and only want those JIDs to have  
access, but I also don't want to give Flickr access to my roster.  So  
I want to use something like OAuth to allow flickr to authenticate  
against my roster somehow without being able to read my roster.     
This is more than just allowing Flickr to publish to some node, this  
is further authenticating ON the flickr site based on my roster.

I take it from the this and the prior post that the expectation is  
that pubsub nodes are hosted by the server controlling the JID that  
owns the node, which makes sense.

thanks,
Adam



>
>
> Best regards,
> Nick
>
> On Tue, Jul 8, 2008 at 8:24 PM, Nathan Fritz <nathanfritz at gmail.com>  
> wrote:
>> It's simpler than that.  You would "affiliate" Flickr's XMPP
>> bot/component/whatever as "publisher" to the node
>> (http://www.xmpp.org/extensions/xep-0060.html#owner-affiliations-modify 
>> ).
>> Of course you don't want Flickr controlling your roster!  And so if  
>> you want
>> Flickr to be able to control which JIDs are subscribed to this node  
>> (you
>> wouldn't want to do that, would you?), then you'd have to make  
>> flickr an
>> administrator of the node and use whitelist or authitication access  
>> models.
>> However, I wouldn't see any need for Flickr to control who  
>> subscribes to
>> this node and not, as it is your business.
>>
>> On Tue, Jul 8, 2008 at 3:34 PM, Adam Pisoni <apisoni at geni.com> wrote:
>>>
>>> This topic has been covered before loosely, but I have some  
>>> questions I
>>> was hoping people could opine on as far as how they see the future  
>>> working
>>> out.  I'm currently working on a messaging product which relies  
>>> heavily on
>>> XMPP and eventually PubSub.   We're also looking at PEP and other  
>>> ways to
>>> consume/expose our data in a brave new PubSub world of federated  
>>> social
>>> networks.  This has led to a lot of interesting questions.
>>>
>>> Imagine bob at somejabberhost.com posts an image to flickr.    Bob  
>>> has many
>>> friends who might be interested in that.  In a PubSub world, those  
>>> friends
>>> would subscribe to a node somewhere which flickr would publish  
>>> to.   Bob's
>>> friends would subscribe to that node.   Here's where the questions  
>>> start.
>>> Do people imagine that node living on flickr or on  
>>> somejabberhost.com?
>>> There are benefits to both.   Imagine this particular node of  
>>> Bob's is
>>> private.  He only wants to allow a subset of his roster to have  
>>> permission
>>> to subscribe to that node.    Lets say, from Bob's point of view,  
>>> he has a
>>> roster group called Family who he wants to give permission to.  If
>>> somejabberhost.com hosts that node then it would be easy for Bob  
>>> to say he
>>> only wants his Family roster group to have access to his  
>>> images_stream node.
>>> He also would need a way of authorizing flickr to publish to that  
>>> node on
>>> his behalf (OAuth)    Of course now Flickr can't further  
>>> authenticate users
>>> for Bob since flickr doesn't know or have access to Bob's roster.  
>>> Nor would
>>> Bob want flickr poking in his roster.
>>>
>>> We tried to imagine a scenario where Bob could give Flickr  
>>> permission
>>> (perhaps using OAuth) to authenticate people against his roster  
>>> (without
>>> flickr being able to read his roster fully).  All of that seems  
>>> complicated
>>> though.
>>>
>>> If Flickr keeps the node, then you have the same issues of Flickr  
>>> not
>>> having any knowledge of Bob's roster.
>>>
>>> I know there may not be answers for these questions yet.  I guess  
>>> I'm just
>>> wondering what people think logical solutions might be.  Or maybe  
>>> there are
>>> answers.
>>>
>>> Thanks,
>>> adam
>>>
>>
>>


From melo at simplicidade.org  Wed Jul  9 02:15:58 2008
From: melo at simplicidade.org (Pedro Melo)
Date: Wed, 9 Jul 2008 08:15:58 +0100
Subject: [Social] Federated PubSub
In-Reply-To: <26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
Message-ID: <69DBB133-D3D7-4430-8B60-6F3887A91CA4@simplicidade.org>


On Jul 9, 2008, at 1:41 AM, Nick Vidal wrote:

> Hi,
>
> Adam Pisoni wrote:
>>> He also would need a way of authorizing flickr to publish to that  
>>> node on
>>> his behalf (OAuth)
>
> For this, Nathan's response is perfect:
>
>> It's simpler than that.  You would "affiliate" Flickr's XMPP
>> bot/component/whatever as "publisher" to the node
>
> Much simpler indeed. This skips OAuth entirely. XMPP controls your
> roster, your nodes, and who has access to these (read/write
> privileges).

Actually, OAuth can have its place. You can use OAuth as the protocol  
Flickr and the user use to accept Flickr JID as a publisher to your  
node. The OAuth component on your jabber server would then add flickr  
jid as a publisher of your node.

So OAuth used on the intereaction between Flickr and user, classical  
XMPP pubsub to do the enforcing. I think this will probably be the  
easier first because right now I don't know many clients that support  
control over pubsub nodes.

But neither servers support OAuth. So real life: right now, flickr  
would host the pubsub nodes and could use the friends and family  
settings plus the connections he already has to keep the whitelist.

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



From gnauck at ag-software.de  Wed Jul  9 03:09:56 2008
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Wed, 09 Jul 2008 10:09:56 +0200
Subject: [Social] Federated PubSub
In-Reply-To: <78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
Message-ID: <162fd9943f229f1916afd3758e1dfe26@localhost>

> I take it from the this and the prior post that the expectation is
> that pubsub nodes are hosted by the server controlling the JID that
> owns the node, which makes sense.

not necessarily, 
* if your server runs no pubsub component you can use pubsub services from
other federated servers
* If the server runs a pubsub component which is not build into the server
directly, but used the XMPP component protocol you have no roster access.

I see your points, maybe you should also take a look at PEP (XEP-0163)
which interacts with the roster.
I like your ideas, but to make this happen we need first a new component
protocol which gives us access to the roster. Otherwise we will have no
portable pubsub components or addons.

Alex


From kevin at kismith.co.uk  Wed Jul  9 03:17:14 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Wed, 9 Jul 2008 09:17:14 +0100
Subject: [Social] Federated PubSub
In-Reply-To: <162fd9943f229f1916afd3758e1dfe26@localhost>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
Message-ID: <f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>

On Wed, Jul 9, 2008 at 9:09 AM, Alexander Gnauck <gnauck at ag-software.de> wrote:
> * If the server runs a pubsub component which is not build into the server
> directly, but used the XMPP component protocol you have no roster access.
> I see your points, maybe you should also take a look at PEP (XEP-0163)
> which interacts with the roster.

As things stand at the moment, all the roster and +notify stuff sits
in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
pubsub is currently not implementable through the component protocol).

/K

From joec0914 at gmail.com  Wed Jul  9 06:18:57 2008
From: joec0914 at gmail.com (Joe Cascio, Jr.)
Date: Wed, 9 Jul 2008 07:18:57 -0400
Subject: [Social] Federated PubSub
Message-ID: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>

I tend to agree most with Pedro Melo in the sense that XMPP can simply be
the transport mechanism and that the "higher" functions, if you will, of
authorizing and subsetting followers can be done in an enclosing layer.

This has several benefits, including being able to gang or parallelize
(yeah, that's not a word :) xmpp servers to distribute load from power-users
and popular sites or to provide transparent back-up if your main XMPP server
goes down.

I think it's inadvisable to look at microblogging as only what XMPP
provides, for instance using xmpp resources as the user-visible identities.

JoeC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080709/d9ccf5c4/attachment.htm 

From apisoni at geni.com  Wed Jul  9 11:32:18 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Wed, 9 Jul 2008 09:32:18 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>
Message-ID: <742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>

When I think about the future world of federated social networks I  
definitely see XMPP as only one component and do not look it to solve  
all authentication/authorization/transport issues.  That said, XMPP  
has this built in 'roster' piece that is hard not to see as a  
federated replacement of the per social network buddy list.   The  
problem is that this buddy list wasn't meant to be a decentralized  
buddy list so the issues I bring up of authorization haven't been  
worked out.   Unless we're saying people should not be thinking of  
rosters as controlled buddy lists.

> But neither servers support OAuth. So real life: right now, flickr  
> would host the pubsub nodes and could use the friends and family  
> settings plus the connections he already has to keep the whitelist.

This is what I thought at first, but I'm trying to think ahead towards  
a time when I don't have to maintain buddy lists and permissions on  
each social network.

Another idea which avoids Flickr needing permission to auth against my  
buddy list is somehow to let Flickr auth against the node itself.    
ie.  I have authorized specific people to sub from a particular node  
and given Flickr affiliate permissions to publish to that node, but  
I've also given Flickr permission to authorize people against those  
authorized to access that node.   This actually solves a number of  
problems (though I know there is currently no way of doing this).    
Makes sense though right?

Thanks,
adam


On Jul 9, 2008, at 4:18 AM, Joe Cascio, Jr. wrote:

> I tend to agree most with Pedro Melo in the sense that XMPP can  
> simply be the transport mechanism and that the "higher" functions,  
> if you will, of authorizing and subsetting followers can be done in  
> an enclosing layer.
>
> This has several benefits, including being able to gang or  
> parallelize (yeah, that's not a word :) xmpp servers to distribute  
> load from power-users and popular sites or to provide transparent  
> back-up if your main XMPP server goes down.
>
> I think it's inadvisable to look at microblogging as only what XMPP  
> provides, for instance using xmpp resources as the user-visible  
> identities.
>
> JoeC


From romeda at gmail.com  Wed Jul  9 12:18:49 2008
From: romeda at gmail.com (Blaine Cook)
Date: Wed, 9 Jul 2008 10:18:49 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
Message-ID: <d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>

On Wed, Jul 9, 2008 at 1:17 AM, Kevin Smith <kevin at kismith.co.uk> wrote:

>
> As things stand at the moment, all the roster and +notify stuff sits
> in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
> pubsub is currently not implementable through the component protocol).
>

I strongly disagree. Parts of XEP-0060 aren't implementable via the
component protocol unless you also implement the roster protocol, but I have
written a functional and useful PubSub implementation that interfaces via
the component protocol.

Moreover, those who've met me know I'm prone to saying that much of the
PubSub protocol is confusing and not necessarily useful in practice, so
having roster-based permissions is far from necessary for most things,
especially web-based apps of the sort we're discussing.

b.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080709/d6e9cc2d/attachment.htm 

From apisoni at geni.com  Wed Jul  9 12:21:59 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Wed, 9 Jul 2008 10:21:59 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
Message-ID: <34A838ED-5CC3-4BA0-AC02-B1148608D8BE@geni.com>

I'm working on a component myself and have had to implement much of  
the roster stuff as well.   I agree with Blaine that you can probably  
implement a fully featured/compliant PubSub within a component.

Thanks,
adam

On Jul 9, 2008, at 10:18 AM, Blaine Cook wrote:

> On Wed, Jul 9, 2008 at 1:17 AM, Kevin Smith <kevin at kismith.co.uk>  
> wrote:
>
> As things stand at the moment, all the roster and +notify stuff sits
> in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
> pubsub is currently not implementable through the component protocol).
>
> I strongly disagree. Parts of XEP-0060 aren't implementable via the  
> component protocol unless you also implement the roster protocol,  
> but I have written a functional and useful PubSub implementation  
> that interfaces via the component protocol.
>
> Moreover, those who've met me know I'm prone to saying that much of  
> the PubSub protocol is confusing and not necessarily useful in  
> practice, so having roster-based permissions is far from necessary  
> for most things, especially web-based apps of the sort we're  
> discussing.
>
> b.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080709/c1bd8d37/attachment.htm 

From romeda at gmail.com  Wed Jul  9 12:25:44 2008
From: romeda at gmail.com (Blaine Cook)
Date: Wed, 9 Jul 2008 10:25:44 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>
	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>
Message-ID: <d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>

On Wed, Jul 9, 2008 at 9:32 AM, Adam Pisoni <apisoni at geni.com> wrote:

> This is what I thought at first, but I'm trying to think ahead towards a
> time when I don't have to maintain buddy lists and permissions on each
> social network.
>

I think that each social network is different; the permissions I grant
people on my Flickr account are fundamentally different than those that I
grant on LinkedIn, which are again different from my Twitter account, and my
blog doesn't have any permissions at all. I like it that way, and I don't
actually want Flickr to know who I've approved on LinkedIn and vice-versa.
My IM buddy list is entirely different, and actually differs from IM network
to IM network, and account to account (i.e., I have multiple IM rosters).

Another idea which avoids Flickr needing permission to auth against my buddy
> list is somehow to let Flickr auth against the node itself.   ie.  I have
> authorized specific people to sub from a particular node and given Flickr
> affiliate permissions to publish to that node, but I've also given Flickr
> permission to authorize people against those authorized to access that node.
>   This actually solves a number of problems (though I know there is
> currently no way of doing this).   Makes sense though right?
>

Another way to think about it would be to have your central PubSub server
(e.g., adampisoni.com) subscribe to Flickr, and essentially act as a proxy
--- you give yourself permissions to your entire Flickr stream, and then
choose who gets permissions based on your central roster. I still think the
caveat above applies, though.

b.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080709/12c3de26/attachment.htm 

From kevin at kismith.co.uk  Wed Jul  9 12:33:49 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Wed, 9 Jul 2008 18:33:49 +0100
Subject: [Social] Federated PubSub
In-Reply-To: <d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
Message-ID: <f5aae3ec0807091033v1a230c40t21112d21c137dce1@mail.gmail.com>

On Wed, Jul 9, 2008 at 6:18 PM, Blaine Cook <romeda at gmail.com> wrote:
>> As things stand at the moment, all the roster and +notify stuff sits
>> in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
>> pubsub is currently not implementable through the component protocol).
> I strongly disagree. Parts of XEP-0060 aren't implementable via the
> component protocol unless you also implement the roster protocol, but I have
> written a functional and useful PubSub implementation that interfaces via
> the component protocol.

Ah, so you've got the roster access, and the +notify stuff going from
a component?
That's interesting (and quite cool).

> Moreover, those who've met me know I'm prone to saying that much of the
> PubSub protocol is confusing and not necessarily useful in practice

I'm not going to disagree there, I've been saying it for years.

> so
> having roster-based permissions is far from necessary for most things,

Sure, but it's necessary for a complete implementation of -0060, which
was all I intended to assert. That said, you've done the roster stuff
in a component, so I was wrong to assert it anyway.

/K

From kevin at kismith.co.uk  Wed Jul  9 12:34:57 2008
From: kevin at kismith.co.uk (Kevin Smith)
Date: Wed, 9 Jul 2008 18:34:57 +0100
Subject: [Social] Federated PubSub
In-Reply-To: <34A838ED-5CC3-4BA0-AC02-B1148608D8BE@geni.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
	<34A838ED-5CC3-4BA0-AC02-B1148608D8BE@geni.com>
Message-ID: <f5aae3ec0807091034x3a891ba3yeedd35f123b72234@mail.gmail.com>

On Wed, Jul 9, 2008 at 6:21 PM, Adam Pisoni <apisoni at geni.com> wrote:
> I'm working on a component myself and have had to implement much of the
> roster stuff as well.   I agree with Blaine that you can probably implement
> a fully featured/compliant PubSub within a component.

I'm impressed (and I think that's pretty cool, people have been saying
that you can't do the roster model, or the +notify stuff, from a
component, so I'm glad to see it done).

/K

From apisoni at geni.com  Wed Jul  9 12:42:28 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Wed, 9 Jul 2008 10:42:28 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>
	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>
	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>
Message-ID: <9361ECE4-2A0F-457A-A806-5ED838571FA7@geni.com>

> Another way to think about it would be to have your central PubSub  
> server (e.g., adampisoni.com) subscribe to Flickr, and essentially  
> act as a proxy --- you give yourself permissions to your entire  
> Flickr stream, and then choose who gets permissions based on your  
> central roster. I still think the caveat above applies, though.

Right this solves who can subscribe to KNOW ABOUT my flickr stream,  
but that list of people is fundamentally the same as those I want  
permission to SEE those pictures.   It's a shame I have to maintain  
those lists separately.   I agree that in many places you want those  
permissions to be separate, but in practice, non-power users don't  
want to maintain many different sets of permissions.   ie, most of us  
only have one group we think of as our family.   OpenSocial and other  
such (ill conceived efforts) are trying to solve this very issue  
precisely because it is so obvious.

thanks,
adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080709/03c907b4/attachment.htm 

From apisoni at geni.com  Wed Jul  9 12:44:40 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Wed, 9 Jul 2008 10:44:40 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <f5aae3ec0807091034x3a891ba3yeedd35f123b72234@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
	<34A838ED-5CC3-4BA0-AC02-B1148608D8BE@geni.com>
	<f5aae3ec0807091034x3a891ba3yeedd35f123b72234@mail.gmail.com>
Message-ID: <BFC78FD6-7B7B-43BA-8F1B-72ABE01FF266@geni.com>

I'll be open sourcing this component pretty soon.  The idea is that it  
will have an adaptable storage system such that you can choose how you  
are persisting your roster and presence info, but the API remains the  
same.   Though Anders and I have had many discussions about how it's  
unfortunate that by choosing to create a component you MUST accept  
responsibility for roster/presence.  Ideally it would be nice in some  
circumstances if you could re-delegate, or never accept responsibility  
for those things from your jabber server if you wanted.

adam

On Jul 9, 2008, at 10:34 AM, Kevin Smith wrote:

> On Wed, Jul 9, 2008 at 6:21 PM, Adam Pisoni <apisoni at geni.com> wrote:
>> I'm working on a component myself and have had to implement much of  
>> the
>> roster stuff as well.   I agree with Blaine that you can probably  
>> implement
>> a fully featured/compliant PubSub within a component.
>
> I'm impressed (and I think that's pretty cool, people have been saying
> that you can't do the roster model, or the +notify stuff, from a
> component, so I'm glad to see it done).
>
> /K


From aconbere at gmail.com  Wed Jul  9 12:51:23 2008
From: aconbere at gmail.com (anders conbere)
Date: Wed, 9 Jul 2008 10:51:23 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <BFC78FD6-7B7B-43BA-8F1B-72ABE01FF266@geni.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
	<34A838ED-5CC3-4BA0-AC02-B1148608D8BE@geni.com>
	<f5aae3ec0807091034x3a891ba3yeedd35f123b72234@mail.gmail.com>
	<BFC78FD6-7B7B-43BA-8F1B-72ABE01FF266@geni.com>
Message-ID: <8ca3fbe80807091051w171ad638xb6d595fa0f76ed56@mail.gmail.com>

On Wed, Jul 9, 2008 at 10:44 AM, Adam Pisoni <apisoni at geni.com> wrote:
> I'll be open sourcing this component pretty soon.  The idea is that it will
> have an adaptable storage system such that you can choose how you are
> persisting your roster and presence info, but the API remains the same.
> Though Anders and I have had many discussions about how it's unfortunate
> that by choosing to create a component you MUST accept responsibility for
> roster/presence.  Ideally it would be nice in some circumstances if you
> could re-delegate, or never accept responsibility for those things from your
> jabber server if you wanted.

Right, I know I've bounced around this idea to a few of you, and it
sounds like there are some servers (djabberd) that work a bit like
this. But I've seen /a lot/ of components being built lately. And at
this point I'm fairly well convinced that this is the only way to
build scalable services that act like bots (plug into your internal
services closely and without managing individual clients). That being
said, as soon as you choose to use a component you throw the baby out
with the bathwater, you get a lot of freedom, but as far as I can tell
no modern server gives you a framework to attach to and build upon the
tools already in place to handle presence, rosters, permissions, etc.
etc.

So it seems to me that this could go one of two ways.

1) Components could be the wrong tool to use here. If that's the case
then we as a community need to come up with a better solution for the
kinds of use cases were seeing.

2) Components are the right tool, in which case it would be
interesting to talk to server authors about how we could better tool
servers to allow this kind of reuse.

~ Anders

>
> adam
>
> On Jul 9, 2008, at 10:34 AM, Kevin Smith wrote:
>
>> On Wed, Jul 9, 2008 at 6:21 PM, Adam Pisoni <apisoni at geni.com> wrote:
>>>
>>> I'm working on a component myself and have had to implement much of the
>>> roster stuff as well.   I agree with Blaine that you can probably
>>> implement
>>> a fully featured/compliant PubSub within a component.
>>
>> I'm impressed (and I think that's pretty cool, people have been saying
>> that you can't do the roster model, or the +notify stuff, from a
>> component, so I'm glad to see it done).
>>
>> /K
>
>

From aconbere at gmail.com  Wed Jul  9 12:54:23 2008
From: aconbere at gmail.com (anders conbere)
Date: Wed, 9 Jul 2008 10:54:23 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>
	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>
	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>
Message-ID: <8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>

On Wed, Jul 9, 2008 at 10:25 AM, Blaine Cook <romeda at gmail.com> wrote:
> On Wed, Jul 9, 2008 at 9:32 AM, Adam Pisoni <apisoni at geni.com> wrote:
>>
>> This is what I thought at first, but I'm trying to think ahead towards a
>> time when I don't have to maintain buddy lists and permissions on each
>> social network.
>
> I think that each social network is different; the permissions I grant
> people on my Flickr account are fundamentally different than those that I
> grant on LinkedIn, which are again different from my Twitter account, and my
> blog doesn't have any permissions at all. I like it that way, and I don't
> actually want Flickr to know who I've approved on LinkedIn and vice-versa.
> My IM buddy list is entirely different, and actually differs from IM network
> to IM network, and account to account (i.e., I have multiple IM rosters).

I've always called this "Contexts", and while right now the roster
doesn't have the tools to allow this kind of parceling of items, I
think it's totally reasonable to imagine being able to delegate
responsibility to portions of ones roster to a 3rd party, safely while
maintaining the semblance of the roster.

You can almost imagine using transports to do this right now (register
with the linkedin transport and it injects the linkedin buddy list
into your roster and now we can grant access to those entities). But I
think there might be a reasonable case for having first class support
for this kind of stuff.

~ Anders

>
>> Another idea which avoids Flickr needing permission to auth against my
>> buddy list is somehow to let Flickr auth against the node itself.   ie.  I
>> have authorized specific people to sub from a particular node and given
>> Flickr affiliate permissions to publish to that node, but I've also given
>> Flickr permission to authorize people against those authorized to access
>> that node.   This actually solves a number of problems (though I know there
>> is currently no way of doing this).   Makes sense though right?
>
> Another way to think about it would be to have your central PubSub server
> (e.g., adampisoni.com) subscribe to Flickr, and essentially act as a proxy
> --- you give yourself permissions to your entire Flickr stream, and then
> choose who gets permissions based on your central roster. I still think the
> caveat above applies, though.
>
> b.
>

From apisoni at geni.com  Wed Jul  9 13:10:18 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Wed, 9 Jul 2008 11:10:18 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>
	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>
	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>
	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>
Message-ID: <24623766-0344-4B4E-ABB6-4018355E3F38@geni.com>

>
> You can almost imagine using transports to do this right now (register
> with the linkedin transport and it injects the linkedin buddy list
> into your roster and now we can grant access to those entities). But I
> think there might be a reasonable case for having first class support
> for this kind of stuff.
>

This is a really interesting idea actually.... and is very much in  
line with the 'federation' part of this discussion.  You may have  
users only on facebook, or on other services all mangled together in  
your roster by allowing there to be relationships between 'rosters' on  
different networks within your roster.   A FB ID can easily be an  
alias for a JID in your roster.   I'm not sure how this all really  
plays out, but it is an interesting line of thought.  Either way,  
people will be looking for solutions to this problem and it can't hurt  
to have ideas on the matter.

adam


From stpeter at stpeter.im  Thu Jul 10 14:46:19 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 10 Jul 2008 13:46:19 -0600
Subject: [Social] Federated PubSub
In-Reply-To: <f5aae3ec0807091033v1a230c40t21112d21c137dce1@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>	<162fd9943f229f1916afd3758e1dfe26@localhost>	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
	<f5aae3ec0807091033v1a230c40t21112d21c137dce1@mail.gmail.com>
Message-ID: <4876670B.3040809@stpeter.im>

Kevin Smith wrote:
> On Wed, Jul 9, 2008 at 6:18 PM, Blaine Cook <romeda at gmail.com> wrote:
>> Moreover, those who've met me know I'm prone to saying that much of the
>> PubSub protocol is confusing and not necessarily useful in practice
> 
> I'm not going to disagree there, I've been saying it for years.

Yes, the full pubsub spec has all sorts of little sidelines to address 
less common use cases, but I'd say that 20% of the spec will be used 80% 
of the time. Would it help to call that out?

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080710/02e07b5a/attachment.bin 

From stpeter at stpeter.im  Thu Jul 10 14:50:51 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 10 Jul 2008 13:50:51 -0600
Subject: [Social] Federated PubSub
In-Reply-To: <8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>
	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>
Message-ID: <4876681B.6000202@stpeter.im>

anders conbere wrote:
> On Wed, Jul 9, 2008 at 10:25 AM, Blaine Cook <romeda at gmail.com> wrote:
>> On Wed, Jul 9, 2008 at 9:32 AM, Adam Pisoni <apisoni at geni.com> wrote:
>>> This is what I thought at first, but I'm trying to think ahead towards a
>>> time when I don't have to maintain buddy lists and permissions on each
>>> social network.
>> I think that each social network is different; the permissions I grant
>> people on my Flickr account are fundamentally different than those that I
>> grant on LinkedIn, which are again different from my Twitter account, and my
>> blog doesn't have any permissions at all. I like it that way, and I don't
>> actually want Flickr to know who I've approved on LinkedIn and vice-versa.
>> My IM buddy list is entirely different, and actually differs from IM network
>> to IM network, and account to account (i.e., I have multiple IM rosters).
> 
> I've always called this "Contexts", and while right now the roster
> doesn't have the tools to allow this kind of parceling of items, I
> think it's totally reasonable to imagine being able to delegate
> responsibility to portions of ones roster to a 3rd party, safely while
> maintaining the semblance of the roster.
> 
> You can almost imagine using transports to do this right now (register
> with the linkedin transport and it injects the linkedin buddy list
> into your roster and now we can grant access to those entities). But I
> think there might be a reasonable case for having first class support
> for this kind of stuff.

Yes we've talked about this for a while -- e.g., your "XSF" group is 
maintained by the Secretary of the XSF, your "Tiddlywinks" group is 
maintained by your tiddlywinks club, etc. But we've never quite finished 
  defining how that would work. A beginning is here:

http://www.xmpp.org/extensions/inbox/communities.html

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080710/6f229906/attachment.bin 

From nathanfritz at gmail.com  Thu Jul 10 14:52:53 2008
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Thu, 10 Jul 2008 12:52:53 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <4876670B.3040809@stpeter.im>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>
	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>
	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>
	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>
	<162fd9943f229f1916afd3758e1dfe26@localhost>
	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>
	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>
	<f5aae3ec0807091033v1a230c40t21112d21c137dce1@mail.gmail.com>
	<4876670B.3040809@stpeter.im>
Message-ID: <182eea400807101252m780b2093q859c3cc36d7c7f34@mail.gmail.com>

>
> Yes, the full pubsub spec has all sorts of little sidelines to address less
> common use cases, but I'd say that 20% of the spec will be used 80% of the
> time. Would it help to call that out?
>
> /psa
>
> I think the PEP spec does a good job of defining a VERY specific set of
features and calling it a complete spec.  I think more of this should be
done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080710/a0fe0f36/attachment-0001.htm 

From stpeter at stpeter.im  Thu Jul 10 14:58:37 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 10 Jul 2008 13:58:37 -0600
Subject: [Social] Federated PubSub
In-Reply-To: <182eea400807101252m780b2093q859c3cc36d7c7f34@mail.gmail.com>
References: <CE142D57-DC35-454D-99AB-0EA1F7AD6F98@geni.com>	<182eea400807081624x5d924e6fs8ace1e918bd394a9@mail.gmail.com>	<26ff4d2a0807081741o55dcec50qf0d5cbf97bc99fe9@mail.gmail.com>	<78749406-77DD-4B17-B067-0CC5E3F06910@geni.com>	<162fd9943f229f1916afd3758e1dfe26@localhost>	<f5aae3ec0807090117p13b0824di1dfb4a4ff9cc28e9@mail.gmail.com>	<d37b4b430807091018r65bc81anf503116a9d45a2dc@mail.gmail.com>	<f5aae3ec0807091033v1a230c40t21112d21c137dce1@mail.gmail.com>	<4876670B.3040809@stpeter.im>
	<182eea400807101252m780b2093q859c3cc36d7c7f34@mail.gmail.com>
Message-ID: <487669ED.60303@stpeter.im>

Nathan Fritz wrote:
>     Yes, the full pubsub spec has all sorts of little sidelines to
>     address less common use cases, but I'd say that 20% of the spec will
>     be used 80% of the time. Would it help to call that out?
> 
>     /psa
> 
> I think the PEP spec does a good job of defining a VERY specific set of 
> features and calling it a complete spec.  I think more of this should be 
> done.

Yes, that's a possibility too. XEP-0060 provides a large set of features 
and options you can choose from in defining specific application types 
or profiles or whatever we want to call them.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080710/9e8ec557/attachment.bin 

From danbri at danbri.org  Thu Jul 10 14:59:57 2008
From: danbri at danbri.org (Dan Brickley)
Date: Thu, 10 Jul 2008 20:59:57 +0100
Subject: [Social] Federated PubSub
In-Reply-To: <4876681B.6000202@stpeter.im>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>
	<4876681B.6000202@stpeter.im>
Message-ID: <48766A3D.1010103@danbri.org>

Ah, v interesting! Hadn't seen that before...

Dan

From danbri at danbri.org  Thu Jul 10 15:02:44 2008
From: danbri at danbri.org (Dan Brickley)
Date: Thu, 10 Jul 2008 21:02:44 +0100
Subject: [Social] Federated PubSub
In-Reply-To: <48766A3D.1010103@danbri.org>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>
	<4876681B.6000202@stpeter.im> <48766A3D.1010103@danbri.org>
Message-ID: <48766AE4.3090602@danbri.org>


re http://www.xmpp.org/extensions/inbox/communities.html

Dan Brickley wrote:
> Ah, v interesting! Hadn't seen that before...

Well that exciting gem was intended just for Peter. So much for not 
checking the To: field of my outgoing mails. Ahem.

Cool stuff though, really!
Dan

From stpeter at stpeter.im  Thu Jul 10 15:06:57 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 10 Jul 2008 14:06:57 -0600
Subject: [Social] Federated PubSub
In-Reply-To: <48766A3D.1010103@danbri.org>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>	<4876681B.6000202@stpeter.im>
	<48766A3D.1010103@danbri.org>
Message-ID: <48766BE1.10704@stpeter.im>

Dan Brickley wrote:
> Ah, v interesting! Hadn't seen that before...

Yeah, it's never made it out of "pre-XEP". Perhaps the discussions at 
the XMPP Summit 10 days from now will inspire us to publish this as a 
real XEP.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080710/7140f379/attachment.bin 

From stpeter at stpeter.im  Thu Jul 10 15:10:04 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 10 Jul 2008 14:10:04 -0600
Subject: [Social] Federated PubSub
In-Reply-To: <48766AE4.3090602@danbri.org>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>	<4876681B.6000202@stpeter.im>
	<48766A3D.1010103@danbri.org> <48766AE4.3090602@danbri.org>
Message-ID: <48766C9C.90103@stpeter.im>

Dan Brickley wrote:
> 
> re http://www.xmpp.org/extensions/inbox/communities.html
> 
> Dan Brickley wrote:
>> Ah, v interesting! Hadn't seen that before...
> 
> Well that exciting gem was intended just for Peter. So much for not 
> checking the To: field of my outgoing mails. Ahem.
> 
> Cool stuff though, really!

Oh yeah sorry about that, we typically deploy the evil reply-to-list 
feature on the jabber.org/xmpp.org lists. ;-)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080710/f8e186b3/attachment-0001.bin 

From apisoni at geni.com  Thu Jul 10 15:24:35 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Thu, 10 Jul 2008 13:24:35 -0700
Subject: [Social] Federated PubSub
In-Reply-To: <48766C9C.90103@stpeter.im>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>	<4876681B.6000202@stpeter.im>
	<48766A3D.1010103@danbri.org> <48766AE4.3090602@danbri.org>
	<48766C9C.90103@stpeter.im>
Message-ID: <9505F058-4120-4D89-A856-4AE5B7F2EFBF@geni.com>

I can see a lot of ways this pre-xep along with XEP-0060 can answer a  
lot of the questions people will have as to how to do exactly the  
kinds of things I was asking about.  A combination of personalized  
groups, authorization, pubsub nodes, and oath type handshakes to allow  
3rd party access or authentication against.

adam


On Jul 10, 2008, at 1:10 PM, Peter Saint-Andre wrote:

> Dan Brickley wrote:
>> re http://www.xmpp.org/extensions/inbox/communities.html
>> Dan Brickley wrote:
>>> Ah, v interesting! Hadn't seen that before...
>> Well that exciting gem was intended just for Peter. So much for not  
>> checking the To: field of my outgoing mails. Ahem.
>> Cool stuff though, really!
>
> Oh yeah sorry about that, we typically deploy the evil reply-to-list  
> feature on the jabber.org/xmpp.org lists. ;-)
>
> /psa
>


From stpeter at stpeter.im  Thu Jul 10 17:11:44 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 10 Jul 2008 16:11:44 -0600
Subject: [Social] Federated PubSub
In-Reply-To: <9505F058-4120-4D89-A856-4AE5B7F2EFBF@geni.com>
References: <1e368400807090418j774b999cgc1d1a1b5c9290068@mail.gmail.com>	<742E401B-8F55-45E4-AAF5-03FEAF3FE204@geni.com>	<d37b4b430807091025u657ccfc7p48987de3ddf97fc2@mail.gmail.com>	<8ca3fbe80807091054g546a661bv31d27e7b5fff35c3@mail.gmail.com>	<4876681B.6000202@stpeter.im>	<48766A3D.1010103@danbri.org>
	<48766AE4.3090602@danbri.org>	<48766C9C.90103@stpeter.im>
	<9505F058-4120-4D89-A856-4AE5B7F2EFBF@geni.com>
Message-ID: <48768920.60106@stpeter.im>

Adam Pisoni wrote:
> I can see a lot of ways this pre-xep along with XEP-0060 can answer a 
> lot of the questions people will have as to how to do exactly the kinds 
> of things I was asking about.  A combination of personalized groups, 
> authorization, pubsub nodes, and oath type handshakes to allow 3rd party 
> access or authentication against.

Sounds like a good topic for discussion at the XMPP Summit. :)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080710/d1d910b1/attachment.bin 

From danbri at danbri.org  Thu Jul 10 19:38:08 2008
From: danbri at danbri.org (Dan Brickley)
Date: Fri, 11 Jul 2008 01:38:08 +0100
Subject: [Social] Mozilla Weave and XMPP
Message-ID: <4876AB70.2050200@danbri.org>


Very intriguing,
http://arstechnica.com/news.ars/post/20080702-first-look-mozilla-weave-0-2-puts-firefox-in-the-cloud.html
Excerpted below. --danbri


[[
Mozilla Labs has announced the availability of Weave 0.2, the third 
major release of its experimental Firefox synchronization add-on. This 
version brings a broader feature set, improved reliability, and 
streamlined notification support. Although it is still in the early 
testing stage, Weave is already effective and easy to use.
Related Stories

     * Personas from Mozilla Labs give Firefox a sleek coat
     * Mozilla wants to put Firefox in the cloud and your pocket
     * Firefox 3 beta 5 released

When Mozilla launched Weave in December, the add-on offered basic 
support for storing the user's Firefox bookmarks and history in the 
cloud, allowing the synchronization of the data between computers. The 
latest version extends this functionality to also cover cookies, 
passwords, tabs, and form contents. Future versions will go further and 
also support synchronizing the user's extensions, themes, and search 
plugins. Mozilla intends to eventually implement an API that will enable 
third-party Firefox extensions to leverage Weave's synchronization 
capabilities for other kinds of user data.

... ...

This version also uses a more elaborate key system that will make it 
possible for users to securely share their bookmarks with other users. 
The UI for configuring sharing isn't operational yet, and the current 
security model only facilitates an all-or-nothing approach to sharing, 
but future versions will provide a higher level of granularity. The 
developers also intend to implement a notification system for sharing on 
top of the XMPP protocol.
]]


From thunder at mozilla.com  Thu Jul 10 21:39:49 2008
From: thunder at mozilla.com (Daniel Mills)
Date: Thu, 10 Jul 2008 19:39:49 -0700
Subject: [Social] Mozilla Weave and XMPP
In-Reply-To: <4876AB70.2050200@danbri.org>
References: <4876AB70.2050200@danbri.org>
Message-ID: <FC5939CF-0376-4094-BBC2-72630B7F899C@mozilla.com>

Hi Dan,

I'm the lead developer for Weave.  We've had our eyes on XMPP for some  
time now, but don't currently use it for much.  We did write a basic  
XMPP stack which allows us to pass around basic notifications for  
sharing ('so-and-so has shared bookmarks with you, click here to  
accept', that kind of thing), but will likely switch a more mature one  
soon (JSJaC looks promising).

Down the line, we want to explore with using XMPP to move around the  
actual data.  Currently we use WebDAV (mostly just GET, PUT, LOCK) to  
do that.

We're not yet to the point where we can spend a lot of time on XMPP  
integration, but we'd welcome any help / insight anyone might have.

Dan

On Jul 10, 2008, at 5:38 PM, Dan Brickley wrote:

>
> Very intriguing,
> http://arstechnica.com/news.ars/post/20080702-first-look-mozilla-weave-0-2-puts-firefox-in-the-cloud.html
> Excerpted below. --danbri
>
>
> [[
> Mozilla Labs has announced the availability of Weave 0.2, the third  
> major release of its experimental Firefox synchronization add-on.  
> This version brings a broader feature set, improved reliability, and  
> streamlined notification support. Although it is still in the early  
> testing stage, Weave is already effective and easy to use.
> Related Stories
>
>    * Personas from Mozilla Labs give Firefox a sleek coat
>    * Mozilla wants to put Firefox in the cloud and your pocket
>    * Firefox 3 beta 5 released
>
> When Mozilla launched Weave in December, the add-on offered basic  
> support for storing the user's Firefox bookmarks and history in the  
> cloud, allowing the synchronization of the data between computers.  
> The latest version extends this functionality to also cover cookies,  
> passwords, tabs, and form contents. Future versions will go further  
> and also support synchronizing the user's extensions, themes, and  
> search plugins. Mozilla intends to eventually implement an API that  
> will enable third-party Firefox extensions to leverage Weave's  
> synchronization capabilities for other kinds of user data.
>
> ... ...
>
> This version also uses a more elaborate key system that will make it  
> possible for users to securely share their bookmarks with other  
> users. The UI for configuring sharing isn't operational yet, and the  
> current security model only facilitates an all-or-nothing approach  
> to sharing, but future versions will provide a higher level of  
> granularity. The developers also intend to implement a notification  
> system for sharing on top of the XMPP protocol.
> ]]
>


From jeffm at iglou.com  Thu Jul 10 21:49:06 2008
From: jeffm at iglou.com (Jeff McAdams)
Date: Thu, 10 Jul 2008 22:49:06 -0400
Subject: [Social] Mozilla Weave and XMPP
In-Reply-To: <FC5939CF-0376-4094-BBC2-72630B7F899C@mozilla.com>
References: <4876AB70.2050200@danbri.org>
	<FC5939CF-0376-4094-BBC2-72630B7F899C@mozilla.com>
Message-ID: <4876CA22.4080504@iglou.com>

Daniel Mills wrote:
> I'm the lead developer for Weave.  We've had our eyes on XMPP for some
> time now, but don't currently use it for much.  We did write a basic
> XMPP stack which allows us to pass around basic notifications for
> sharing ('so-and-so has shared bookmarks with you, click here to
> accept', that kind of thing), but will likely switch a more mature one
> soon (JSJaC looks promising).

> Down the line, we want to explore with using XMPP to move around the
> actual data.  Currently we use WebDAV (mostly just GET, PUT, LOCK) to do
> that.

> We're not yet to the point where we can spend a lot of time on XMPP
> integration, but we'd welcome any help / insight anyone might have.

XEP-0049 please.  :)

So...that's historical...is there something newer that is supposed to be
the new hotness?  It seems like its almost ideal for Weave...at least in
concept.
-- 
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
                                       -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080710/37eeee7c/attachment.pgp 

From thunder at mozilla.com  Sat Jul 12 18:37:00 2008
From: thunder at mozilla.com (Daniel Mills)
Date: Sat, 12 Jul 2008 16:37:00 -0700
Subject: [Social] Mozilla Weave and XMPP
In-Reply-To: <4876CA22.4080504@iglou.com>
References: <4876AB70.2050200@danbri.org>
	<FC5939CF-0376-4094-BBC2-72630B7F899C@mozilla.com>
	<4876CA22.4080504@iglou.com>
Message-ID: <89383B88-05B0-4F42-87C3-852490D668A1@mozilla.com>

On Jul 10, 2008, at 7:49 PM, Jeff McAdams wrote:

> Daniel Mills wrote:
>
>> Down the line, we want to explore with using XMPP to move around the
>> actual data.  Currently we use WebDAV (mostly just GET, PUT, LOCK)  
>> to do
>> that.
>
> XEP-0049 please.  :)

I just took a look.  Interesting, though probably not quite what we're  
looking for... I think we'll want to explore some way of integrating  
XMPP that augments the current Weave backend (that is, keeping the  
current WebDAV-based storage, instead of replacing it).

Currently Weave stores encrypted JSON files on a server to represent a  
snapshot state, and changesets (as separate files).  I think a  
possible first step for XMPP integration, other than using it for  
notifications as we have now, would be to move around the changesets  
via XMPP.  However, the data payload would most likely remain  
encrypted (and probably compressed) JSON.

Dan

From stpeter at stpeter.im  Mon Jul 14 10:51:33 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 14 Jul 2008 09:51:33 -0600
Subject: [Social] Mozilla Weave and XMPP
In-Reply-To: <89383B88-05B0-4F42-87C3-852490D668A1@mozilla.com>
References: <4876AB70.2050200@danbri.org>	<FC5939CF-0376-4094-BBC2-72630B7F899C@mozilla.com>	<4876CA22.4080504@iglou.com>
	<89383B88-05B0-4F42-87C3-852490D668A1@mozilla.com>
Message-ID: <487B7605.4070407@stpeter.im>

Daniel Mills wrote:
> On Jul 10, 2008, at 7:49 PM, Jeff McAdams wrote:
> 
>> Daniel Mills wrote:
>>
>>> Down the line, we want to explore with using XMPP to move around the
>>> actual data.  Currently we use WebDAV (mostly just GET, PUT, LOCK) to do
>>> that.
>>
>> XEP-0049 please.  :)
> 
> I just took a look.  Interesting, though probably not quite what we're 
> looking for... I think we'll want to explore some way of integrating 
> XMPP that augments the current Weave backend (that is, keeping the 
> current WebDAV-based storage, instead of replacing it).
> 
> Currently Weave stores encrypted JSON files on a server to represent a 
> snapshot state, and changesets (as separate files).  I think a possible 
> first step for XMPP integration, other than using it for notifications 
> as we have now, would be to move around the changesets via XMPP.  
> However, the data payload would most likely remain encrypted (and 
> probably compressed) JSON.

Ages and ages ago, Joe Hildebrand and I worked on this:

http://www.xmpp.org/internet-drafts/attic/draft-hildebrand-webdav-notify-00.html

I'd be happy to update that I-D if you're interested in WebDAV change 
notifications over XMPP.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080714/ce1af512/attachment.bin 

From apisoni at geni.com  Wed Jul 16 20:46:17 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Wed, 16 Jul 2008 18:46:17 -0700
Subject: [Social] Memcache Viewer
Message-ID: <403FAC98-5FBE-427E-A6AF-6C6B0FE6DFB2@geni.com>

Many of you that are working on various xmpp bots and such likely use  
memcache for some stuff.  If you do and are using a Mac, you might  
want to check this out.

http://github.com/andrewfromgeni/mcinsight/tree/master

One of geni's developers just released it.  Basically, its a GUI  
version of memcache that lets you inspect what's in the cache.  It's  
still a work in progress, but I've already found it quite handy.

Thanks,
adam


From bear42 at gmail.com  Thu Jul 17 14:11:03 2008
From: bear42 at gmail.com (bear)
Date: Thu, 17 Jul 2008 15:11:03 -0400
Subject: [Social] Memcache Viewer
In-Reply-To: <403FAC98-5FBE-427E-A6AF-6C6B0FE6DFB2@geni.com>
References: <403FAC98-5FBE-427E-A6AF-6C6B0FE6DFB2@geni.com>
Message-ID: <f6c154a30807171211m26e60060wcf1d764a55e3f9c8@mail.gmail.com>

O.M.G.

if you are going to be at the summit I will gladly buy you a round of
whatever you are drinking!

On Wed, Jul 16, 2008 at 9:46 PM, Adam Pisoni <apisoni at geni.com> wrote:
> Many of you that are working on various xmpp bots and such likely use
> memcache for some stuff.  If you do and are using a Mac, you might want to
> check this out.
>
> http://github.com/andrewfromgeni/mcinsight/tree/master
>
> One of geni's developers just released it.  Basically, its a GUI version of
> memcache that lets you inspect what's in the cache.  It's still a work in
> progress, but I've already found it quite handy.
>
> Thanks,
> adam
>
>



-- 
---
Bear

bear at seesmic.com (work)
bear at code-bear.com (jabber & email)
http://code-bear.com/bearlog (weblog)

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29

From apisoni at geni.com  Thu Jul 17 14:33:37 2008
From: apisoni at geni.com (Adam Pisoni)
Date: Thu, 17 Jul 2008 12:33:37 -0700
Subject: [Social] Memcache Viewer
In-Reply-To: <f6c154a30807171211m26e60060wcf1d764a55e3f9c8@mail.gmail.com>
References: <403FAC98-5FBE-427E-A6AF-6C6B0FE6DFB2@geni.com>
	<f6c154a30807171211m26e60060wcf1d764a55e3f9c8@mail.gmail.com>
Message-ID: <7A29685D-8BA8-4B0C-993B-F12E8E3DDC94@geni.com>

Yup, I'll be there and I do love my beer!

adam

On Jul 17, 2008, at 12:11 PM, bear wrote:

> O.M.G.
>
> if you are going to be at the summit I will gladly buy you a round of
> whatever you are drinking!
>
> On Wed, Jul 16, 2008 at 9:46 PM, Adam Pisoni <apisoni at geni.com> wrote:
>> Many of you that are working on various xmpp bots and such likely use
>> memcache for some stuff.  If you do and are using a Mac, you might  
>> want to
>> check this out.
>>
>> http://github.com/andrewfromgeni/mcinsight/tree/master
>>
>> One of geni's developers just released it.  Basically, its a GUI  
>> version of
>> memcache that lets you inspect what's in the cache.  It's still a  
>> work in
>> progress, but I've already found it quite handy.
>>
>> Thanks,
>> adam
>>
>>
>
>
>
> -- 
> ---
> Bear
>
> bear at seesmic.com (work)
> bear at code-bear.com (jabber & email)
> http://code-bear.com/bearlog (weblog)
>
> PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29


From bob at wyman.us  Sat Jul 26 14:46:51 2008
From: bob at wyman.us (Bob Wyman)
Date: Sat, 26 Jul 2008 15:46:51 -0400
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
Message-ID: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>

The results of last week's XMPP Summit are beginning to bleed out as Ralphm
blogs the first of a promised series of notes on the event.
See: http://ralphm.net/blog/2008/07/26/xmpp_summit_5
and http://ralphm.net/blog/2008/07/26/xmpp_social_networks_1

Not surprisingly, it seems that those at the Summit agreed that the most
sensible way to federate XMPP PubSub servers is to have various servers
subscribe to each other. Thus, if I was running a microblogging service that
provided open access to "public" posts on my service, I might set up a node
to which I published all such "public" posts. Other microblogging services,
search engines, etc. would then subscribe to that node and, by doing so,
could mix messages published to my service with those published to their own
service.

This approach of "Federation via Subscription" has some distinct advantages
over the alernative, "Federation via Publishing", particularly in that it
eases spam control and management of server resources. However, it has a
distinct disadvantage in that it makes it somewhat harder to form networks
of cooperating servers.

In a system which relies on Federation via Subscription, all servers that
receive messages must have knowledge of potential publishers prior to any
data flowing between them. Given two servers, A and B, no data will flow
from A to B unless B first becomes aware of A and subsequently subscribes to
at least one node on A. The interesting question becomes: "How does B become
aware of A?". Since no data can flow between the two servers until a
subscription is established, if there are no other mechanisms provided, one
must assume that B discovers A via "out-of-band" communications such as
email messages, phone calls, directory lookups, etc.  These are, of course,
rather crude discovery methods and require manual configuration upon
discovery to establish federating subscriptions.

An alternative means for facilitating discovery would be to extend the
XEP-0060 PubSub specification to support a means for servers to publish
"Advertisements" which announce the availability of nodes for federation.
Advertisements would specify which nodes are available for federation and
what data will be published over those nodes. In order to reuse as much
existing framework as possible, Advertisements would be published just like
normal events, but they would be published to a "well known node" that is
commonly available on all services that support advertisements. This node
might be named: "http://jabber.org/protocol/pubsub#advertisements" and would
be like any other pubsub node in that it could be subscribed to, read, etc.
However, it would only support publishing <advertisement/>s not <event\>s.

The basic assumption behind federation is that two services will be
publishing data which is similar. For instance, that two micro-blogging
services will both be publishing micro-blogging entries that are formatted
as Atom entries. Agreement on the payload formats is essential to enable
federation. On the other hand, it is unreasonable to insist that all servers
use common node names. Thus, a mechanism is needed to provide a mapping from
some commonly agreed name for  a stream of data and the node name that is
used on any particular server. This can be accomplished by having the
Advertisement provide a mapping from commonly understood logical node names
to local concrete names. Thus, those creating micro-blogging standards might
say that the logical node name for publishing public posts is:
http://example.com/PublicMicroBloggingPosts. Then, a server that published
public posts on a node named "987ye879799wwww00" would simply provide both
the local and logical name for the node in the advertisement.

Given this introduction, an advertisement might look like the following:
(but, use of an xdata form might be more appropriate and more flexible...)

<iq type='set'
    from='new_service at denmark.lit'
    to='old_service.shakespeare.lit'
    id='ad1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>

    <publish node='http://jabber.org/protocol/pubsub#advertisements'>
      <advertisement xmlns='http://jabber.org/protocol/pubsub#advertisements'
                     id="*tag:new_service at denmark.lit,2008-07-24:1234*">
        <local node='987ye879799wwww00'
               format='http://example.com/post_format'\>
        <common node='http://example.com/PublicMicroBloggingPosts
<http://www.w3.org/2005/Atom>'\>
        <description>All public posts on this server.</description>
      </advertisement>
    </publish>
  </pubsub>
</iq>

If the Advertisement node is supported as a normal node, then it should be
possible for others to subscribe to the node and thus monitor advertisements
as they are published. Using filters, subscribers would either subscribe to
all advertisements published to the remote node or only to those
advertisements that are specific to that node. This permits advertisements
to flow to nodes not known to the advertiser as well as to permit servers to
ensure that they are rapidly made aware of changes to servers in which they
have an interest. Additional metadata such as keywords, etc. could be added
to make filtering easier and more effective.

Of course, "Advertisers" shouldn't expect that the mere act of advertising
will always result in a federating subscription. Server managers will still
often want to moderate the lists of nodes they subscribe to. Nonetheless,
the mechanism a foundation on which automatic subscription will sometimes
reasonably be built. For instance, I might wish to build a microblogging
aggregator that automatically subscribes to all remote services that claim
support for microblogging. Or, I might have a strong trust relationship with
some other service and decide that I would like to have my service subscribe
to anything advertised by the that service -- while manually reviewing
advertisements from other services... Many patterns are possible and
reasonable.

Those familar with blogging infrastructure will recognize a great deal of
similarity between the idea of Advertisements and that of "pinging." In
fact, within the blogging world, pinging is probably the most common and
useful means available to blog aggregators to discover new blogs. In fact,
it can be argued that the introduction of pinging and its use by blog
aggregators was probably one of the most essential steps in building the
blogging infrastructure as we know it today. Before pinging, the process of
discovering new blogs was horribly difficult, inaccurate and expensive for
service providers.

Comments? Does this sound reasonable?

bob wyman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080726/639f7e24/attachment.htm 

From jabber.org at ralphm.ik.nu  Sat Jul 26 16:09:57 2008
From: jabber.org at ralphm.ik.nu (Ralph Meijer)
Date: Sat, 26 Jul 2008 23:09:57 +0200
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
Message-ID: <20080726210957.GA75737@ik.nu>

On Sat, Jul 26, 2008 at 03:46:51PM -0400, Bob Wyman wrote:
> The results of last week's XMPP Summit are beginning to bleed out as Ralphm
> blogs the first of a promised series of notes on the event.
> See: http://ralphm.net/blog/2008/07/26/xmpp_summit_5
> and http://ralphm.net/blog/2008/07/26/xmpp_social_networks_1
> 
> Not surprisingly, it seems that those at the Summit agreed that the most
> sensible way to federate XMPP PubSub servers is to have various servers
> subscribe to each other. Thus, if I was running a microblogging service that
> provided open access to "public" posts on my service, I might set up a node to
> which I published all such "public" posts. Other microblogging services, search
> engines, etc. would then subscribe to that node and, by doing so, could mix
> messages published to my service with those published to their own service.
> 
> This approach of "Federation via Subscription" has some distinct advantages
> over the alernative, "Federation via Publishing", particularly in that it eases
> spam control and management of server resources. However, it has a distinct
> disadvantage in that it makes it somewhat harder to form networks of
> cooperating servers.

You couldn't wait until the end of the series did you? ;-)

> In a system which relies on Federation via Subscription, all servers that
> receive messages must have knowledge of potential publishers prior to any data
> flowing between them. Given two servers, A and B, no data will flow from A to B
> unless B first becomes aware of A and subsequently subscribes to at least one
> node on A. The interesting question becomes: "How does B become aware of A?".
> Since no data can flow between the two servers until a subscription is
> established, if there are no other mechanisms provided, one must assume that B
> discovers A via "out-of-band" communications such as email messages, phone
> calls, directory lookups, etc.  These are, of course, rather crude discovery
> methods and require manual configuration upon discovery to establish federating
> subscriptions.

The approach we wanted to take was to come up with the simplest possible
thing that could work. The federation via subscription model is actually
pretty much the as how we do federation in Jabber IM settings, and that
seems to work reasonably well, I would say. That said, we didn't stop
just were you seem to assume, although some have suggested it during the
summit. I won't outright dismiss what you suggest here, because I need
to take a better look at it, but we came up with a different way of
discovering pubsub nodes that I think is very natural to how the web
works.

The solution we came up with is using HTML and/or Atom link elements, on
pages/regular feeds that represent a person's updates, or his and and
his friends, etc. Pretty similar to how such pages currently point to
Atom/RSS feeds, we use a 'rel' of 'xmpp.feed' and the 'href' points to
the XMPP URI of the node, eg. xmpp:ralphm at jaiku.com?;node=updates. This
provides for an easy way to have one user on service A to subscribe to
another user on service B: the first user is very likely to know about
the page of the second user at site B. He inputs that URL and the
service can do auto discovery and subscribe all behind the scenes. I'll
expand on it more on my blog, but that seems the gist of it.

I probably have more thoughts on this but need some sleep first. Cya!

-- 
Groetjes,

ralphm

From lior.sion at gmail.com  Sat Jul 26 16:17:49 2008
From: lior.sion at gmail.com (Lior Sion)
Date: Sun, 27 Jul 2008 00:17:49 +0300
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <20080726210957.GA75737@ik.nu>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
Message-ID: <49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>

it sounds to me that using http to discover new updates will create heavy
stress on the server: tens of social networks each polling for new updates
all the time on all the combined users..

I might be missing something here, but if the publishing mechanism in
recursive (that is, I subscribe to twitter/user/ABC so I would get any new
thing related to ABC, their comments, tweets, presence, whatever) then what
will the new announcement mechanism add?

The difference between blog world pinging usages and social networking
federation is that in the blog world, there's a distinct one to many
relationship, or very close to it - many many small blogs updating a few
distinct aggregation services, while social federation is different, no?

Lior

On Sun, Jul 27, 2008 at 12:09 AM, Ralph Meijer <jabber.org at ralphm.ik.nu>wrote:

> On Sat, Jul 26, 2008 at 03:46:51PM -0400, Bob Wyman wrote:
> > The results of last week's XMPP Summit are beginning to bleed out as
> Ralphm
> > blogs the first of a promised series of notes on the event.
> > See: http://ralphm.net/blog/2008/07/26/xmpp_summit_5
> > and http://ralphm.net/blog/2008/07/26/xmpp_social_networks_1
> >
> > Not surprisingly, it seems that those at the Summit agreed that the most
> > sensible way to federate XMPP PubSub servers is to have various servers
> > subscribe to each other. Thus, if I was running a microblogging service
> that
> > provided open access to "public" posts on my service, I might set up a
> node to
> > which I published all such "public" posts. Other microblogging services,
> search
> > engines, etc. would then subscribe to that node and, by doing so, could
> mix
> > messages published to my service with those published to their own
> service.
> >
> > This approach of "Federation via Subscription" has some distinct
> advantages
> > over the alernative, "Federation via Publishing", particularly in that it
> eases
> > spam control and management of server resources. However, it has a
> distinct
> > disadvantage in that it makes it somewhat harder to form networks of
> > cooperating servers.
>
> You couldn't wait until the end of the series did you? ;-)
>
> > In a system which relies on Federation via Subscription, all servers that
> > receive messages must have knowledge of potential publishers prior to any
> data
> > flowing between them. Given two servers, A and B, no data will flow from
> A to B
> > unless B first becomes aware of A and subsequently subscribes to at least
> one
> > node on A. The interesting question becomes: "How does B become aware of
> A?".
> > Since no data can flow between the two servers until a subscription is
> > established, if there are no other mechanisms provided, one must assume
> that B
> > discovers A via "out-of-band" communications such as email messages,
> phone
> > calls, directory lookups, etc.  These are, of course, rather crude
> discovery
> > methods and require manual configuration upon discovery to establish
> federating
> > subscriptions.
>
> The approach we wanted to take was to come up with the simplest possible
> thing that could work. The federation via subscription model is actually
> pretty much the as how we do federation in Jabber IM settings, and that
> seems to work reasonably well, I would say. That said, we didn't stop
> just were you seem to assume, although some have suggested it during the
> summit. I won't outright dismiss what you suggest here, because I need
> to take a better look at it, but we came up with a different way of
> discovering pubsub nodes that I think is very natural to how the web
> works.
>
> The solution we came up with is using HTML and/or Atom link elements, on
> pages/regular feeds that represent a person's updates, or his and and
> his friends, etc. Pretty similar to how such pages currently point to
> Atom/RSS feeds, we use a 'rel' of 'xmpp.feed' and the 'href' points to
> the XMPP URI of the node, eg. xmpp:ralphm at jaiku.com?;node=updates. This
> provides for an easy way to have one user on service A to subscribe to
> another user on service B: the first user is very likely to know about
> the page of the second user at site B. He inputs that URL and the
> service can do auto discovery and subscribe all behind the scenes. I'll
> expand on it more on my blog, but that seems the gist of it.
>
> I probably have more thoughts on this but need some sleep first. Cya!
>
> --
> Groetjes,
>
> ralphm
>



-- 
thanks,
Lior Sion

Skype: sionlior | GTalk: lior.sion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080727/b598d3f1/attachment-0001.htm 

From ayende at ayende.com  Sat Jul 26 16:22:21 2008
From: ayende at ayende.com (Ayende Rahien)
Date: Sun, 27 Jul 2008 00:22:21 +0300
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
	<49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
Message-ID: <27d8d0930807261422i38c5f848vf1a1acce650750e4@mail.gmail.com>

I think that a more interesting question is what I am subscribing _to_.
Is this new service, or new users in known service?
That is, is this about getting information about new users in service I
trust, or about new services that pop up.


From lachlan at lachstock.com.au  Sat Jul 26 18:35:09 2008
From: lachlan at lachstock.com.au (Lachlan Hardy)
Date: Sun, 27 Jul 2008 09:35:09 +1000
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
	<49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
Message-ID: <1612cc300807261635l27858f76j245ecb6185a4e9@mail.gmail.com>

> it sounds to me that using http to discover new updates will create heavy
> stress on the server: tens of social networks each polling for new updates
> all the time on all the combined users..
>

I think he meant using HTTP to discover new sources to subscribe to and get
the updates from. Not using HTTP for the updates themselves.

Lachlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080727/061b12c5/attachment.htm 

From romeda at gmail.com  Sat Jul 26 18:41:39 2008
From: romeda at gmail.com (Blaine Cook)
Date: Sat, 26 Jul 2008 16:41:39 -0700
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
Message-ID: <d37b4b430807261641w77fa8d92gcf571cda1f6f6378@mail.gmail.com>

I think the answer is simpler than discovery. Email, SMTP, is a favourite
example of mine. Discovery is limited to "who handles the mail for this
person, user at example.com", and takes the form of a ubiquitous service (DNS)
at the lowest levels of the protocol, and thus only requires implementation
in core libraries.
If I want to share microblogging posts, photos, links, or any "social
object" in general, then I can do that. These services have been successful
in an asymmetric fashion. Although I'm interested in the BBC's photo stream,
it's unlikely they'll be as interested in my photo stream. In that sense,
the subscription model works well.

Moreover, It can work exactly like email, but in reverse --- I can tell my
grandmother that she can add me, "lattice at flickr.com", to her photo site
(e.g., on facebook) as a friend/family member. In the background, the
process works exactly like email, though instead of sending an SMTP message,
the server sends a subscription request method. The interaction designers
take over, and give me a way to say "YES, I'd like my grandmother, "
rcook at facebook.com" to see my photos." From then on, facebook.com will
receive a notification for "rcook at facebook.com" any time I post a photo. The
only discovery required were two DNS lookups to find the XMPP servers.

That's it. That enables messaging from one site to another, which in turn
enables the rich interaction models that drive my interest in this
technology.

b.


On Sat, Jul 26, 2008 at 12:46 PM, Bob Wyman <bob at wyman.us> wrote:

> The results of last week's XMPP Summit are beginning to bleed out as Ralphm
> blogs the first of a promised series of notes on the event.
> See: http://ralphm.net/blog/2008/07/26/xmpp_summit_5
> and http://ralphm.net/blog/2008/07/26/xmpp_social_networks_1
>
> Not surprisingly, it seems that those at the Summit agreed that the most
> sensible way to federate XMPP PubSub servers is to have various servers
> subscribe to each other. Thus, if I was running a microblogging service that
> provided open access to "public" posts on my service, I might set up a node
> to which I published all such "public" posts. Other microblogging services,
> search engines, etc. would then subscribe to that node and, by doing so,
> could mix messages published to my service with those published to their own
> service.
>
> This approach of "Federation via Subscription" has some distinct advantages
> over the alernative, "Federation via Publishing", particularly in that it
> eases spam control and management of server resources. However, it has a
> distinct disadvantage in that it makes it somewhat harder to form networks
> of cooperating servers.
>
> In a system which relies on Federation via Subscription, all servers that
> receive messages must have knowledge of potential publishers prior to any
> data flowing between them. Given two servers, A and B, no data will flow
> from A to B unless B first becomes aware of A and subsequently subscribes to
> at least one node on A. The interesting question becomes: "How does B become
> aware of A?". Since no data can flow between the two servers until a
> subscription is established, if there are no other mechanisms provided, one
> must assume that B discovers A via "out-of-band" communications such as
> email messages, phone calls, directory lookups, etc.  These are, of course,
> rather crude discovery methods and require manual configuration upon
> discovery to establish federating subscriptions.
>
> An alternative means for facilitating discovery would be to extend the
> XEP-0060 PubSub specification to support a means for servers to publish
> "Advertisements" which announce the availability of nodes for federation.
> Advertisements would specify which nodes are available for federation and
> what data will be published over those nodes. In order to reuse as much
> existing framework as possible, Advertisements would be published just like
> normal events, but they would be published to a "well known node" that is
> commonly available on all services that support advertisements. This node
> might be named: "http://jabber.org/protocol/pubsub#advertisements" and
> would be like any other pubsub node in that it could be subscribed to, read,
> etc. However, it would only support publishing <advertisement/>s not
> <event\>s.
>
> The basic assumption behind federation is that two services will be
> publishing data which is similar. For instance, that two micro-blogging
> services will both be publishing micro-blogging entries that are formatted
> as Atom entries. Agreement on the payload formats is essential to enable
> federation. On the other hand, it is unreasonable to insist that all servers
> use common node names. Thus, a mechanism is needed to provide a mapping from
> some commonly agreed name for  a stream of data and the node name that is
> used on any particular server. This can be accomplished by having the
> Advertisement provide a mapping from commonly understood logical node names
> to local concrete names. Thus, those creating micro-blogging standards might
> say that the logical node name for publishing public posts is:
> http://example.com/PublicMicroBloggingPosts. Then, a server that published
> public posts on a node named "987ye879799wwww00" would simply provide both
> the local and logical name for the node in the advertisement.
>
> Given this introduction, an advertisement might look like the following:
> (but, use of an xdata form might be more appropriate and more flexible...)
>
> <iq type='set'
>
>     from='new_service at denmark.lit'
>     to='old_service.shakespeare.lit'
>     id='ad1'>
>   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>
>     <publish node='http://jabber.org/protocol/pubsub#advertisements'>
>       <advertisement xmlns='http://jabber.org/protocol/pubsub#advertisements'
>
>                      id="*tag:new_service at denmark.lit,2008-07-24:1234*">
>         <local node='987ye879799wwww00'
>                format='http://example.com/post_format'\ <http://example.com/post_format'%5C>>
>
>         <common node='http://example.com/PublicMicroBloggingPosts <http://www.w3.org/2005/Atom>'\>
>         <description>All public posts on this server.</description>
>
>       </advertisement>
>     </publish>
>   </pubsub>
> </iq>
>
> If the Advertisement node is supported as a normal node, then it should be
> possible for others to subscribe to the node and thus monitor advertisements
> as they are published. Using filters, subscribers would either subscribe to
> all advertisements published to the remote node or only to those
> advertisements that are specific to that node. This permits advertisements
> to flow to nodes not known to the advertiser as well as to permit servers to
> ensure that they are rapidly made aware of changes to servers in which they
> have an interest. Additional metadata such as keywords, etc. could be added
> to make filtering easier and more effective.
>
> Of course, "Advertisers" shouldn't expect that the mere act of advertising
> will always result in a federating subscription. Server managers will still
> often want to moderate the lists of nodes they subscribe to. Nonetheless,
> the mechanism a foundation on which automatic subscription will sometimes
> reasonably be built. For instance, I might wish to build a microblogging
> aggregator that automatically subscribes to all remote services that claim
> support for microblogging. Or, I might have a strong trust relationship with
> some other service and decide that I would like to have my service subscribe
> to anything advertised by the that service -- while manually reviewing
> advertisements from other services... Many patterns are possible and
> reasonable.
>
> Those familar with blogging infrastructure will recognize a great deal of
> similarity between the idea of Advertisements and that of "pinging." In
> fact, within the blogging world, pinging is probably the most common and
> useful means available to blog aggregators to discover new blogs. In fact,
> it can be argued that the introduction of pinging and its use by blog
> aggregators was probably one of the most essential steps in building the
> blogging infrastructure as we know it today. Before pinging, the process of
> discovering new blogs was horribly difficult, inaccurate and expensive for
> service providers.
>
> Comments? Does this sound reasonable?
>
> bob wyman
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080726/d0347a96/attachment-0001.htm 

From bob at wyman.us  Sat Jul 26 19:14:24 2008
From: bob at wyman.us (Bob Wyman)
Date: Sat, 26 Jul 2008 20:14:24 -0400
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <20080726210957.GA75737@ik.nu>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
Message-ID: <45be5cd40807261714g2bf13b26t279a81a80f49121d@mail.gmail.com>

On Sat, Jul 26, 2008 at 5:09 PM, Ralph Meijer <jabber.org at ralphm.ik.nu>wrote:
> You couldn't wait until the end of the series did you? ;-)
But, this subject is too much fun to wait for! Please do finish your series
quickly so that we can all get in the discussion!

> The solution we came up with is using HTML
> and/or Atom link elements, on pages/regular
> feeds that represent a person's updates, or his
> and and his friends, etc.
The problem you're solving here is different from and orthogonal to the one
I was discussing. Your solution is perfectly reasonable as a means to
discover an individual feed and would be particularly useful in finding
private feeds. However, it is not well suited to the needs of a service that
is trying to provide aggregation, search or discover services over public
feeds.

Today we have things like Summize and TweetBeep that provide search and
alerting services within the limited realm of public content posted to
Twitter. But these services rely on special relationships with Twitter.com.
That situation is very different from what we have in the more open world of
blogging where Google Blogsearch, Technorati, etc. are able to provide
services that span across all blogging sites due to the fact that blogs ping
and are thus easily discovered by the aggregators. As soon as a new blog
goes online, it pings one or more pinging services and immediately has its
public postings incorporated into the various services that do blog
aggregation, search etc.. This is, I think, a good thing. But, it would be
hard to do the same with a solution such as the one you propose (links in
HTML, etc.) if only because we can't be sure that all microbloggers would
actually have HTML or Atom feeds to carry those links and, even if they did,
it can take an awfully long time for an aggregator to find them.

The other problem I'm trying to address in my proposal is how one goes about
reducing the overhead of handling all the subscriptions that would exist in
a large social network where the number of subscribers to any particular
feed follows a power law based on the total number of potential subscribers.
There are issues of scale here... Imagine that I'm running an XMPP service
that has millions of users and you're running a small service that handles
several dozen users. Now, imagine that one of your users is very popular and
has 1 million of my users as subscribers. If only point-to-point
subscriptions are possible, then your service is going to have to provide
local storage for 1 million subscriptions and whenever your user publishes
data, your service is going to have to either send 1 million copies of the
message to my service or at least one copy with 1 million SHIM headers (see
XEP-0060). In either case, that's a lot of data! The alternative is for my
service to subscribe to your feed of all public data and then do the
filtering inside my own servers. (Yes, I should probably report back to you
on subscription counts and such... But, that's a different issue.) But, for
that to work, I need a way to discover not just a specific feed, but the
node which carries all public feeds on your server.

I'm not suggesting that a service would advertise something as granular as a
single user's feed or that it would advertise private feeds. Rather,
services should advertise things like "Feed of all public posts."

The advertisment mechanism is, in fact, one that is well understood in the
world of general publish/subscribe systems and would, of course, be used to
provide discovery for a variety of feeds including those that aren't
"social" per se. For instance, a service might advertise that it provides
"Weather Feed", "Stock Market Quotes", "Blog Posts", "Ski Resort
Conditions", "Movie Show Times", etc... that could be subscribed to,
filtered, etc.

bob wyman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080726/2a07094e/attachment.htm 

From bob at wyman.us  Sat Jul 26 19:24:53 2008
From: bob at wyman.us (Bob Wyman)
Date: Sat, 26 Jul 2008 20:24:53 -0400
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <27d8d0930807261422i38c5f848vf1a1acce650750e4@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
	<49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
	<27d8d0930807261422i38c5f848vf1a1acce650750e4@mail.gmail.com>
Message-ID: <45be5cd40807261724w533d1ea5s615fec567e4d7341@mail.gmail.com>

On Sat, Jul 26, 2008 at 5:22 PM, Ayende Rahien <ayende at ayende.com> wrote:
> From the description, it sounds like it is something
> that is aimed at discovering new services, not new
> items within existing service.
Yes. You are right. My primary intent in suggesting the Advertisement
mechanism is to allow the discovery of new services rather than individual
feeds within those services. And, as pointed out in another message, I'm
primarily concerned with the scale related issues that arise when trying to
provide cross-service aggregation or in serving large numbers of subscribers
that are spread between different services. That's a very different set of
issues than those that appear in discover of private, personal feeds.

bob wyman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080726/2494d3dd/attachment.htm 

From ayende at ayende.com  Sat Jul 26 20:13:45 2008
From: ayende at ayende.com (Ayende Rahien)
Date: Sun, 27 Jul 2008 04:13:45 +0300
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <45be5cd40807261724w533d1ea5s615fec567e4d7341@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
	<49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
	<27d8d0930807261422i38c5f848vf1a1acce650750e4@mail.gmail.com>
	<45be5cd40807261724w533d1ea5s615fec567e4d7341@mail.gmail.com>
Message-ID: <27d8d0930807261813k5f75447gbe2f47cce67b5c4b@mail.gmail.com>

How many service providers do you expect to have?

On Sun, Jul 27, 2008 at 3:24 AM, Bob Wyman <bob at wyman.us> wrote:

> On Sat, Jul 26, 2008 at 5:22 PM, Ayende Rahien <ayende at ayende.com> wrote:
> > From the description, it sounds like it is something
> > that is aimed at discovering new services, not new
> > items within existing service.
> Yes. You are right. My primary intent in suggesting the Advertisement
> mechanism is to allow the discovery of new services rather than individual
> feeds within those services. And, as pointed out in another message, I'm
> primarily concerned with the scale related issues that arise when trying to
> provide cross-service aggregation or in serving large numbers of subscribers
> that are spread between different services. That's a very different set of
> issues than those that appear in discover of private, personal feeds.
>
> bob wyman
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080727/306038e1/attachment.htm 

From bob at wyman.us  Sat Jul 26 22:24:09 2008
From: bob at wyman.us (Bob Wyman)
Date: Sat, 26 Jul 2008 23:24:09 -0400
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <27d8d0930807261813k5f75447gbe2f47cce67b5c4b@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
	<49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
	<27d8d0930807261422i38c5f848vf1a1acce650750e4@mail.gmail.com>
	<45be5cd40807261724w533d1ea5s615fec567e4d7341@mail.gmail.com>
	<27d8d0930807261813k5f75447gbe2f47cce67b5c4b@mail.gmail.com>
Message-ID: <45be5cd40807262024u60d6f7b9od4dbda753c9a99e1@mail.gmail.com>

On Sat, Jul 26, 2008 at 9:13 PM, Ayende Rahien <ayende at ayende.com> wrote:
> How many service providers do you expect to have?
It depends on the service. Aggregation is hard. Thus, I wouldn't expect
there to be a great many aggregators at any one time since aggregation is
hard -- especially if the aggregators do things like offer real-time
"tracking" services (prospective search). But, even if there aren't very
many, we've learned from blogging and the web that aggregators are very
important to the health of the overall system. Ideally, there would always
be more than one provider of any particular service to ensure competition
and thus ensure pressure to innovate by offering improved or new
capabilities. However, if we don't establish the protocols to enable
aggregation of social networking content, we're going to find that the only
service providers that have a chance to enter the market will be those that
have special relationships to existing major social networks -- for
instance, like the relationship between Summize and Twitter. The result, of
course, will be that it becomes impossible to compete with existing services
by innovating. We'll have a lock-in that will not serve the community's
interests.

It should be recognized that the "advertisement" mechanism has utility for
many kinds of publish/subscribe service -- whether or not they are
specifically related to social networking. Thus, the examples I gave in an
earlier note of "News Feeds", "Stock Market Quotes", "sports results,"
"weather reports", etc.. It is best, I think, if we try to have social
networking systems rely on technologies that are generally useful. We should
avoid unnecessary specialization so that the Social Networking space can
benefit from innovation and ideas that come from other realms.

bob wyman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080726/dec906dc/attachment.htm 

From ayende at ayende.com  Sat Jul 26 22:33:20 2008
From: ayende at ayende.com (Ayende Rahien)
Date: Sun, 27 Jul 2008 06:33:20 +0300
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <45be5cd40807262024u60d6f7b9od4dbda753c9a99e1@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
	<49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
	<27d8d0930807261422i38c5f848vf1a1acce650750e4@mail.gmail.com>
	<45be5cd40807261724w533d1ea5s615fec567e4d7341@mail.gmail.com>
	<27d8d0930807261813k5f75447gbe2f47cce67b5c4b@mail.gmail.com>
	<45be5cd40807262024u60d6f7b9od4dbda753c9a99e1@mail.gmail.com>
Message-ID: <27d8d0930807262033n436154c7r70688af690e72fe1@mail.gmail.com>

Aggregation is only useful if you have a lot of individuals participating.
If you don't, you can just form direct links to the publishers, without the
need for aggregation

On Sun, Jul 27, 2008 at 6:24 AM, Bob Wyman <bob at wyman.us> wrote:

> On Sat, Jul 26, 2008 at 9:13 PM, Ayende Rahien <ayende at ayende.com> wrote:
> > How many service providers do you expect to have?
> It depends on the service. Aggregation is hard. Thus, I wouldn't expect
> there to be a great many aggregators at any one time since aggregation is
> hard -- especially if the aggregators do things like offer real-time
> "tracking" services (prospective search). But, even if there aren't very
> many, we've learned from blogging and the web that aggregators are very
> important to the health of the overall system. Ideally, there would always
> be more than one provider of any particular service to ensure competition
> and thus ensure pressure to innovate by offering improved or new
> capabilities. However, if we don't establish the protocols to enable
> aggregation of social networking content, we're going to find that the only
> service providers that have a chance to enter the market will be those that
> have special relationships to existing major social networks -- for
> instance, like the relationship between Summize and Twitter. The result, of
> course, will be that it becomes impossible to compete with existing services
> by innovating. We'll have a lock-in that will not serve the community's
> interests.
>
> It should be recognized that the "advertisement" mechanism has utility for
> many kinds of publish/subscribe service -- whether or not they are
> specifically related to social networking. Thus, the examples I gave in an
> earlier note of "News Feeds", "Stock Market Quotes", "sports results,"
> "weather reports", etc.. It is best, I think, if we try to have social
> networking systems rely on technologies that are generally useful. We should
> avoid unnecessary specialization so that the Social Networking space can
> benefit from innovation and ideas that come from other realms.
>
> bob wyman
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080727/2bf192b1/attachment-0001.htm 

From bob at wyman.us  Sat Jul 26 22:52:02 2008
From: bob at wyman.us (Bob Wyman)
Date: Sat, 26 Jul 2008 23:52:02 -0400
Subject: [Social] Federating Social Networks (Supporting Service
	Advertisements)
In-Reply-To: <27d8d0930807262033n436154c7r70688af690e72fe1@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>
	<20080726210957.GA75737@ik.nu>
	<49a191f40807261417v20ccdec0iffc06ad8a12eaa59@mail.gmail.com>
	<27d8d0930807261422i38c5f848vf1a1acce650750e4@mail.gmail.com>
	<45be5cd40807261724w533d1ea5s615fec567e4d7341@mail.gmail.com>
	<27d8d0930807261813k5f75447gbe2f47cce67b5c4b@mail.gmail.com>
	<45be5cd40807262024u60d6f7b9od4dbda753c9a99e1@mail.gmail.com>
	<27d8d0930807262033n436154c7r70688af690e72fe1@mail.gmail.com>
Message-ID: <45be5cd40807262052h2206495cndf7b60b7c2990e07@mail.gmail.com>

On Sat, Jul 26, 2008 at 11:33 PM, Ayende Rahien <ayende at ayende.com> wrote:
> Aggregation is only useful if you have a lot of
> individuals participating. If you don't, you can
> just form direct links to the publishers, without
> the need for aggregation.

Of course. But, your comment makes me think I misunderstood your earlier
question. Let me clarify:

I think there will be a small number of major aggregation services relative
to the number of publishing services. The future should not be like today.
Today, we've only got a small number of services publishing data. But, in
the future, if we can get good protocols defined, we should have a great
number of them. The key reason we have only a small number of social network
services today is that we don't have support in the system for federating
data between services. The result is that the earliest services benefit from
"network effects" and lock out any new services. If we get the federation
protocols right, then it will be possible for dozens, if not hundreds, of
different services to be started and have a chance to prove themselves.

bob wyman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080726/cb510220/attachment.htm 

From stpeter at stpeter.im  Tue Jul 29 15:44:13 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 29 Jul 2008 14:44:13 -0600
Subject: [Social] more summit follow-up
Message-ID: <488F811D.70509@stpeter.im>

Leo Dirac, who was at the XMPP Summit, has a helpful post here:

http://www.embracingchaos.com/2008/07/xmpp-pubsub-a-g.html

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080729/e16a8278/attachment.bin 

From stpeter at stpeter.im  Tue Jul 29 15:51:27 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 29 Jul 2008 14:51:27 -0600
Subject: [Social] more summit follow-up
In-Reply-To: <488F811D.70509@stpeter.im>
References: <488F811D.70509@stpeter.im>
Message-ID: <488F82CF.6030001@stpeter.im>

Peter Saint-Andre wrote:
> Leo Dirac, who was at the XMPP Summit, has a helpful post here:
> 
> http://www.embracingchaos.com/2008/07/xmpp-pubsub-a-g.html

So I think we have a few things to work on:

1. Define a SHIM header for sequence numbers.

2. Standardize the link rels we discussed.

3. Define an ad-hoc command for making a node of yours subscribe to 
another node for lightweight chaining or repeaters.

Then I think we're most of the way there. :)

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080729/d482ed8f/attachment.bin 

From stpeter at stpeter.im  Tue Jul 29 23:52:12 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 29 Jul 2008 22:52:12 -0600
Subject: [Social] Federating Social Networks (Supporting
	Service	Advertisements)
In-Reply-To: <45be5cd40807261714g2bf13b26t279a81a80f49121d@mail.gmail.com>
References: <45be5cd40807261246oe9637a3i7482e7ec09cf2275@mail.gmail.com>	<20080726210957.GA75737@ik.nu>
	<45be5cd40807261714g2bf13b26t279a81a80f49121d@mail.gmail.com>
Message-ID: <488FF37C.4000208@stpeter.im>

Bob Wyman wrote:
> On Sat, Jul 26, 2008 at 5:09 PM, Ralph Meijer <jabber.org 
> <http://jabber.org>@ralphm.ik.nu <http://ralphm.ik.nu>> wrote:
>  > You couldn't wait until the end of the series did you? ;-)
> But, this subject is too much fun to wait for! Please do finish your 
> series quickly so that we can all get in the discussion!
> 
>  > The solution we came up with is using HTML
>  > and/or Atom link elements, on pages/regular
>  > feeds that represent a person's updates, or his
>  > and and his friends, etc.
> The problem you're solving here is different from and orthogonal to the 
> one I was discussing. Your solution is perfectly reasonable as a means 
> to discover an individual feed and would be particularly useful in 
> finding private feeds. However, it is not well suited to the needs of a 
> service that is trying to provide aggregation, search or discover 
> services over public feeds.
> 
> Today we have things like Summize and TweetBeep that provide search and 
> alerting services within the limited realm of public content posted to 
> Twitter. But these services rely on special relationships with 
> Twitter.com. That situation is very different from what we have in the 
> more open world of blogging where Google Blogsearch, Technorati, etc. 
> are able to provide services that span across all blogging sites due to 
> the fact that blogs ping and are thus easily discovered by the 
> aggregators. As soon as a new blog goes online, it pings one or more 
> pinging services and immediately has its public postings incorporated 
> into the various services that do blog aggregation, search etc.. This 
> is, I think, a good thing. But, it would be hard to do the same with a 
> solution such as the one you propose (links in HTML, etc.) if only 
> because we can't be sure that all microbloggers would actually have HTML 
> or Atom feeds to carry those links and, even if they did, it can take an 
> awfully long time for an aggregator to find them.
> 
> The other problem I'm trying to address in my proposal is how one goes 
> about reducing the overhead of handling all the subscriptions that would 
> exist in a large social network where the number of subscribers to any 
> particular feed follows a power law based on the total number of 
> potential subscribers. There are issues of scale here... Imagine that 
> I'm running an XMPP service that has millions of users and you're 
> running a small service that handles several dozen users. Now, imagine 
> that one of your users is very popular and has 1 million of my users as 
> subscribers. If only point-to-point subscriptions are possible, then 
> your service is going to have to provide local storage for 1 million 
> subscriptions and whenever your user publishes data, your service is 
> going to have to either send 1 million copies of the message to my 
> service or at least one copy with 1 million SHIM headers (see XEP-0060). 
> In either case, that's a lot of data! The alternative is for my service 
> to subscribe to your feed of all public data and then do the filtering 
> inside my own servers. (Yes, I should probably report back to you on 
> subscription counts and such... But, that's a different issue.) But, for 
> that to work, I need a way to discover not just a specific feed, but the 
> node which carries all public feeds on your server.

As I understand it, what Ralph and Blaine and those guys came up with 
while I was out of the room working on Jingle is that we could chain 
pubsub nodes by having a "repeater node" at bigprovider.com subscribe to 
that super-popular node at smallprovider.com. Clearly this works only 
for open pubsub nodes (no fancy ACLs to be shared), but this approach 
provides the simplest way to share information across services. We need 
to define an ad-hoc command for subscribing mynode to yournode but that 
should be pretty straightforward.

/psa



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080729/1bb29123/attachment-0001.bin 

From mayufei at cn.ibm.com  Wed Jul 30 03:03:15 2008
From: mayufei at cn.ibm.com (Yu Fei Ma)
Date: Wed, 30 Jul 2008 16:03:15 +0800
Subject: [Social] AUTO: Yu Fei Ma is out of the office. (returning
	2008-08-01)
Message-ID: <OFE83640DC.668E400E-ON48257496.002C3E88-48257496.002C3E89@cn.ibm.com>



I am out of the office until 2008-08-01.

I am on my training class from July 29 to July 31 without intranet access.
However, I will try to do it during the night. Sorry for any inconvenience.




Note: This is an automated response to your message social Digest, Vol 5,
Issue 20 sent on 7/30/08 13:09:03.
This is the only notification you will receive while this person is away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/fdb3b704/attachment.htm 

From bob at wyman.us  Wed Jul 30 12:26:13 2008
From: bob at wyman.us (Bob Wyman)
Date: Wed, 30 Jul 2008 13:26:13 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
Message-ID: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>

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.com and @foo at indenti.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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/979aa164/attachment.htm 

From chris.messina at gmail.com  Wed Jul 30 13:22:40 2008
From: chris.messina at gmail.com (Chris Messina)
Date: Wed, 30 Jul 2008 11:22:40 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
Message-ID: <1bc4603e0807301122u6ad4eac3n780fd5ed81531b80@mail.gmail.com>

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.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.com and @foo at indenti.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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/ca1c558f/attachment.htm 

From aconbere at gmail.com  Wed Jul 30 13:56:24 2008
From: aconbere at gmail.com (anders conbere)
Date: Wed, 30 Jul 2008 11:56:24 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
Message-ID: <8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>

On Wed, Jul 30, 2008 at 10:26 AM, Bob Wyman <bob at wyman.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.com and @foo at indenti.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 at 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.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
>
>

From appleman at gmail.com  Wed Jul 30 14:07:57 2008
From: appleman at gmail.com (Henry H)
Date: Wed, 30 Jul 2008 14:07:57 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <1bc4603e0807301122u6ad4eac3n780fd5ed81531b80@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<1bc4603e0807301122u6ad4eac3n780fd5ed81531b80@mail.gmail.com>
Message-ID: <a60f29b10807301207h6c655901w856992a308ebdac2@mail.gmail.com>

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 at 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.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.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.com and @foo at indenti.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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/fac76623/attachment.htm 

From chris.messina at gmail.com  Wed Jul 30 14:38:43 2008
From: chris.messina at gmail.com (Chris Messina)
Date: Wed, 30 Jul 2008 12:38:43 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807301207h6c655901w856992a308ebdac2@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<1bc4603e0807301122u6ad4eac3n780fd5ed81531b80@mail.gmail.com>
	<a60f29b10807301207h6c655901w856992a308ebdac2@mail.gmail.com>
Message-ID: <1bc4603e0807301238g50fc9ff7xeb1cf58dbc3a6219@mail.gmail.com>

...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.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 at 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.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.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.com and @foo at indenti.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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/6fb6bae9/attachment-0001.htm 

From appleman at gmail.com  Wed Jul 30 14:44:16 2008
From: appleman at gmail.com (Henry H)
Date: Wed, 30 Jul 2008 14:44:16 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <1bc4603e0807301238g50fc9ff7xeb1cf58dbc3a6219@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<1bc4603e0807301122u6ad4eac3n780fd5ed81531b80@mail.gmail.com>
	<a60f29b10807301207h6c655901w856992a308ebdac2@mail.gmail.com>
	<1bc4603e0807301238g50fc9ff7xeb1cf58dbc3a6219@mail.gmail.com>
Message-ID: <a60f29b10807301244x12395dabo296fa0c2dbc3a366@mail.gmail.com>

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.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.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 at 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.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.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.com and @foo at indenti.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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/a60465ad/attachment.htm 

From bob at wyman.us  Wed Jul 30 14:44:18 2008
From: bob at wyman.us (Bob Wyman)
Date: Wed, 30 Jul 2008 15:44:18 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
Message-ID: <45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>

On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere at gmail.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.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.com and anders at example.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/f201f163/attachment.htm 

From aconbere at gmail.com  Wed Jul 30 14:56:52 2008
From: aconbere at gmail.com (anders conbere)
Date: Wed, 30 Jul 2008 12:56:52 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
Message-ID: <8ca3fbe80807301256r2583004bgfbbb74b72ad2de37@mail.gmail.com>

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

From appleman at gmail.com  Wed Jul 30 14:57:50 2008
From: appleman at gmail.com (Henry H)
Date: Wed, 30 Jul 2008 14:57:50 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
Message-ID: <a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>

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.us> wrote:

> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere at gmail.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.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.com and anders at example.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/37e38f2e/attachment-0001.htm 

From bob at wyman.us  Wed Jul 30 15:23:29 2008
From: bob at wyman.us (Bob Wyman)
Date: Wed, 30 Jul 2008 16:23:29 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
Message-ID: <45be5cd40807301323v7d9cce49tbbac029783142ea9@mail.gmail.com>

On Wed, Jul 30, 2008 at 3:57 PM, Henry H <appleman at gmail.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.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.com and susan at bad.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/f8a0613a/attachment.htm 

From ayende at ayende.com  Wed Jul 30 15:37:12 2008
From: ayende at ayende.com (Ayende Rahien)
Date: Wed, 30 Jul 2008 23:37:12 +0300
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301323v7d9cce49tbbac029783142ea9@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
	<45be5cd40807301323v7d9cce49tbbac029783142ea9@mail.gmail.com>
Message-ID: <27d8d0930807301337h612871bdi9bc6ba0a2c8010a8@mail.gmail.com>

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.us> wrote:

> On Wed, Jul 30, 2008 at 3:57 PM, Henry H <appleman at gmail.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.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.com and susan at bad.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/8df1d54e/attachment.htm 

From bob at wyman.us  Wed Jul 30 15:50:03 2008
From: bob at wyman.us (Bob Wyman)
Date: Wed, 30 Jul 2008 16:50:03 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <27d8d0930807301337h612871bdi9bc6ba0a2c8010a8@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
	<45be5cd40807301323v7d9cce49tbbac029783142ea9@mail.gmail.com>
	<27d8d0930807301337h612871bdi9bc6ba0a2c8010a8@mail.gmail.com>
Message-ID: <45be5cd40807301350x37854c1as5c969f55ff327888@mail.gmail.com>

On Wed, Jul 30, 2008 at 4:37 PM, Ayende Rahien <ayende at ayende.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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/1eb6a168/attachment.htm 

From ayende at ayende.com  Wed Jul 30 15:55:04 2008
From: ayende at ayende.com (Ayende Rahien)
Date: Wed, 30 Jul 2008 23:55:04 +0300
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301350x37854c1as5c969f55ff327888@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
	<45be5cd40807301323v7d9cce49tbbac029783142ea9@mail.gmail.com>
	<27d8d0930807301337h612871bdi9bc6ba0a2c8010a8@mail.gmail.com>
	<45be5cd40807301350x37854c1as5c969f55ff327888@mail.gmail.com>
Message-ID: <27d8d0930807301355gb90f945xee7ff1089b0df059@mail.gmail.com>

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

> On Wed, Jul 30, 2008 at 4:37 PM, Ayende Rahien <ayende at ayende.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.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/4bdc637c/attachment.htm 

From dave at cridland.net  Wed Jul 30 16:05:11 2008
From: dave at cridland.net (Dave Cridland)
Date: Wed, 30 Jul 2008 22:05:11 +0100
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
Message-ID: <7078.1217451911.188646@peirce.dave.cridland.net>

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.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.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.com and anders at example.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.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.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.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.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From appleman at gmail.com  Wed Jul 30 16:07:58 2008
From: appleman at gmail.com (Henry H)
Date: Wed, 30 Jul 2008 16:07:58 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301350x37854c1as5c969f55ff327888@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
	<45be5cd40807301323v7d9cce49tbbac029783142ea9@mail.gmail.com>
	<27d8d0930807301337h612871bdi9bc6ba0a2c8010a8@mail.gmail.com>
	<45be5cd40807301350x37854c1as5c969f55ff327888@mail.gmail.com>
Message-ID: <a60f29b10807301407g3b0b9d4fgab0579ed404eca5b@mail.gmail.com>

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.us> wrote:

> On Wed, Jul 30, 2008 at 4:37 PM, Ayende Rahien <ayende at ayende.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.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/ef59f519/attachment-0001.htm 

From appleman at gmail.com  Wed Jul 30 16:15:10 2008
From: appleman at gmail.com (Henry H)
Date: Wed, 30 Jul 2008 16:15:10 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <7078.1217451911.188646@peirce.dave.cridland.net>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
Message-ID: <a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>

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.com or Bob at foo.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.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.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.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.com and anders at example.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.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.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.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.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/ecff3757/attachment.htm 

From bob at wyman.us  Wed Jul 30 16:28:15 2008
From: bob at wyman.us (Bob Wyman)
Date: Wed, 30 Jul 2008 17:28:15 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
	<a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
Message-ID: <45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>

On Wed, Jul 30, 2008 at 5:15 PM, Henry H <appleman at gmail.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.com and Susan at bad.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.com from Susan at good.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/1e2c7288/attachment.htm 

From appleman at gmail.com  Wed Jul 30 17:46:02 2008
From: appleman at gmail.com (Henry H)
Date: Wed, 30 Jul 2008 17:46:02 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
	<a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
	<45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>
Message-ID: <a60f29b10807301546u2ae06afct6b23139adc590fd3@mail.gmail.com>

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.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.us> wrote:

> On Wed, Jul 30, 2008 at 5:15 PM, Henry H <appleman at gmail.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.com and Susan at bad.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.com from Susan at good.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/9b4206fc/attachment.htm 

From sociallist45098 at aquick.org  Wed Jul 30 18:44:27 2008
From: sociallist45098 at aquick.org (Adam Fields)
Date: Wed, 30 Jul 2008 19:44:27 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807301546u2ae06afct6b23139adc590fd3@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
	<a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
	<45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>
	<a60f29b10807301546u2ae06afct6b23139adc590fd3@mail.gmail.com>
Message-ID: <20080730234427.GM26744@lola.aquick.org>

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.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

From appleman at gmail.com  Wed Jul 30 19:04:56 2008
From: appleman at gmail.com (Henry H)
Date: Wed, 30 Jul 2008 19:04:56 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <20080730234427.GM26744@lola.aquick.org>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
	<a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
	<45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>
	<a60f29b10807301546u2ae06afct6b23139adc590fd3@mail.gmail.com>
	<20080730234427.GM26744@lola.aquick.org>
Message-ID: <a60f29b10807301704v1123faden567405d30f83975b@mail.gmail.com>

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.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.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080730/868a7407/attachment-0001.htm 

From fireun at gmail.com  Wed Jul 30 20:22:15 2008
From: fireun at gmail.com (fireun ukobach)
Date: Wed, 30 Jul 2008 18:22:15 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807301704v1123faden567405d30f83975b@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
	<a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
	<45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>
	<a60f29b10807301546u2ae06afct6b23139adc590fd3@mail.gmail.com>
	<20080730234427.GM26744@lola.aquick.org>
	<a60f29b10807301704v1123faden567405d30f83975b@mail.gmail.com>
Message-ID: <a13e66800807301822g3853c234l9057afc40fd9d9e8@mail.gmail.com>

My original impression of user at jabber.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.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 at system@domain.com is really, really stupid. IMHO. You will never
get user conformity on that.

cheers,
-=C=-

From steveivy at gmail.com  Wed Jul 30 21:25:31 2008
From: steveivy at gmail.com (Steve Ivy)
Date: Wed, 30 Jul 2008 19:25:31 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <20080730234427.GM26744@lola.aquick.org>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
	<a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
	<45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>
	<a60f29b10807301546u2ae06afct6b23139adc590fd3@mail.gmail.com>
	<20080730234427.GM26744@lola.aquick.org>
Message-ID: <d9a04aea0807301925t54e1205gf612dd8c4cf1ba29@mail.gmail.com>

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.com or
factoryjoe at factoryjoe.com.

--Steve


On Wed, Jul 30, 2008 at 4:44 PM, Adam Fields <sociallist45098 at aquick.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.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

From lachlan at lachstock.com.au  Wed Jul 30 22:38:09 2008
From: lachlan at lachstock.com.au (Lachlan Hardy)
Date: Thu, 31 Jul 2008 13:38:09 +1000
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <d9a04aea0807301925t54e1205gf612dd8c4cf1ba29@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<7078.1217451911.188646@peirce.dave.cridland.net>
	<a60f29b10807301415l312149f4j4444489268333501@mail.gmail.com>
	<45be5cd40807301428r2977e0ffy750e47a698a519@mail.gmail.com>
	<a60f29b10807301546u2ae06afct6b23139adc590fd3@mail.gmail.com>
	<20080730234427.GM26744@lola.aquick.org>
	<d9a04aea0807301925t54e1205gf612dd8c4cf1ba29@mail.gmail.com>
Message-ID: <1612cc300807302038l3063a3b7ye8c5f38d48f97894@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/7a55bbdb/attachment.htm 

From stpeter at stpeter.im  Thu Jul 31 00:01:26 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 30 Jul 2008 23:01:26 -0600
Subject: [Social] OAuth update
Message-ID: <48914726.4040903@stpeter.im>

I'm making progress on updating XEP-0235 to be OAuth-specific. I'll try 
to finish the edits tomorrow. Here's a sneak peek (thanks to Fritzy for 
the chat earlier today):

http://www.xmpp.org/extensions/tmp/xep-0235-0.4.html

I have my doubts about the invitation use case, so I may remove those 
provisionally until we figure out whether it's reasonable to use OAuth 
in that context.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080730/0fdf9500/attachment.bin 

From sh at defuze.org  Thu Jul 31 03:08:22 2008
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Thu, 31 Jul 2008 10:08:22 +0200 (CEST)
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
Message-ID: <56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>


> On Wed, Jul 30, 2008 at 2:56 PM, anders conbere <aconbere at gmail.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.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.com and anders at example.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

From gnauck at ag-software.de  Thu Jul 31 03:15:16 2008
From: gnauck at ag-software.de (Alexander Gnauck)
Date: Thu, 31 Jul 2008 10:15:16 +0200
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
Message-ID: <32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>

> 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


From melo at simplicidade.org  Thu Jul 31 03:21:04 2008
From: melo at simplicidade.org (Pedro Melo)
Date: Thu, 31 Jul 2008 09:21:04 +0100
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
Message-ID: <2D69E38E-5963-47D1-A0CF-7721588A94CD@simplicidade.org>


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.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.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.com and  
> anders at example.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.org
Use XMPP!



From jm at liotier.org  Thu Jul 31 04:08:42 2008
From: jm at liotier.org (Jean-Marc Liotier)
Date: Thu, 31 Jul 2008 11:08:42 +0200
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
Message-ID: <20080731090842.GA3781@kivu.grabeuh.com>

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.


From sh at defuze.org  Thu Jul 31 04:03:29 2008
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Thu, 31 Jul 2008 11:03:29 +0200 (CEST)
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
Message-ID: <51008.195.101.247.164.1217495009.squirrel@mail1.webfaction.com>


>> 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

From jm at liotier.org  Thu Jul 31 04:18:44 2008
From: jm at liotier.org (Jean-Marc Liotier)
Date: Thu, 31 Jul 2008 11:18:44 +0200
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
Message-ID: <20080731091844.GB3781@kivu.grabeuh.com>

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.


From jm at liotier.org  Thu Jul 31 04:24:25 2008
From: jm at liotier.org (Jean-Marc Liotier)
Date: Thu, 31 Jul 2008 11:24:25 +0200
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <51008.195.101.247.164.1217495009.squirrel@mail1.webfaction.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<51008.195.101.247.164.1217495009.squirrel@mail1.webfaction.com>
Message-ID: <20080731092425.GC3781@kivu.grabeuh.com>

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/


From jm at liotier.org  Thu Jul 31 04:26:21 2008
From: jm at liotier.org (Jean-Marc Liotier)
Date: Thu, 31 Jul 2008 11:26:21 +0200
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <20080731090842.GA3781@kivu.grabeuh.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<a60f29b10807301257m6516de6av8758a9b24bcc75b9@mail.gmail.com>
	<20080731090842.GA3781@kivu.grabeuh.com>
Message-ID: <20080731092621.GD3781@kivu.grabeuh.com>

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...


From sh at defuze.org  Thu Jul 31 04:30:57 2008
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Thu, 31 Jul 2008 11:30:57 +0200 (CEST)
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <20080731092425.GC3781@kivu.grabeuh.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<51008.195.101.247.164.1217495009.squirrel@mail1.webfaction.com>
	<20080731092425.GC3781@kivu.grabeuh.com>
Message-ID: <32969.195.101.247.164.1217496657.squirrel@mail1.webfaction.com>


> 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

From melo at simplicidade.org  Thu Jul 31 04:58:16 2008
From: melo at simplicidade.org (Pedro Melo)
Date: Thu, 31 Jul 2008 10:58:16 +0100
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
Message-ID: <C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>

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.org
Use XMPP!



From melo at simplicidade.org  Thu Jul 31 07:24:55 2008
From: melo at simplicidade.org (Pedro Melo)
Date: Thu, 31 Jul 2008 13:24:55 +0100
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
Message-ID: <82E95A86-23C2-4E2D-86DA-ECC390902EA1@simplicidade.org>

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.com and @foo at indenti.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.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.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.org
Use XMPP!



From appleman at gmail.com  Thu Jul 31 07:34:53 2008
From: appleman at gmail.com (Henry H)
Date: Thu, 31 Jul 2008 07:34:53 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
Message-ID: <a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>

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 at domain is a good way to identify people
@name at 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 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/f6854514/attachment.htm 

From joec0914 at gmail.com  Thu Jul 31 08:11:12 2008
From: joec0914 at gmail.com (Joe Cascio, Jr.)
Date: Thu, 31 Jul 2008 09:11:12 -0400
Subject: [Social] Problem related to namespaces... ID proliferation.
Message-ID: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>

I'd like to hear some discussion on a related topic, which is ID
proliferation. I would think Chris Messina might have something to say on
the topic, being involved in the DISO project. In addition to the problem of
having more than one person having "@susan" there is a growing problem of a
single Susan being Susan at twitter.com, Susie at identi.ca, SueBlue at whatever.com,
etc.

I'm bothered by the fact that most discussion seems to assume that identity
is merely a projection of XMPP's ID mechanism. Wouldn't it be better to have
someone's OpenID meta-data provide a discovery mechanism for any of several
servers that they might be contacted on? Then the XMPP address/identity
would be a lower level routing, perhaps invisible to the end user?

This surely doesn't solve the SMS problem, which is due to the fact that
simply more characters are needed to create globally unique addresses, but
I'd like to make one observation about short (domain-specific) vs. long
(domain-independent) names.

In the set of all people that I talk to, on Twitter, email, or IM, I have a
hard time coming up with any two that have the same local short name. Yes,
there are multiple JoeCascios out there, but I don't think any of my online
contacts know them. Ok, so my name is fairly uncommon. What about a
JohnSmith? How many JohnSmiths do you know? Couldn't potential conflicts be
handled by a personal nickname? The globally unique low level id could be
mapped to my own local short alias for that person. The default short alias
is their own defined short name, but I could override that to let me
distinguish messages arriving at my device.

JoeC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/19983f34/attachment.htm 

From appleman at gmail.com  Thu Jul 31 08:30:52 2008
From: appleman at gmail.com (Henry H)
Date: Thu, 31 Jul 2008 08:30:52 -0500
Subject: [Social] Problem related to namespaces... ID proliferation.
In-Reply-To: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
References: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
Message-ID: <a60f29b10807310630h324a8f99heb0f544113584bb1@mail.gmail.com>

You just summarized the last post (as of now - sans the summary post) of the
thread you're referring to - or you can just look at the last line of the
summary post :-)

On Thu, Jul 31, 2008 at 8:11 AM, Joe Cascio, Jr. <joec0914 at gmail.com> wrote:

> I'd like to hear some discussion on a related topic, which is ID
> proliferation. I would think Chris Messina might have something to say on
> the topic, being involved in the DISO project. In addition to the problem of
> having more than one person having "@susan" there is a growing problem of a
> single Susan being Susan at twitter.com, Susie at identi.ca,
> SueBlue at whatever.com, etc.
>
> I'm bothered by the fact that most discussion seems to assume that identity
> is merely a projection of XMPP's ID mechanism. Wouldn't it be better to have
> someone's OpenID meta-data provide a discovery mechanism for any of several
> servers that they might be contacted on? Then the XMPP address/identity
> would be a lower level routing, perhaps invisible to the end user?
>
> This surely doesn't solve the SMS problem, which is due to the fact that
> simply more characters are needed to create globally unique addresses, but
> I'd like to make one observation about short (domain-specific) vs. long
> (domain-independent) names.
>
> In the set of all people that I talk to, on Twitter, email, or IM, I have a
> hard time coming up with any two that have the same local short name. Yes,
> there are multiple JoeCascios out there, but I don't think any of my online
> contacts know them. Ok, so my name is fairly uncommon. What about a
> JohnSmith? How many JohnSmiths do you know? Couldn't potential conflicts be
> handled by a personal nickname? The globally unique low level id could be
> mapped to my own local short alias for that person. The default short alias
> is their own defined short name, but I could override that to let me
> distinguish messages arriving at my device.
>
> JoeC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/910a22f9/attachment.htm 

From jabber.org at ralphm.ik.nu  Thu Jul 31 08:50:55 2008
From: jabber.org at ralphm.ik.nu (Ralph Meijer)
Date: Thu, 31 Jul 2008 15:50:55 +0200
Subject: [Social] OAuth update
In-Reply-To: <48914726.4040903@stpeter.im>
References: <48914726.4040903@stpeter.im>
Message-ID: <4891C33F.3090505@ralphm.ik.nu>

Peter Saint-Andre wrote:
> I'm making progress on updating XEP-0235 to be OAuth-specific. I'll try 
> to finish the edits tomorrow. Here's a sneak peek (thanks to Fritzy for 
> the chat earlier today):
> 
> http://www.xmpp.org/extensions/tmp/xep-0235-0.4.html
> 
> I have my doubts about the invitation use case, so I may remove those 
> provisionally until we figure out whether it's reasonable to use OAuth 
> in that context.
> 
> Peter

Hi,

I have read this draft in detail and have some doubts about its scope 
and use cases. I also discussed this with my colleague, Marc Worrell, 
who has written a full PHP implementation of OAuth (service and consumer.

First off, the use case we discussed at the XMPP Summit was a Consumer 
using an OAuth access token to do a particular request over XMPP on 
behalf of a User. The assumption being that the access token would be 
acquired out-of-band (using regular, over-HTTP OAuth exchanges).

I don't see any particular use base beyond that one. OAuth was designed 
for a state-less protocol with no authentication and identity built-in. 
In my opinion, for all the XMPP-only use cases that would be solved with 
OAuth in HTTP, we don't need any tokens and/or signatures.

I first want to tackle the invitation use case in this draft. This 
example does not speak of a request token being acquired, although it is 
included in the access token request. Also I don't understand the 
mechanics of the consumer key here. If it belongs to the invitee, how 
does the inviter know it? Why exchange it between User and Consumer? I 
don't think this exchange actually works in practice.

Taking a step back to look at the invite use-case, I notice that what is 
desired, is a way to let the muc service know that a particular entity 
is invited by an occupant of a room, to that room. Whether that entity 
is allowed into the room is a matter of room policy. So I see two 
possible exchanges:

1) * Inviter sends invitation to invitee.
    * Invitee attempts to join room, mentioning inviter's invitation.
    * Room asks confirmation with inviter that invitee was indeed invited.
    * Room decides on allowing invitee in.

2) * Inviter sends notice to room about imminent joining of invitee
    * Inviter sends invite to invitee
    * Invitee attempts to join room
    * Room decided on allowing invitee in

Exchange 1) can easily be adapted to follow the full token exchange 
dance described by OAuth. The room needs to remember the token that 
shows proof of the invite. But wait, we have built-in authentication. 
Leaving optional MITM and replay attacks out of the picture*, we can 
just have the invitee mention the JID of the inviter, and store that 
instead of a token. No OAuth needed.

* MITM and replay attacks in XMPP can happen in several places: c2s 
traffic, s2s traffic and the servers themselves. If you can assume that 
all traffic is TLS based, that severely limits the possibility of those 
attacks, leaving you to trust the two servers. In the discussions at the 
Summit, this assumption was made. Remind this for later.


The node subscription use case shows a full exchange of tokens, whereas 
I was under the impression that we got an access token out of band. Why 
do this over XMPP? If you really want to define this, and for now I 
don't see why, then make it a full implementation of the exchange, with 
the regular signature methods.

Currently the signature method in all the examples is 
PLAINTEXT+HMAC-SHA1, a new signature method invented solely for the 
out-of-band-token use case we discussed at the Summit. While the short 
summary [1] on Peter's blog mentions the way to sign, this draft does 
not explain it at all.

Basically, it says to only make a signature (using HMAC-SHA1) over the 
consumer key, consumer secret, the access token and the access token 
secret. No nonce or timestamp or additional attributes are used here 
(hence probably the mention of PLAINTEXT). I had a lengthy discussion 
about this with Marc and we are not even sure if we need this special 
method.

The assumption of MITM and replay attacks being addressed by XMPP itself 
[2] IMO only applies to direct server-to-server traffic only. In that 
case, why make a signature at all? Couldn't we just use the PLAINTEXT 
method, or even just directly send over the consumer secret and token 
secret (they are only obfuscated in PLAINTEXT). Is there any reason to 
hash them? I can only think of one reason: one service not being sure if 
the recipient can be trusted, which seems odd, because we assumed that 
to boot.

A client (like a third-party application that wants to subscribe to a 
pubsub node) cannot know if the full path to the pubsub service has TLS 
in place, and thus cannot guess if a MITM or replay attack is possible. 
In this case, you would need a signature, with nonce and timestamp. 
Signing without them gives a false sense of security, if my recollection 
of security classes serves me well. So the regular HMAC-SHA1 method 
should be used here? Maybe you actually need to sign attributes of the 
request it self, too?

I do notice that in Example 18 (Consumer presents an Access Token for 
permanent authorization), nonce and timestamp (and version) /are/ used. 
Maybe this will be explained by the promised edits by Peter.

It would be nice if somebody could explain again, why we did the new 
signature method, as I am not sure about it anymore.

Summarizing, I think that we use two things from the OAuth movement in XMPP:

   a) Presenting an access token that was acquired out-of-band to show 
authorization for a particular request.
   b) The dialogs that are shown to a User (through the web) to 
authorize a Consumer for a particular action. You can reuse them to work 
for authorization on a Consumer's JID, only, too.

Leaves me with pointing out that the actual access token in the reply 
from the Service Provider and the one used in the subsequent request is 
different in several examples.

ralphm

From makk384 at gmail.com  Thu Jul 31 09:08:24 2008
From: makk384 at gmail.com (Mark Morgan)
Date: Thu, 31 Jul 2008 15:08:24 +0100
Subject: [Social] Problem related to namespaces... ID proliferation.
In-Reply-To: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
References: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
Message-ID: <f1a2bc2c0807310708v54b9c390g25edb3eaefab07e5@mail.gmail.com>

On Thu, Jul 31, 2008 at 2:11 PM, Joe Cascio, Jr. <joec0914 at gmail.com> wrote:
> I'm bothered by the fact that most discussion seems to assume that identity
> is merely a projection of XMPP's ID mechanism. Wouldn't it be better to have
> someone's OpenID meta-data provide a discovery mechanism for any of several
> servers that they might be contacted on? Then the XMPP address/identity
> would be a lower level routing, perhaps invisible to the end user?

There are a few things which are being assumed by this thread and the
one it forked off from:

a/ there would be a method of discovering their presence on each of
the different services at any given time, so you know what one to
route to.  Possible with some that are stateful, but not such things
as email, sms, twitter (I don't think anyway, I'm not too sure how
twitter operates).

b/ if there is a way of discovering the above, the user you're trying
to contact may have a preference as to which one things should be
routed to, which would ideally need to be taken into account.

c/ conversation context would also need to be taken into account.  If
a conversation started on one medium, it normally would be best to
continue it on that same medium, even if a higher-priority 'route'
becomes available.  Not necessarily as important for private
conversations, but moreso for public ones,  else a chat may suddenly
appear on the given serivce in the middle of a conversation.

d/ invisible routing would always be preferred.  This often won't be
the case, for instance, if the highest priority route (if that could
be determined from the above) is one that's public (twitter, blog,
whatever else), you don't want to be sending them very personal
messages.  Even having an option for specifying the routing, with a
default if none given is not ideal, as it would then be up to the
sender to always take the routine into account anyway, in case it was
a 'private' message, with a potentially very embarrassing result if
that is forgotten.

Take care,
Mark.

From seth at mojodna.net  Thu Jul 31 11:00:31 2008
From: seth at mojodna.net (Seth Fitzsimmons)
Date: Thu, 31 Jul 2008 12:00:31 -0400
Subject: [Social] Problem related to namespaces... ID proliferation.
In-Reply-To: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
References: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
Message-ID: <1d7d37050807310900v30f2139bidce2cf7adf161cdc@mail.gmail.com>

Long, long ago I ran into a similar (but much on a much smaller scale)
problem.  Here's how I solved it:
If I'm using identi.ca, @susan refers to susan at identi.ca; for twitter,
susan at twitter.com.  If I'm using identi.ca and want to refer to
susan at twitter.com, I would use @susan at twitter.com (ugly with the double @'s;
in my old system, we used !'s; e.g. !susan at twitter.com! or
!susan at twitter.com:susan on twitter!).

When my note is syndicated to another system, the reference is rewritten
from the perspective of the system it's being read on, so a viewer on
twitter would see a message from "me at identi.ca" to "@susan", but a viewer on
identi.ca would see a message from "me" to "susan at twitter.com".

Using the !user[@node][:description]! variant (or something similar, perhaps
with []'s), you can define nicknames (or just infer from someone's contact
list) and rewrite them into that form automatically.

seth

On Thu, Jul 31, 2008 at 9:11 AM, Joe Cascio, Jr. <joec0914 at gmail.com> wrote:

> I'd like to hear some discussion on a related topic, which is ID
> proliferation. I would think Chris Messina might have something to say on
> the topic, being involved in the DISO project. In addition to the problem of
> having more than one person having "@susan" there is a growing problem of a
> single Susan being Susan at twitter.com, Susie at identi.ca,
> SueBlue at whatever.com, etc.
>
> I'm bothered by the fact that most discussion seems to assume that identity
> is merely a projection of XMPP's ID mechanism. Wouldn't it be better to have
> someone's OpenID meta-data provide a discovery mechanism for any of several
> servers that they might be contacted on? Then the XMPP address/identity
> would be a lower level routing, perhaps invisible to the end user?
>
> This surely doesn't solve the SMS problem, which is due to the fact that
> simply more characters are needed to create globally unique addresses, but
> I'd like to make one observation about short (domain-specific) vs. long
> (domain-independent) names.
>
> In the set of all people that I talk to, on Twitter, email, or IM, I have a
> hard time coming up with any two that have the same local short name. Yes,
> there are multiple JoeCascios out there, but I don't think any of my online
> contacts know them. Ok, so my name is fairly uncommon. What about a
> JohnSmith? How many JohnSmiths do you know? Couldn't potential conflicts be
> handled by a personal nickname? The globally unique low level id could be
> mapped to my own local short alias for that person. The default short alias
> is their own defined short name, but I could override that to let me
> distinguish messages arriving at my device.
>
> JoeC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/91f9cbb8/attachment-0001.htm 

From bob at wyman.us  Thu Jul 31 11:29:07 2008
From: bob at wyman.us (Bob Wyman)
Date: Thu, 31 Jul 2008 12:29:07 -0400
Subject: [Social] Problem related to namespaces... ID proliferation.
In-Reply-To: <1d7d37050807310900v30f2139bidce2cf7adf161cdc@mail.gmail.com>
References: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
	<1d7d37050807310900v30f2139bidce2cf7adf161cdc@mail.gmail.com>
Message-ID: <45be5cd40807310929l5cd1ef86t72459958ce62d2a2@mail.gmail.com>

On Thu, Jul 31, 2008 at 12:00 PM, Seth Fitzsimmons <seth at mojodna.net> wrote:
> a viewer on twitter would see a message
> from "me at identi.ca" to "@susan", but a
> viewer on identi.ca would see a message
> from "me" to "susan at twitter.com".

If your Tweets/Dents were being logged to an RSS file at Identi.ca, how
should things look in that file? The file is "dumb" and can't tell whether a
reader is an Identi.ca user or a Twitter user... Am I correct in assuming
that one should consider readers of the file to be "outsiders" and thus both
names would be fully expanded with no nicknames? (e.g. a message from
me at identica.ca to susan at twitter.com)

bob wyman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/87c4e1d0/attachment.htm 

From jabber.org at ralphm.ik.nu  Thu Jul 31 11:38:41 2008
From: jabber.org at ralphm.ik.nu (Ralph Meijer)
Date: Thu, 31 Jul 2008 18:38:41 +0200
Subject: [Social] Problem related to namespaces... ID proliferation.
In-Reply-To: <45be5cd40807310929l5cd1ef86t72459958ce62d2a2@mail.gmail.com>
References: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>	<1d7d37050807310900v30f2139bidce2cf7adf161cdc@mail.gmail.com>
	<45be5cd40807310929l5cd1ef86t72459958ce62d2a2@mail.gmail.com>
Message-ID: <4891EA91.6060106@ralphm.ik.nu>

Bob Wyman wrote:
> On Thu, Jul 31, 2008 at 12:00 PM, Seth Fitzsimmons <seth at mojodna.net 
> <mailto:seth at mojodna.net>> wrote:
>  > a viewer on twitter would see a message
>  > from "me at identi.ca <mailto:me at identi.ca>" to "@susan", but a
>  > viewer on identi.ca <http://identi.ca/> would see a message
>  > from "me" to "susan at twitter.com <mailto:susan at twitter.com>".
> 
> If your Tweets/Dents were being logged to an RSS file at Identi.ca, how 
> should things look in that file? The file is "dumb" and can't tell 
> whether a reader is an Identi.ca user or a Twitter user... Am I correct 
> in assuming that one should consider readers of the file to be 
> "outsiders" and thus both names would be fully expanded with no 
> nicknames? (e.g. a message from me at identica.ca <mailto:me at identica.ca> 
> to susan at twitter.com <mailto:susan at twitter.com>)

That seems good to me. Just like it is usually discouraged to use 
relative links in feeds. Also, as somebody else suggested, those nicks 
could instead be marked up, to point to a JID or web page. I wouldn't 
use e-mail addresses as in your example.

Note that I think that (Atom) feeds should use the Atom threading 
extensions to point to the post responded on, and that one might also 
use <link rel='related'/> elements in the entry to point to related 
entities.

ralphm

From romeda at gmail.com  Thu Jul 31 12:13:47 2008
From: romeda at gmail.com (Blaine Cook)
Date: Thu, 31 Jul 2008 10:13:47 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
Message-ID: <d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>

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.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 at domain is a good way to identify people
>

Agreed.

@name at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/7be62471/attachment.htm 

From appleman at gmail.com  Thu Jul 31 12:21:06 2008
From: appleman at gmail.com (Henry H)
Date: Thu, 31 Jul 2008 12:21:06 -0500
Subject: [Social] Problem related to namespaces... ID proliferation.
In-Reply-To: <4891EA91.6060106@ralphm.ik.nu>
References: <1e368400807310611i598f9246x41aabb8a744f99af@mail.gmail.com>
	<1d7d37050807310900v30f2139bidce2cf7adf161cdc@mail.gmail.com>
	<45be5cd40807310929l5cd1ef86t72459958ce62d2a2@mail.gmail.com>
	<4891EA91.6060106@ralphm.ik.nu>
Message-ID: <a60f29b10807311021k5143a1d8iab6502c0c628e98e@mail.gmail.com>

At this point, we are into visual semantics.

One could argue susan at twitter.com is better because it's a well-known
convention for email.  Others could argue that http://identi.ca/susan is
more friendly for use in RSS feeds.  Someone else could argue using a
different convention like susan/twitter.com without an @ sign is better.

Personally I don't care either way, but I'd avoid creating something
entirely new because it's an age-old problem with existing and proven
mechanisms for addressing.  Why re-create the wheel with some "new"
identification system?  The problem is simple so keep the solution simple.
At its roots this is a messaging platform just like every other messaging
platform out there (real-time, near real-time, etc.) which needs to address
messaging routing, tracking, security, privacy, etc.

The Internet is based on network layers (packets, mac addresses, IP
addresses, domain names, users within domains) - the only reason to add
another layer is for usability (because you are not providing more
functionality).  The functionality is already there and being used.  If you
want better searching, less chatty protocols, better tracking then you can
add additional layers on top of the network stack but it always comes at a
cost.  Unless you of course plan to build this messaging platform on top of
something besides the Internet (not likely for too many reasons to name).

Hey, I'd love to put an @mom on an envelope and drop it in any U.S. post
office mailbox and have that routed to my mother, but I would hate to be the
U.S. post office if that was ever implemented.  And if my mother lived
outside the U.S., I would hate the job of the person who is required to
translate mail addresses between other countries and the U.S.

The biggest challenge here is everyone has to agree on it a "standard", but
standards usually occur AFTER the fact, not before.  Adoption first,
standards second as the space matures.  Naturally something that works well
and is adopted quickly usually becomes the basis for a standard - people are
lazy.  Therefore the solution needs to be seamless or invisible and usually
based on something familar.  Make something complex and it won't be adopted
by anyone but the most tech savvy (i.e. the people on this list).  Standards
driven by simplicity naturally become the most widely adopted - it's a
self-fulling circle.

In the battle between natural standards (e.g. think evolution) versus
artificial standards (e.g. you will now use RFC 31234115 to define message
length, blah blah blah because it's needed to ensure flexibility for the one
day in the future where everyone will be hooked directly up into the Matrix)

:-)





On Thu, Jul 31, 2008 at 11:38 AM, Ralph Meijer <jabber.org at ralphm.ik.nu>wrote:

> Bob Wyman wrote:
>
>> On Thu, Jul 31, 2008 at 12:00 PM, Seth Fitzsimmons <seth at mojodna.net<mailto:
>> seth at mojodna.net>> wrote:
>>  > a viewer on twitter would see a message
>>  > from "me at identi.ca <mailto:me at identi.ca>" to "@susan", but a
>>  > viewer on identi.ca <http://identi.ca/> would see a message
>>  > from "me" to "susan at twitter.com <mailto:susan at twitter.com>".
>>
>> If your Tweets/Dents were being logged to an RSS file at Identi.ca, how
>> should things look in that file? The file is "dumb" and can't tell whether a
>> reader is an Identi.ca user or a Twitter user... Am I correct in assuming
>> that one should consider readers of the file to be "outsiders" and thus both
>> names would be fully expanded with no nicknames? (e.g. a message from
>> me at identica.ca <mailto:me at identica.ca> to susan at twitter.com <mailto:
>> susan at twitter.com>)
>>
>
> That seems good to me. Just like it is usually discouraged to use relative
> links in feeds. Also, as somebody else suggested, those nicks could instead
> be marked up, to point to a JID or web page. I wouldn't use e-mail addresses
> as in your example.
>
> Note that I think that (Atom) feeds should use the Atom threading
> extensions to point to the post responded on, and that one might also use
> <link rel='related'/> elements in the entry to point to related entities.
>
> ralphm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/761a24f9/attachment.htm 

From romeda at gmail.com  Thu Jul 31 13:15:48 2008
From: romeda at gmail.com (Blaine Cook)
Date: Thu, 31 Jul 2008 11:15:48 -0700
Subject: [Social] OAuth update
In-Reply-To: <4891C33F.3090505@ralphm.ik.nu>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
Message-ID: <d37b4b430807311115j5bcee8fl65f1d45787b504d2@mail.gmail.com>

I've been thinking about this (did the OAuth-over-XMPP implementation for
FireEagle on Tuesday), and there are a few problems with the way we
specified the OAuth interactions. Ralph's right, except that we do need
OAuth support over XMPP. The use case that I have is when a user has granted
permission to an application over OAuth, that application should be able to
perform actions over XMPP, without the user knowing which transport is being
used.
Regarding the signature semantics, the points raised are important. I think
the signature should actually be just HMAC-SHA1 as defined in the OAuth
specification, with the following modifications:

- method should be equal to the type of XMPP stanza (message, presence, or
iq)
- request url should be the "to" address concatenated (with '&') with the
"from" address.
- the normalized request parameters should be all oauth_* parameters
included in the <oauth> element (note that we are NOT trying to map from
HTTP application/x-www-form-urlencoded parameters to XMPP "parameters").

Thus, for the following stanza:

<iq to="x at example.com" from="y at example.org" id="1234">
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='mynode'/>
<oauth xmlns='urn:xmpp:tmp:oauth'>
<oauth_consumer_key>foo</oauth_consumer_key>
<oauth_token>bar</oauth_token>
<oauth_signature_method>HMAC-SHA1</oauth_signature_method>
<oauth_signature>h2vvES3WQpdYmjzUK7Fl2G1Nez8=</oauth_signature>
</oauth>
</pubsub>
</iq>

The signature base string would work out to:

iq&x%40example.com%26y%40example.org
&oauth_consumer_key%3Dfoo%40oauth_signature_method%3DHMAC-SHA1%40oauth_token%3Dbar

So assuming a consumer secret of 'consumersecret' and a token secret of '
tokensecret', the signature is going to be:

h2vvES3WQpdYmjzUK7Fl2G1Nez8=

Note that this is subject to replay attacks BUT, by including the "to" and
"from" addresses, it limits the replayability to compromised servers or c2s
connections (in which case, you have larger problems to worry about).
Ideally, OAuth subscriptions should only be sent via TLS encrypted c2s
connections, and all s2s connections should be TLS-enabled. For
security conscious individuals (i.e., the wording in the spec should be this
way), all connections MUST be over TLS.

Does this satisfy the signature requirements? It's not exactly what I
currently have implemented, but only minor changes are necessary, and I
think expresses the intent of the PLAINTEXT+HMAC-SHA1 (hiding the secret)
while addressing the fact that only encoding the secrets in the signature
meant arbitrary replay attacks.

On Thu, Jul 31, 2008 at 6:50 AM, Ralph Meijer <jabber.org at ralphm.ik.nu>wrote:

> Peter Saint-Andre wrote:
>
>> I'm making progress on updating XEP-0235 to be OAuth-specific. I'll try to
>> finish the edits tomorrow. Here's a sneak peek (thanks to Fritzy for the
>> chat earlier today):
>>
>> http://www.xmpp.org/extensions/tmp/xep-0235-0.4.html
>>
>> I have my doubts about the invitation use case, so I may remove those
>> provisionally until we figure out whether it's reasonable to use OAuth in
>> that context.
>>
>> Peter
>>
>
> Hi,
>
> I have read this draft in detail and have some doubts about its scope and
> use cases. I also discussed this with my colleague, Marc Worrell, who has
> written a full PHP implementation of OAuth (service and consumer.
>
> First off, the use case we discussed at the XMPP Summit was a Consumer
> using an OAuth access token to do a particular request over XMPP on behalf
> of a User. The assumption being that the access token would be acquired
> out-of-band (using regular, over-HTTP OAuth exchanges).
>
> I don't see any particular use base beyond that one. OAuth was designed for
> a state-less protocol with no authentication and identity built-in. In my
> opinion, for all the XMPP-only use cases that would be solved with OAuth in
> HTTP, we don't need any tokens and/or signatures.
>
> I first want to tackle the invitation use case in this draft. This example
> does not speak of a request token being acquired, although it is included in
> the access token request. Also I don't understand the mechanics of the
> consumer key here. If it belongs to the invitee, how does the inviter know
> it? Why exchange it between User and Consumer? I don't think this exchange
> actually works in practice.
>
> Taking a step back to look at the invite use-case, I notice that what is
> desired, is a way to let the muc service know that a particular entity is
> invited by an occupant of a room, to that room. Whether that entity is
> allowed into the room is a matter of room policy. So I see two possible
> exchanges:
>
> 1) * Inviter sends invitation to invitee.
>   * Invitee attempts to join room, mentioning inviter's invitation.
>   * Room asks confirmation with inviter that invitee was indeed invited.
>   * Room decides on allowing invitee in.
>
> 2) * Inviter sends notice to room about imminent joining of invitee
>   * Inviter sends invite to invitee
>   * Invitee attempts to join room
>   * Room decided on allowing invitee in
>
> Exchange 1) can easily be adapted to follow the full token exchange dance
> described by OAuth. The room needs to remember the token that shows proof of
> the invite. But wait, we have built-in authentication. Leaving optional MITM
> and replay attacks out of the picture*, we can just have the invitee mention
> the JID of the inviter, and store that instead of a token. No OAuth needed.
>
> * MITM and replay attacks in XMPP can happen in several places: c2s
> traffic, s2s traffic and the servers themselves. If you can assume that all
> traffic is TLS based, that severely limits the possibility of those attacks,
> leaving you to trust the two servers. In the discussions at the Summit, this
> assumption was made. Remind this for later.
>
>
> The node subscription use case shows a full exchange of tokens, whereas I
> was under the impression that we got an access token out of band. Why do
> this over XMPP? If you really want to define this, and for now I don't see
> why, then make it a full implementation of the exchange, with the regular
> signature methods.
>
> Currently the signature method in all the examples is PLAINTEXT+HMAC-SHA1,
> a new signature method invented solely for the out-of-band-token use case we
> discussed at the Summit. While the short summary [1] on Peter's blog
> mentions the way to sign, this draft does not explain it at all.
>
> Basically, it says to only make a signature (using HMAC-SHA1) over the
> consumer key, consumer secret, the access token and the access token secret.
> No nonce or timestamp or additional attributes are used here (hence probably
> the mention of PLAINTEXT). I had a lengthy discussion about this with Marc
> and we are not even sure if we need this special method.
>
> The assumption of MITM and replay attacks being addressed by XMPP itself
> [2] IMO only applies to direct server-to-server traffic only. In that case,
> why make a signature at all? Couldn't we just use the PLAINTEXT method, or
> even just directly send over the consumer secret and token secret (they are
> only obfuscated in PLAINTEXT). Is there any reason to hash them? I can only
> think of one reason: one service not being sure if the recipient can be
> trusted, which seems odd, because we assumed that to boot.
>
> A client (like a third-party application that wants to subscribe to a
> pubsub node) cannot know if the full path to the pubsub service has TLS in
> place, and thus cannot guess if a MITM or replay attack is possible. In this
> case, you would need a signature, with nonce and timestamp. Signing without
> them gives a false sense of security, if my recollection of security classes
> serves me well. So the regular HMAC-SHA1 method should be used here? Maybe
> you actually need to sign attributes of the request it self, too?
>
> I do notice that in Example 18 (Consumer presents an Access Token for
> permanent authorization), nonce and timestamp (and version) /are/ used.
> Maybe this will be explained by the promised edits by Peter.
>
> It would be nice if somebody could explain again, why we did the new
> signature method, as I am not sure about it anymore.
>
> Summarizing, I think that we use two things from the OAuth movement in
> XMPP:
>
>  a) Presenting an access token that was acquired out-of-band to show
> authorization for a particular request.
>  b) The dialogs that are shown to a User (through the web) to authorize a
> Consumer for a particular action. You can reuse them to work for
> authorization on a Consumer's JID, only, too.
>
> Leaves me with pointing out that the actual access token in the reply from
> the Service Provider and the one used in the subsequent request is different
> in several examples.
>
> ralphm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/4cae78ff/attachment-0001.htm 

From appleman at gmail.com  Thu Jul 31 13:32:25 2008
From: appleman at gmail.com (Henry H)
Date: Thu, 31 Jul 2008 13:32:25 -0500
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
Message-ID: <a60f29b10807311132o269d0292s7ec10b3f5a5e43f9@mail.gmail.com>

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.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.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 at domain is a good way to identify people
>>
>
> Agreed.
>
> @name at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/346274d5/attachment.htm 

From romeda at gmail.com  Thu Jul 31 13:37:13 2008
From: romeda at gmail.com (Blaine Cook)
Date: Thu, 31 Jul 2008 11:37:13 -0700
Subject: [Social] OAuth update
In-Reply-To: <4891C33F.3090505@ralphm.ik.nu>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
Message-ID: <d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>

I wanted to reply separately to Ralph's concerns about describing how to do
the "OAuth dance" over XMPP --- I don't think it's necessary, since HTTP
works well and is almost certainly the only / best way that people will do
this for some time. At some point in the future, if it becomes prudent to
describe how to obtain OAuth tokens via HTTP, we can do that. For now, it
just complicates the picture and as such should be removed.
b.

On Thu, Jul 31, 2008 at 6:50 AM, Ralph Meijer <jabber.org at ralphm.ik.nu>wrote:

> Peter Saint-Andre wrote:
>
>> I'm making progress on updating XEP-0235 to be OAuth-specific. I'll try to
>> finish the edits tomorrow. Here's a sneak peek (thanks to Fritzy for the
>> chat earlier today):
>>
>> http://www.xmpp.org/extensions/tmp/xep-0235-0.4.html
>>
>> I have my doubts about the invitation use case, so I may remove those
>> provisionally until we figure out whether it's reasonable to use OAuth in
>> that context.
>>
>> Peter
>>
>
> Hi,
>
> I have read this draft in detail and have some doubts about its scope and
> use cases. I also discussed this with my colleague, Marc Worrell, who has
> written a full PHP implementation of OAuth (service and consumer.
>
> First off, the use case we discussed at the XMPP Summit was a Consumer
> using an OAuth access token to do a particular request over XMPP on behalf
> of a User. The assumption being that the access token would be acquired
> out-of-band (using regular, over-HTTP OAuth exchanges).
>
> I don't see any particular use base beyond that one. OAuth was designed for
> a state-less protocol with no authentication and identity built-in. In my
> opinion, for all the XMPP-only use cases that would be solved with OAuth in
> HTTP, we don't need any tokens and/or signatures.
>
> I first want to tackle the invitation use case in this draft. This example
> does not speak of a request token being acquired, although it is included in
> the access token request. Also I don't understand the mechanics of the
> consumer key here. If it belongs to the invitee, how does the inviter know
> it? Why exchange it between User and Consumer? I don't think this exchange
> actually works in practice.
>
> Taking a step back to look at the invite use-case, I notice that what is
> desired, is a way to let the muc service know that a particular entity is
> invited by an occupant of a room, to that room. Whether that entity is
> allowed into the room is a matter of room policy. So I see two possible
> exchanges:
>
> 1) * Inviter sends invitation to invitee.
>   * Invitee attempts to join room, mentioning inviter's invitation.
>   * Room asks confirmation with inviter that invitee was indeed invited.
>   * Room decides on allowing invitee in.
>
> 2) * Inviter sends notice to room about imminent joining of invitee
>   * Inviter sends invite to invitee
>   * Invitee attempts to join room
>   * Room decided on allowing invitee in
>
> Exchange 1) can easily be adapted to follow the full token exchange dance
> described by OAuth. The room needs to remember the token that shows proof of
> the invite. But wait, we have built-in authentication. Leaving optional MITM
> and replay attacks out of the picture*, we can just have the invitee mention
> the JID of the inviter, and store that instead of a token. No OAuth needed.
>
> * MITM and replay attacks in XMPP can happen in several places: c2s
> traffic, s2s traffic and the servers themselves. If you can assume that all
> traffic is TLS based, that severely limits the possibility of those attacks,
> leaving you to trust the two servers. In the discussions at the Summit, this
> assumption was made. Remind this for later.
>
>
> The node subscription use case shows a full exchange of tokens, whereas I
> was under the impression that we got an access token out of band. Why do
> this over XMPP? If you really want to define this, and for now I don't see
> why, then make it a full implementation of the exchange, with the regular
> signature methods.
>
> Currently the signature method in all the examples is PLAINTEXT+HMAC-SHA1,
> a new signature method invented solely for the out-of-band-token use case we
> discussed at the Summit. While the short summary [1] on Peter's blog
> mentions the way to sign, this draft does not explain it at all.
>
> Basically, it says to only make a signature (using HMAC-SHA1) over the
> consumer key, consumer secret, the access token and the access token secret.
> No nonce or timestamp or additional attributes are used here (hence probably
> the mention of PLAINTEXT). I had a lengthy discussion about this with Marc
> and we are not even sure if we need this special method.
>
> The assumption of MITM and replay attacks being addressed by XMPP itself
> [2] IMO only applies to direct server-to-server traffic only. In that case,
> why make a signature at all? Couldn't we just use the PLAINTEXT method, or
> even just directly send over the consumer secret and token secret (they are
> only obfuscated in PLAINTEXT). Is there any reason to hash them? I can only
> think of one reason: one service not being sure if the recipient can be
> trusted, which seems odd, because we assumed that to boot.
>
> A client (like a third-party application that wants to subscribe to a
> pubsub node) cannot know if the full path to the pubsub service has TLS in
> place, and thus cannot guess if a MITM or replay attack is possible. In this
> case, you would need a signature, with nonce and timestamp. Signing without
> them gives a false sense of security, if my recollection of security classes
> serves me well. So the regular HMAC-SHA1 method should be used here? Maybe
> you actually need to sign attributes of the request it self, too?
>
> I do notice that in Example 18 (Consumer presents an Access Token for
> permanent authorization), nonce and timestamp (and version) /are/ used.
> Maybe this will be explained by the promised edits by Peter.
>
> It would be nice if somebody could explain again, why we did the new
> signature method, as I am not sure about it anymore.
>
> Summarizing, I think that we use two things from the OAuth movement in
> XMPP:
>
>  a) Presenting an access token that was acquired out-of-band to show
> authorization for a particular request.
>  b) The dialogs that are shown to a User (through the web) to authorize a
> Consumer for a particular action. You can reuse them to work for
> authorization on a Consumer's JID, only, too.
>
> Leaves me with pointing out that the actual access token in the reply from
> the Service Provider and the one used in the subsequent request is different
> in several examples.
>
> ralphm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/904f46a6/attachment.htm 

From jabber.org at ralphm.ik.nu  Thu Jul 31 13:44:31 2008
From: jabber.org at ralphm.ik.nu (Ralph Meijer)
Date: Thu, 31 Jul 2008 20:44:31 +0200
Subject: [Social] OAuth update
In-Reply-To: <d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
	<d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>
Message-ID: <4892080F.3060803@ralphm.ik.nu>

Blaine Cook wrote:
> [..] At some point in the future, if it becomes prudent to describe how to
 > obtain OAuth tokens via HTTP, we can do that. [..]

XMPP, that is.



From romeda at gmail.com  Thu Jul 31 13:55:48 2008
From: romeda at gmail.com (Blaine Cook)
Date: Thu, 31 Jul 2008 11:55:48 -0700
Subject: [Social] OAuth update
In-Reply-To: <4892080F.3060803@ralphm.ik.nu>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
	<d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>
	<4892080F.3060803@ralphm.ik.nu>
Message-ID: <d37b4b430807311155ia3b4b1bge2376180d051469f@mail.gmail.com>

Right, thanks ;-)

On Thu, Jul 31, 2008 at 11:44 AM, Ralph Meijer <jabber.org at ralphm.ik.nu>wrote:

> Blaine Cook wrote:
>
>> [..] At some point in the future, if it becomes prudent to describe how to
>>
> > obtain OAuth tokens via HTTP, we can do that. [..]
>
> XMPP, that is.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/30df1dd6/attachment.htm 

From romeda at gmail.com  Thu Jul 31 13:57:32 2008
From: romeda at gmail.com (Blaine Cook)
Date: Thu, 31 Jul 2008 11:57:32 -0700
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <a60f29b10807311132o269d0292s7ec10b3f5a5e43f9@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
	<a60f29b10807311132o269d0292s7ec10b3f5a5e43f9@mail.gmail.com>
Message-ID: <d37b4b430807311157l5c51e1dbiaf79e98397e10f78@mail.gmail.com>

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.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.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.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 at domain is a good way to identify people
>>>
>>
>> Agreed.
>>
>> @name at 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/8f34e8c7/attachment.htm 

From nathanfritz at gmail.com  Thu Jul 31 14:02:00 2008
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Thu, 31 Jul 2008 12:02:00 -0700
Subject: [Social] OAuth update
In-Reply-To: <4892080F.3060803@ralphm.ik.nu>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
	<d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>
	<4892080F.3060803@ralphm.ik.nu>
Message-ID: <182eea400807311202y4a630c1fm988622d4abc70522@mail.gmail.com>

I'm going to disagree.  We can treat the XMPP client/transport as the
consumer, and a pubsub service as the service.  We can use it to prove that
this XMPP JID is approved by an HTTP based user to have certain access over
HTTP.  We can use a specialized XMPP client (like Twhirl) as the consumer as
well as the authorizer over the two transports.  Take this example:



   1. Say you want LinkedIn to be informed LIVE whenever your Gmail contact
   list changes (additions, edits, and deletes).
   2. Gmail and LinkedIn have agreed upon a certificate and secret for
   LinkedIn.
   3. Gmail stores your contact list in an XMPP PubSub Node.
   4. You go to LinkedIn.com and inform it that you want [your-user-here]@
   gmail.com's contacts to update your LinkedIn contacts live.
   5. LinkedIn, over XMPP, requests a "request token" from Gmail's pubsub
   service, signing it with the agreed upon certificate and secret.
   6. Gmail, if the signature was valid, sends LinkedIn a "request token."
   7. LinkedIn then redirects the user to a Gmail webpage.
   8. On the Gmail Webpage, you have to log in or already be logged in.  You
   are asked whether you approve of LinkedIn having read-only access to your
   contact list with live updates.  You could optionally set a timeframe (6
   months to expire).
   9. You approve the request and Gmail redirects you back to LinkedIn.
   10. LinkedIn, over XMPP, requests an "access token," again, signing it,
   and now using the "request token" that you approved.
   11. Gmail, if the signature is correct, and the request token was
   approved, replies with an access token.
   12. LinkedIn, over XMPP, subscribes to your Publish-Subscribe Contact
   List node using the access token.
   13. From there on out (until the token expires if you set an expiration)
   gets updated every time you add/edit/delete items from your contact list in
   Gmail as they happen!

Sure, maybe there are other ways of accomplishing this, but then take the
Twhirl example:


   1. Twhirl logs into twhirl.org via XMPP SASL-Anonymous and is assigned a
   random JID.
   2. Twhirl, over XMPP, requests a request token from the identi.ca bot.
   3. Twhirl, over the identi.ca HTTP API, with the user's account, approves
   the token.  Now we have proof that this random JID is approved by the user
   to get updates.
   4. Twhirl, over XMPP, requests the access token.
   5. Twhirl sends presence to the bot with the OAuth access token via XMPP.
   6. Twhirl gets updates from the bot via XMPP until presence is
   unavailable.

This is a bit of an edge case, but in it, we use OAuth to prove that the
XMPP JID is approved by the HTTP user.  I'm perfectly willing to listen to
other STANDARDS BASED ways of solving this.

In short, the HTTP OAuth dance still has it's place in XMPP.

Thanks,
Nathan Fritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/37a32251/attachment.htm 

From dave at cridland.net  Thu Jul 31 14:06:10 2008
From: dave at cridland.net (Dave Cridland)
Date: Thu, 31 Jul 2008 20:06:10 +0100
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
Message-ID: <7078.1217531170.219484@peirce.dave.cridland.net>

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 @... at ... 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.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From nick at iss.im  Thu Jul 31 14:41:17 2008
From: nick at iss.im (Nick Vidal)
Date: Thu, 31 Jul 2008 16:41:17 -0300
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <7078.1217531170.219484@peirce.dave.cridland.net>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
	<7078.1217531170.219484@peirce.dave.cridland.net>
Message-ID: <26ff4d2a0807311241h5d6437e7kde98301900bc90d0@mail.gmail.com>

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.im

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

debbie
alias debbie at new.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.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.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 @... at ... 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.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/6ca8264a/attachment.htm 

From sociallist45098 at aquick.org  Thu Jul 31 14:50:58 2008
From: sociallist45098 at aquick.org (Adam Fields)
Date: Thu, 31 Jul 2008 15:50:58 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <7078.1217531170.219484@peirce.dave.cridland.net>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
	<7078.1217531170.219484@peirce.dave.cridland.net>
Message-ID: <20080731195057.GS26744@lola.aquick.org>

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

From lachlan at lachstock.com.au  Thu Jul 31 16:02:58 2008
From: lachlan at lachstock.com.au (Lachlan Hardy)
Date: Fri, 1 Aug 2008 07:02:58 +1000
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <d37b4b430807311157l5c51e1dbiaf79e98397e10f78@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>
	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>
	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
	<a60f29b10807311132o269d0292s7ec10b3f5a5e43f9@mail.gmail.com>
	<d37b4b430807311157l5c51e1dbiaf79e98397e10f78@mail.gmail.com>
Message-ID: <1612cc300807311402j8c51featef6f1a45c4bb658d@mail.gmail.com>

> 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

From stpeter at stpeter.im  Thu Jul 31 16:07:18 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 31 Jul 2008 15:07:18 -0600
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <1612cc300807311402j8c51featef6f1a45c4bb658d@mail.gmail.com>
References: <45be5cd40807301026i9d19843y342f6391de172de2@mail.gmail.com>	<8ca3fbe80807301156y49ba9c13q3e1a0337e63c7652@mail.gmail.com>	<45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>	<a60f29b10807311132o269d0292s7ec10b3f5a5e43f9@mail.gmail.com>	<d37b4b430807311157l5c51e1dbiaf79e98397e10f78@mail.gmail.com>
	<1612cc300807311402j8c51featef6f1a45c4bb658d@mail.gmail.com>
Message-ID: <48922986.8010102@stpeter.im>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/social/attachments/20080731/7ad0d2a4/attachment-0001.bin 

From jabber.org at ralphm.ik.nu  Thu Jul 31 16:18:40 2008
From: jabber.org at ralphm.ik.nu (Ralph Meijer)
Date: Thu, 31 Jul 2008 23:18:40 +0200
Subject: [Social] OAuth update
In-Reply-To: <182eea400807311202y4a630c1fm988622d4abc70522@mail.gmail.com>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
	<d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>
	<4892080F.3060803@ralphm.ik.nu>
	<182eea400807311202y4a630c1fm988622d4abc70522@mail.gmail.com>
Message-ID: <20080731211839.GA14478@ik.nu>

On Thu, Jul 31, 2008 at 12:02:00PM -0700, Nathan Fritz wrote:
> I'm going to disagree.  We can treat the XMPP client/transport as the consumer,
> and a pubsub service as the service.  We can use it to prove that this XMPP JID
> is approved by an HTTP based user to have certain access over HTTP.

That we can doesn't mean we should. Both your examples can easily be
implemented by doing the requests for the request token and subsequent
exhange for an access token over HTTP as the OAuth spec specifies. How
access is granted, by the way, is unspecified. The only thing we would
need to spec is how to pass the access token over XMPP, to prove that
the sending party is indeed authorized to perform the associated action.

I haven't heard of a compelling reason to do the bit up to the consumer
getting the access token over XMPP rather than HTTP. It is likely that
all of your use cases require the HTPP OAuth exhange implemented anyway,
allowing you to use existing libraries. By providing a way to present
the access token over XMPP we have enabled the use of OAuth in XMPP with
minimal effort.

If you still want that, I can transform your examples to match my
hypotheses above. But I first need some sleep.

-- 
Groetjes,

ralphm


From romeda at gmail.com  Thu Jul 31 17:07:33 2008
From: romeda at gmail.com (Blaine Cook)
Date: Thu, 31 Jul 2008 15:07:33 -0700
Subject: [Social] OAuth update
In-Reply-To: <20080731211839.GA14478@ik.nu>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
	<d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>
	<4892080F.3060803@ralphm.ik.nu>
	<182eea400807311202y4a630c1fm988622d4abc70522@mail.gmail.com>
	<20080731211839.GA14478@ik.nu>
Message-ID: <d37b4b430807311507o996a34cs43e385e1f25fe2f0@mail.gmail.com>

I really strongly agree with Ralph here --- in all cases, the use needs to
go to the Service Provider's website in order to grant permission to the
Consumer (verify the token). Since HTTP is part of the flow, why not just
use HTTP? It's well understood, libraries exist that support it, and it's
easier to guarantee security (which is really important when you're talking
about the exchange of secrets).

b.

On Thu, Jul 31, 2008 at 2:18 PM, Ralph Meijer <jabber.org at ralphm.ik.nu>wrote:

> On Thu, Jul 31, 2008 at 12:02:00PM -0700, Nathan Fritz wrote:
> > I'm going to disagree.  We can treat the XMPP client/transport as the
> consumer,
> > and a pubsub service as the service.  We can use it to prove that this
> XMPP JID
> > is approved by an HTTP based user to have certain access over HTTP.
>
> That we can doesn't mean we should. Both your examples can easily be
> implemented by doing the requests for the request token and subsequent
> exhange for an access token over HTTP as the OAuth spec specifies. How
> access is granted, by the way, is unspecified. The only thing we would
> need to spec is how to pass the access token over XMPP, to prove that
> the sending party is indeed authorized to perform the associated action.
>
> I haven't heard of a compelling reason to do the bit up to the consumer
> getting the access token over XMPP rather than HTTP. It is likely that
> all of your use cases require the HTPP OAuth exhange implemented anyway,
> allowing you to use existing libraries. By providing a way to present
> the access token over XMPP we have enabled the use of OAuth in XMPP with
> minimal effort.
>
> If you still want that, I can transform your examples to match my
> hypotheses above. But I first need some sleep.
>
> --
> Groetjes,
>
> ralphm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/56baacc4/attachment.htm 

From nathanfritz at gmail.com  Thu Jul 31 17:33:39 2008
From: nathanfritz at gmail.com (Nathan Fritz)
Date: Thu, 31 Jul 2008 15:33:39 -0700
Subject: [Social] OAuth update
In-Reply-To: <d37b4b430807311507o996a34cs43e385e1f25fe2f0@mail.gmail.com>
References: <48914726.4040903@stpeter.im> <4891C33F.3090505@ralphm.ik.nu>
	<d37b4b430807311137y4bd3a6c8gcccac143d376c74@mail.gmail.com>
	<4892080F.3060803@ralphm.ik.nu>
	<182eea400807311202y4a630c1fm988622d4abc70522@mail.gmail.com>
	<20080731211839.GA14478@ik.nu>
	<d37b4b430807311507o996a34cs43e385e1f25fe2f0@mail.gmail.com>
Message-ID: <182eea400807311533o16b71258p544a8cfcad2db0ff@mail.gmail.com>

On Thu, Jul 31, 2008 at 3:07 PM, Blaine Cook <romeda at gmail.com> wrote:

> I really strongly agree with Ralph here --- in all cases, the use needs to
> go to the Service Provider's website in order to grant permission to the
> Consumer (verify the token). Since HTTP is part of the flow, why not just
> use HTTP? It's well understood, libraries exist that support it, and it's
> easier to guarantee security (which is really important when you're talking
> about the exchange of secrets).
>
> b.
>
>
>> I haven't heard of a compelling reason to do the bit up to the consumer
>> getting the access token over XMPP rather than HTTP. It is likely that
>> all of your use cases require the HTPP OAuth exhange implemented anyway,
>> allowing you to use existing libraries. By providing a way to present
>> the access token over XMPP we have enabled the use of OAuth in XMPP with
>> minimal effort.
>>
>
But the proof that a given XMPP account is approved is less direct.  Yes,
you use the access key over XMPP, but it breaks the consumer-service
paradigm.  Perhaps my argument is weak, but shouldn't the consumer request
the keys through the protocol it is consuming on?  I am, however,
reasonable.  If there is no advantage for the requests to be made from the
same protocol as the access token is used in, then I bow out of this debate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/social/attachments/20080731/6e4463fa/attachment.htm 

From sociallist45098 at aquick.org  Thu Jul 31 19:07:00 2008
From: sociallist45098 at aquick.org (Adam Fields)
Date: Thu, 31 Jul 2008 20:07:00 -0400
Subject: [Social] "@" is evil... Namespace conflicts...
In-Reply-To: <48922986.8010102@stpeter.im>
References: <45be5cd40807301244r2277e425gfd823ce8ccc621df@mail.gmail.com>
	<56541.195.101.247.164.1217491702.squirrel@mail1.webfaction.com>
	<32ce7c09f4ac7301bcd4ae0a0bb4a34b@localhost>
	<C21640C7-2F9C-433C-B0D5-BCC7EDD71764@simplicidade.org>
	<a60f29b10807310534m6be0abbdic61de461000e51d0@mail.gmail.com>
	<d37b4b430807311013p4c2383f9u35e9396fa58f5936@mail.gmail.com>
	<a60f29b10807311132o269d0292s7ec10b3f5a5e43f9@mail.gmail.com>
	<d37b4b430807311157l5c51e1dbiaf79e98397e10f78@mail.gmail.com>
	<1612cc300807311402j8c51featef6f1a45c4bb658d@mail.gmail.com>
	<48922986.8010102@stpeter.im>
Message-ID: <20080801000700.GU26744@lola.aquick.org>

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