Best Practices to access my Friends' Private Resources (with permission)

[sappenin]

Hey List,

I'm looking for more community input. I'm trying to work on the
problems associated with accessing protected social networking
resources in an open/Diso fashion across social-network boundaries.
For example, how could I use my Facebook account to ask a user on
Twitter for permission to view his/her private feed? (Note, this is
somewhat of a continuation of this discussion from last year:
http://groups.google.com/group/diso-project/browse_thread/thread/d1db43fb1151e2f3/fddc0936571e0b44)

More specifically--what specifications/protocols would be involved?
How does the initial invitation occur in a cross-social network
environment? How does access actually get "granted"? Rescinded?
What is granted as part of that access? How would I actually go about
accessing the protected resource?

From a pragmatic perspective, some follow-on questions would be:
should this be standardized in a single place? Or is the answer just,
"go use existing protocols"? If so, which ones? Would a best-
practices document make sense here? Is there a single "best way" to
access a person's private photos in an open-protocol fashion, for
example? What about a private micro-blog?

Currently I'm working to specify the "invitation" part of this whole
process (http://oinvite.net). But that's just one piece, and OInvite
might not even be the best way to accomplish the initial invitation.
So, I'd like to get some broader perspsective and ideas, and possibly
start a discussion surrounding private resource access (my feeling is
this is going to be a crucial piece in any open/distributed social
networking model).

Thanks for chiming in!

David

######################################
[One Way to do Private Resouce Access]
######################################

[The Protected Resource]: Beth's Private Micro-Blog Feed (or picture
stream, etc)

[The Flow]
1.) jo...@example.com sends be...@microblog.net a request to view her
protected resource (I view this as an invitation to begin
"communicating" in a more general sense). The resouce is
http://twitterplusplus.com/beth.
2.) Beth's server responds with an acceptance to John that contains
some OAuth keys.
3.) John's server accesses beth's protected feed on behalf of John.
4.) John reads the protected feed in his aggregator or directly or
however.

[This flow is pretty simplistic, but it touches lots of different
protocols]

[Stephen Paul Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Somebody claiming to be sappenin wrote:
> I'm looking for more community input. I'm trying to work on the
> problems associated with accessing protected social networking
> resources in an open/Diso fashion across social-network boundaries.
> For example, how could I use my Facebook account to ask a user on
> Twitter for permission to view his/her private feed? (Note, this is
> somewhat of a continuation of this discussion from last year:
> http://groups.google.com/group/diso-project/browse_thread/thread/d1db43fb1151e2f3/fddc0936571e0b44)

This is basically the use case that OAuth was set up to solve.

> Currently I'm working to specify the "invitation" part of this whole
> process (http://oinvite.net). But that's just one piece, and OInvite
> might not even be the best way to accomplish the initial invitation.

I IM you / email you / contact you in whatever way you prefer and say "hey,
add me to the list of people allowed to see X"

I auth to your site (or, if reading via feed/API, OAuth) and poof!

This is the sort of model I built the DiSo Permissions plugin around.

In practise, it's hard to test, because I have very little data that I care
to share on the web which I want to be private :)

- --
Stephen Paul Weber, @singpolyma
Please see <http://singpolyma.net> for how I prefer to be contacted.
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLrRXmAAoJENEcKRHOUZze0ygQANCxr/sOwWrEWE8Ew7Mvy4i0
IkAJb+n2rJMQwbXTDTP4lR+SVAZlbEQ4dSMyMxxWOZHjuJsifJfrr0ZxgyGWTxf4
NQYDvvyAZXrJpwYH3TIPBhjyiK6ENQ4dfDr5H3eXA1cgZAl3szNWMMopQF1tT3ui
sWofBhF9ScKsfgDcFbSazYk1JlwI81NXph3tMN0cU6h8G5chCGM5VeP1gXXIfWCc
60ZYWUA9bNSLkI+tXedJXEpdNyCmU8lu94UxGjDA0pbNat3OXCo8o1MxayT3aExI
b/Fr0nRaepXOCGZJwe7HsxSVVsgsr/EHp9Y1qqiFZtdIECTC4KZgtrXesAtFYJb3
5SoqPn23/2ZyOIYPrkj13xWBkkPVSiP2Ii9U7LKX02VBhstQ/IGTjtJoXidY7+Aa
Jt0npdMdF0Abm54b3B1rLWeiNt+C/U4hFn7s9Qx3+ohu9yOXIlnEcgvD+4QPqB3O
Cq/R8mkyKA/XVbKNR6hwtbUwXm8zfIkJFD1FJpphx4Q5Hea0WEd8hn8kkaeMZjik
Mf4kE2l4xZRxQlW+InyrWP5AqjRkm7tEQYq2H5HVFUXCPZXRbbPSeUKZKLKwWQpI
dYer08mVEJ9t3SOJ0hzbWMbiRHHxUP3k8RRtoP9utZ9jCHQKuKE9AappyVhmbncl
NfnjggCs2UviUGGUsgWd
=qWI5
-----END PGP SIGNATURE-----

[Chris Messina]

Stephen's right.

Basically you can do this two ways:

• whitelist certain parties and rely on authentication to grant access
• use tokens that serve as proof of "authorization"

Ultimately, technologies like Kerberos, SAML, and other technologies were developed to solve many of the issues you asked about.

OpenID and OAuth took a somewhat lighter-weight approach to the problem and provided conventions for doing these things over the web, using HTTP and HTTPS.

Those technologies provide the underpinnings of what you're looking for; for more advanced scenarios, you want to start looking into WebFinger and LRDD — but none of these things tell you exactly how to deal with federation and/or managing access or tokens. Those are policy decisions best left up to you, as the service creator.

Chris

--
You received this message because you are subscribed to the Google Groups "Diso Project" group.
To post to this group, send email to diso-p...@googlegroups.com.
To unsubscribe from this group, send email to diso-project...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/diso-project?hl=en.

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[David Fuelling]

2010/3/26 Stephen Paul Weber <singp...@singpolyma.net>

Somebody claiming to be sappenin wrote:
> I'm looking for more community input.  I'm trying to work on the
> problems associated with accessing protected social networking
> resources in an open/Diso fashion across social-network boundaries.
> For example, how could I use my Facebook account to ask a user on
> Twitter for permission to view his/her private feed?  (Note, this is
> somewhat of a continuation of this discussion from last year:
> http://groups.google.com/group/diso-project/browse_thread/thread/d1db43fb1151e2f3/fddc0936571e0b44)

This is basically the use case that OAuth was set up to solve.

Great points!  In the spirit of lively discussion, allow me to push back a bit.

OAuth works great when you control access to the 2 OAuth touch-points: your app and the service your app is accessing.  However, in my example above, there are two people controlling two different touch points, so there is an additional actor in the mix (and a slightly different access route).  To make my example work with OAuth, there needs to be a way to get "my" OAuth tokens to my "friend" so my friend can access the resource.  That's one of the problems OInvite is meant to help solve.  

Of course, to your points below, one way to do all this is via a whitelist.  But this is problematic for two other reasons:  

First, what if I don't have any contact info for you except your Twitter page saying, "push this button to request access to this private feed"? (Assume maybe we were college roommates and haven't talked for a while, but that you would likely grant me access).  I may not be able to easily contact you in any great way except, in my Twitter example, by signing up to Twitter and then clicking that button (which goes against what I'm trying to enable via this thread).

Second, if I do have your contact information (e.g., your email address), there will be issues for "regular people" (read: My mom or Grandma) who aren't savvy enough to truly know the difference between their various identifiers.  For example, my mom may email me from "m...@gmail.com", and ask me to whitelist her on my Twitter feed.  However, when she logs into Facebook using her userid "mom" and password, and then tries to access my Twitter feed, it won't work because she doesn't realize there are actually two different OpenIDs in the mix (one from Facebook and one from Gmail).

In my opinion, it would be much better to have a standardized way to exchange either the identity that I want whitelisted, or else the authorization tokens that will give me access, or both in a standard way from within whatever app I'm using (again, that's OInvite).

 

> Currently I'm working to specify the "invitation" part of this whole
> process (http://oinvite.net).  But that's just one piece, and OInvite
> might not even be the best way to accomplish the initial invitation.

I IM you / email you / contact you in whatever way you prefer and say "hey,
add me to the list of people allowed to see X"
I auth to your site (or, if reading via feed/API, OAuth) and poof!

Per my comments above, this will work, but not well in all situations.

[Stephen Paul Weber]

Your twitter page is contact info that can go on the whitelist :-)

Sent from my Android phone. Topposted :-(

On Mar 27, 2010 3:34 PM, "David Fuelling" <sapp...@gmail.com> wrote:

2010/3/26 Stephen Paul Weber <singp...@singpolyma.net>

> > Somebody claiming to be sappenin wrote: > > I'm looking for more community input.  I'm trying t...

Great points!  In the spirit of lively discussion, allow me to push back a bit.

OAuth works great when you control access to the 2 OAuth touch-points: your app and the service your app is accessing.  However, in my example above, there are two people controlling two different touch points, so there is an additional actor in the mix (and a slightly different access route).  To make my example work with OAuth, there needs to be a way to get "my" OAuth tokens to my "friend" so my friend can access the resource.  That's one of the problems OInvite is meant to help solve.  

Of course, to your points below, one way to do all this is via a whitelist.  But this is problematic for two other reasons:  

First, what if I don't have any contact info for you except your Twitter page saying, "push this button to request access to this private feed"? (Assume maybe we were college roommates and haven't talked for a while, but that you would likely grant me access).  I may not be able to easily contact you in any great way except, in my Twitter example, by signing up to Twitter and then clicking that button (which goes against what I'm trying to enable via this thread).

Second, if I do have your contact information (e.g., your email address), there will be issues for "regular people" (read: My mom or Grandma) who aren't savvy enough to truly know the difference between their various identifiers.  For example, my mom may email me from "m...@gmail.com", and ask me to whitelist her on my Twitter feed.  However, when she logs into Facebook using her userid "mom" and password, and then tries to access my Twitter feed, it won't work because she doesn't realize there are actually two different OpenIDs in the mix (one from Facebook and one from Gmail).

In my opinion, it would be much better to have a standardized way to exchange either the identity that I want whitelisted, or else the authorization tokens that will give me access, or both in a standard way from within whatever app I'm using (again, that's OInvite).

 

> > > Currently I'm working to specify the "invitation" part of this whole > > process (http://oinv...

Per my comments above, this will work, but not well in all situations.

-- You received this message because you are subscribed to the Google Groups "Diso Project" group. ...

[David Fuelling]

Not if I don't have a Twitter account.

2010/3/27 Stephen Paul Weber <singp...@singpolyma.net>

[Stephen Paul Weber]

Oh, I see... well, when you contact your friend you'll have to give him some id for you, even if the contact msg is sent as a programatic "Invite"

Sent from my Android phone. Topposted :-(

-- You received this message because you are subscribed to the Google Groups "Diso Project" group.

To post to this group, send email to diso-p...@googlegroups.com. To unsubscribe from this group, ...

[David Fuelling]

True, but this is my whole point.  If the invite was programmatic, then I could at least contact my friend from the social network I happened to be on.

[Chris Messina]

It's true that solving this problem generally is one of the necessary achievements that'll need to be in place for true, private, distributed social networking to be possible. 

However, the solution is neither obvious nor trivial -- especially if you expect that people won't need to learn anything new. 

We can start by solving the cross-networking messaging problem, but ultimately there's very little that can be done to secure the transmission of such messages (that are usable and universal).

I think Facebook is out in front of this -- in some ways by pushing for less secrecy in the network. 

Hard to say how it'll go, but it does seem like something's going to have to give to make headway. 

Sorry to not have a better solution! :1

Chris

Sent from my iPhone 2G

To post to this group, send email to diso-p...@googlegroups.com.

To unsubscribe from this group, send email to diso-project...@googlegroups.com.

[jg]

How could I use my Facebook account to ask a user on Twitter for
permission to view his/her private feed?

This question needs more details. For instance, do you want to access
the Twitter feed from within Facebook? If so, that would require a
Facebook application in which case, that application would have the
facility to request a persons Twitter feed. Which would also require
that the requestor have a Twitter account. Alas, THIS is the real
problem. Having to have a Twitter account when you already have a
Facebook account. Twitter would have to build the functionality to
treat Facebook users as Twitter users without having a Twitter
account. With current solutions, they'd probably implement OpenID and
OAuth for authorizing and granting access. But again, that involves
Twitter having to do some work which may or may not be inline with
their business goals.

What specifications/protocols would be involved?
OpenID and Oauth.

How does the initial invitation occur in a cross-social network
environment?

The requestor clicks "follow me" on the target's Twitter page. Twitter
then provides an authorization UI that allows OpenID or Facebook
Connect. The requestor signs in with Facebook Connect and Twitter
follows it's normal process.

The target would get the request and allow/disallow it. Twitter would
send a message to Facebook with the response. Facebook would have to
accept it and do something that then allows the requestor to see the
Twitter feed in Facebook.

How does access actually get "granted"?

Twitter and Facebook would have to implement an access UI for each
person to select permissions requrested/granted and integrate the data
into showing/providing the Twitter feed.

Rescinded?
Same as above.

What is granted as part of that access?

Per the OAuth spec./implementation.

How would I actually go about accessing the protected resource?

From within a Facebook UI that shows Twitter feeds.

Should this be standardized in a single place? Or is the answer just,

"go use existing protocols"? If so, which ones?

Yes. This should be standardized following the model used for email/
SMTP.

Would a best-practices document make sense here?
Yes in the form of a .org website promoting/marketing the idea.

Is there a single "best way" to access a person's private photos in an
open-protocol fashion, for example?

Is there ever a single best way for anything?

What about a private micro-blog?

This is my preference since I'm developing one (http://get6d.com) but
ultimately, I want to help create the next version of Email, so to
speak.

[jg]

I wanted to add how we've implemented this in 6d. I'm not trying to
plug the implementation. I just think it will contribute positively to
this thread.

We've built an address book just like with Email where you enter the
target's 6d url. When you click on the "follow" button, a POST request
is sent to the target's 6d site with the person's url. The target's 6d
site then displays the request in the target's address book under the
Friend Request group. The target can approve the follow request, which
his site will then send a POST request to the requestor's site with a
generated key. The requestor's site saves that key and uses it to
identify messages coming from the target's site. The relationship is
now established.

Eventually, that key will be used to encrypt and decrpyt the messages
going back and forth for further lock down.

Now that the relationship has been established, the requestor and
target can add a post to their site, choosing or not to send it to the
other via their address book, just like Email. The post shows up in
the person's posts view when their logged into their own site. Right
now, it's a copy of the data (html) that's stored in the person's
database. Images, however, are linked from the target's site so if the
image is deleted, it's no longer accessible unless it was copied by
the requestor. What I'm leaning towards now though is just sending a
notification and having the data and resources requested from the
target's site so the target can then have more control over the
access. I think that will allow for disallowing someone to view that
data or resource.

I know this doesn't answer the question about sharing data across
existing social networks. I really think the urgent question to be
answered is how to get Twitter, Facebook, Google, Yahoo!, Microsoft,
and others to implement sharing facilities within their system because
ultimately, I really believe that's what has to happen. And after
saying that, they could probably just follow the SMTP model and add an
additional "request to follow" notification via HTTP and be headed in
a GREAT direction. I'm going to go take a look at the SMTP protocol.
Perhaps we just need to extend that over HTTP?

On Mar 27, 9:52 pm, Chris Messina <chris.mess...@gmail.com> wrote:
> It's true that solving this problem generally is one of the necessary  
> achievements that'll need to be in place for true, private,  
> distributed social networking to be possible.
>
> However, the solution is neither obvious nor trivial -- especially if  
> you expect that people won't need to learn anything new.
>
> We can start by solving the cross-networking messaging problem, but  
> ultimately there's very little that can be done to secure the  
> transmission of such messages (that are usable and universal).
>
> I think Facebook is out in front of this -- in some ways by pushing  
> for less secrecy in the network.
>
> Hard to say how it'll go, but it does seem like something's going to  
> have to give to make headway.
>
> Sorry to not have a better solution! :1
>
> Chris
>
> Sent from my iPhone 2G
>

> On Mar 27, 2010, at 1:55 PM, David Fuelling <sappe...@gmail.com> wrote:
>
>
>
> > True, but this is my whole point.  If the invite was programmatic,  
> > then I could at least contact my friend from the social network I  
> > happened to be on.
>

> > 2010/3/27 Stephen Paul Weber <singpol...@singpolyma.net>

> > Oh, I see... well, when you contact your friend you'll have to give  
> > him some id for you, even if the contact msg is sent as a  
> > programatic "Invite"
>
> > Sent from my Android phone. Topposted :-(
>

> >> On Mar 27, 2010 3:39 PM, "David Fuelling" <sappe...@gmail.com> wrote:
>
> >> Not if I don't have a Twitter account.
>

> >> 2010/3/27 Stephen Paul Weber <singpol...@singpolyma.net>

[David Fuelling]

see inline...

On Sun, Mar 28, 2010 at 1:39 PM, jg <guerr...@gmail.com> wrote:

How could I use my Facebook account to ask a user on Twitter for
permission to view his/her private feed?

This question needs more details. For instance, do you want to access
the Twitter feed from within Facebook?

Yes.  How to access a private resource on Twitter (or any other social network) from Facebook (or some other social network). 

 

If so, that would require a
Facebook application in which case, that application would have the
facility to request a persons Twitter feed. Which would also require
that the requestor have a Twitter account. Alas, THIS is the real
problem. Having to have a Twitter account when you already have a
Facebook account. Twitter would have to build the functionality to
treat Facebook users as Twitter users without having a Twitter
account. With current solutions, they'd probably implement OpenID and
OAuth for authorizing and granting access. But again, that involves
Twitter having to do some work which may or may not be inline with
their business goals.

I agree with your prognosis.  Currently there's no real *standard* way for Facebook users to interact with Twitter users without also having a Twitter account (but this problem extends to all social networks).  In practice, Twitter and Facebook may never reach this level of compatibility, but the thrust of me posing these questions is to reach a future where social-networks at least have the *possibility* of direct interaction (a good parallel is email...I can email you on gmail from my yahoo account, but I don't need a gmail account to do that).  As it stands now, there are standards out there that could enable this future, but no agreed-upon way to put them all together in a standard way.

 

How does the initial invitation occur in a cross-social network

environment?

The requestor clicks "follow me" on the target's Twitter page. Twitter
then provides an authorization UI that allows OpenID or Facebook
Connect. The requestor signs in with Facebook Connect and Twitter
follows it's normal process.

This solution is very Twitter/Facebook specific.  It would be nice to have a solution that would work with *any* two social networks, assuming each network provided service hooks.  For example, there might be a Facebook clone called Basefook.  It would be great if I could use my Basefook account to see your private Flickr photos (assuming you had some good reason to share them with me) without me having to sign-up/sign-in to Flickr to finish that authorization and access.

 

The target would get the request and allow/disallow it. Twitter would
send a message to Facebook with the response. Facebook would have to
accept it and do something that then allows the requestor to see the
Twitter feed in Facebook.

Yes.

 

How does access actually get "granted"?

Twitter and Facebook would have to implement an access UI for each
person to select permissions requrested/granted and integrate the data
into showing/providing the Twitter feed.

Yes.

 

Should this be standardized in a single place? Or is the answer just,

"go use existing protocols"? If so, which ones?

Yes. This should be standardized following the model used for email/
SMTP.

I agree.

 

Would a best-practices document make sense here?

Yes in the form of a .org website promoting/marketing the idea.

I guess I sort of hoped Diso would be that ".org"....

 

Is there a single "best way" to access a person's private photos in an
open-protocol fashion, for example?

Is there ever a single best way for anything?

Well, I guess by "best way" I mean "universally agreeable" in a programmatic fashion.  For example, SMTP may not be the best way to exchange textual email messages, but everyone supports it so it's probably the best choice if you want to send email to people, at least today.

 

What about a private micro-blog?

This is my preference since I'm developing one (http://get6d.com) but
ultimately, I want to help create the next version of Email, so to
speak.

Interesting.  So did I, for a while (http://www.differencemail.org).  I'd be curious to talk more with you about the "better email" thing.  Differencemail basically had everything handled with existing specs except for the "unsolicited first contact" piece, which is originally what spawned OInvite.  I think solving the private-feed problem in an open/diso fashion could provide a very cool basis for something that could work like email, but be a lot "better" (pardon the term).

[David Fuelling]

On Sun, Mar 28, 2010 at 1:54 PM, jg <guerr...@gmail.com> wrote:

I wanted to add how we've implemented this in 6d. I'm not trying to
plug the implementation. I just think it will contribute positively to
this thread.

Great!  Thanks for sharing this info!!

 

We've built an address book just like with Email where you enter the
target's 6d url. When you click on the "follow" button, a POST request
is sent to the target's 6d site with the person's url. The target's 6d
site then displays the request in the target's address book under the
Friend Request group. The target can approve the follow request, which
his site will then send a POST request to the requestor's site with a
generated key. The requestor's site saves that key and uses it to
identify messages coming from the target's site. The relationship is
now established.

This is very close to what OInvite does.  I'm envisioning OInvite as mechanism to both initiate a relationship *and* as an exchange of OAuth keys for access to a particular resource.  In the spirit of open-protocols, it would be great to have some more involvement in OInvite to formally specify what goes on here (and I'm fully open to that *not* being OInvite and being something else -- but OInvite is a pretty good start).  

Either way, it seems like you should base whatever you build into 6d on some sort of specification so that 6d can be compatible with other social networks/communications systems in the future.

I'd love to hear your thoughts about this in particular.

 

Eventually, that key will be used to encrypt and decrpyt the messages
going back and forth for further lock down.

Now that the relationship has been established, the requestor and
target can add a post to their site, choosing or not to send it to the
other via their address book, just like Email. The post shows up in
the person's posts view when their logged into their own site. Right
now, it's a copy of the data (html) that's stored in the person's
database. Images, however, are linked from the target's site so if the
image is deleted, it's no longer accessible unless it was copied by
the requestor. What I'm leaning towards now though is just sending a
notification and having the data and resources requested from the
target's site so the target can then have more control over the
access. I think that will allow for disallowing someone to view that
data or resource.

Very Cool!  Sometimes reading your stuff I feel like we've lived a parallel life.  You writing 6d, and me trying to specify differencemail.

 

I know this doesn't answer the question about sharing data across
existing social networks. I really think the urgent question to be
answered is how to get Twitter, Facebook, Google, Yahoo!, Microsoft,
and others to implement sharing facilities within their system because
ultimately, I really believe that's what has to happen.

I think we can look at past open protocols that the "bigs" have adopted for reference.  OpenID, OAuth, XRD, etc all started as open discussions about how to solve a common problem (or create a common benefit).  It was only once these ideas gained community traction that the "bigs" began adopting them (and it didn't hurt that representatives from the "bigs" were involved in the initial drafting processes, but I digress).  

In any event, whether we're reinventing email or trying to make social-network resource access something truly open (in the way email is today) then we need to start with some protocols to specify some of these interactions.  The protocols should be restricted to server-to-server interactions, with the rest being left up to UI designers. 

 

And after
saying that, they could probably just follow the SMTP model and add an
additional "request to follow" notification via HTTP and be headed in
a GREAT direction. I'm going to go take a look at the SMTP protocol.
Perhaps we just need to extend that over HTTP?

Hmmm...I'm not sure I follow you on this one.  SMTP doesn't have any sort of "request to follow" mechanism.  It's more, "send me anything you want, and I'll do my best to try and determine whether or not my users want to see it" (i.e., spam prevention).  Some companies have tried to put a "whitelist" layer over email (I think Earthlink was one of the more famous instances), with limited success.  But still, the problem of first contact is tricky, and very much unspecified.  Spam is basically people taking advantage of the fact that it's really hard to deal with the problem of "first contact" in open communications systems (like email, for example).

I've written a fair amount on this topic here: http://softwareblog.sappenin.com/2009/06/case-for-open-friend-request-protocol.html

Basically, IMHO the Twitter "model" is pretty ideal (not saying Twitter itself, but the way Twitter does it).  You start off with a whitelist that regulates who/what can see your private resources.  Next, you allow people to click a button saying, "give me access".  In this type of system, the only place left for spam to enter into the mix is the "invitation".  Again, spam is something I'm working to mitigate as part of OInvite, too.

[jg]

I read some of the OInvite spec. While I think a common protocol is a
good idea, I don't want to create yet another spec to have to read. I
think a good approach is to define user stories first. Then see what
existing protocols have to offer to solve them. For example, XMPP
already defines a way to invite someone, while OpenID defines a way to
"identify" a person, although I don't think OpenID in it's current
state can be used to solve some of the user stories that I've been
thinking of since the implementations that I've seen require you to
login to an authority server and the target site still creates an
account for you. When I email my friend at yahoo from my gmail
account, Yahoo doesn't create an account for me just to deliver the
message.

On Mar 30, 8:59 am, David Fuelling <sappe...@gmail.com> wrote:

> I've written a fair amount on this topic here:http://softwareblog.sappenin.com/2009/06/case-for-open-friend-request...
>
> <http://softwareblog.sappenin.com/2009/06/case-for-open-friend-request...>Basically,

[Stephen Paul Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Somebody claiming to be David Fuelling wrote:
> In any event, whether we're reinventing email or trying to make
> social-network resource access something truly open (in the way email is
> today) then we need to start with some protocols to specify some of these
> interactions. The protocols should be restricted to server-to-server
> interactions, with the rest being left up to UI designers.

I'm still not sure how this is different from a message to the user (using
any of the myriad of existing communications tech) saying "please add me to
your whitelist". If you want magic, you could give some reccomendations for
extra MIME stuff / microformats in email / extra XMPP components / etc for
the different techs to have a button in the email/IM/SMS that does the
requested action. A wholly new protocol seems worse than overkill.

- --
Stephen Paul Weber, @singpolyma
Please see <http://singpolyma.net> for how I prefer to be contacted.
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLs6flAAoJENEcKRHOUZzefAwQAJgiae084/Xozl/5uTAcqr4L
necdDYFyJ+xY/OgjPIpAhScVKLSJsAvfxHGQeMBNiUOL6HZuy+xonLU1widsWcTD
w9RYFUliFefiM3NfNudZE7LPuna5SQqwDjgBFaJiujbPEWZLDNe/o7fykTH7Crwt
Dpub8QeVMN1WX7QGhOpw3NM1J5w4NlMiS7UqsdOa4zDjvJe6xrwOM630cn1erDpI
23uPyV0QZe508MIpgitO38hCAM8XIULnPhaN3M7nrIXubFgQ3mTk7jnMLokMQRvq
zforCDNRUBf+Kh7SIvTlQ+X1Zvr64S0gyXKX5VrGaYb2KLlOnRKPU9VBZaThhi3t
UT8E5S3z1nTgHuo/SMhcu5AMWicsLWO+vgkn09NNbXVLDmX9PSbw1GfvbWu08UJv
UhAo0FGI41b6lFc3sib2PdRbPlBgbmCFi198l2n6sjMs8gVCxrLYcEz/viLvxxeX
QMiwKudLlP6wBKEDVDkBOzDPRYGNkqncR/CSiH80NC3U4Km1ESuZz/ehXU6KMVDu
3eXx4PdwLIwSmGMPjzsvuJgA/GiQ9nrbtVvYbhbkeNQFdtRS9vG/JWAuYbj580lc
ooji6G1i9K8QmwkZxMcVq2S+EPMuQby4z4eh5LIc/rDsfHqrVi/JOqAESjcHr/i0
4WLuc7POk9zN4Y6JiO/M
=zS59
-----END PGP SIGNATURE-----

[David Fuelling]

I think identifying various user stories is a great idea, and would be very interested to hear some of the stories you have in mind.  It would be great to collect these stories, and some potential ways to solve them with existing (or not) protocols in a single place.  

Does DISO have a wiki that we could use?  Or maybe a google doc would be lightweight-enough for now.