I'm wondering if any kind of idea or spec exists that addresses the
notion of "open friends requests" in the context of Social Networks?
Is this possibly something that you guys are thinking about with
DiSo?
The idea would be that I'm in Social Network A, and want to invite a
friend from Social Network B to be "friends" with me -- so the actual
relationship would take some coordination between the two social
network providers (A & B), in an open way. Of course, there are spam
issues to be overcome, but I'm wondering if you know of anything going
on in this space.
> I'm wondering if any kind of idea or spec exists that addresses the > notion of "open friends requests" in the context of Social Networks? > Is this possibly something that you guys are thinking about with > DiSo?
> The idea would be that I'm in Social Network A, and want to invite a > friend from Social Network B to be "friends" with me -- so the actual > relationship would take some coordination between the two social > network providers (A & B), in an open way. Of course, there are spam > issues to be overcome, but I'm wondering if you know of anything going > on in this space.
I think the first step would be to figure out what it means to have a cross-site friend relationship.
Did you have any specific ideas about what you'd expect to be able to do after adding the remote user as a friend?
I think the decentralized equivalent of a friend request would really be some sort of access control handshake. In some ways it's the OAuth model but your friend is requesting access to *your* data rather than his own, so there are actually four parties involved: you, your friend, the app that stores your data and the app that your friend will use to access your data. Ultimately you want your app to issue your friend's app a token that it can use to access your data, but how you get there is not something I think we can do with today's tech and definitely requires a lot of thought to make sure the right parties get to make the necessary decisions at the right time with the right information.
Whether after this handshake completes you list the user on your site as a friend is up to you, of course. You could even list the user as a friend without doing this handshake, because no-one can control what you publish on your site.
> I'm wondering if any kind of idea or spec exists that addresses the > notion of "open friends requests" in the context of Social Networks? > Is this possibly something that you guys are thinking about with > DiSo?
So far, most discussions have assumed asynchronous friending, with a potetial for sending "X has friended" you notifications over PEP or similar.
- -- Stephen Paul Weber, @singpolyma Please see <http://singpolyma.net> for how I prefer to be contacted. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
> > I'm wondering if any kind of idea or spec exists that addresses the > > notion of "open friends requests" in the context of Social Networks? > > Is this possibly something that you guys are thinking about with > > DiSo?
> So far, most discussions have assumed asynchronous friending, with a > potetial for sending "X has friended" you notifications over PEP or > similar.
Can you elaborate more on what you mean by the "asynchronous" part?
Also, it seems like PEP works off of a given user's existing friend list, so has much discussion taken place around how "first contact" occurs? I'm not that familiar with XMPP, but is "first contact" pretty much open to anyone you want to add to your friend list and send a message to?
> On Mon, Dec 15, 2008 at 3:27 PM, Stephen Paul Weber< > singpol...@singpolyma.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1
>>> I'm wondering if any kind of idea or spec exists that addresses the >>> notion of "open friends requests" in the context of Social Networks? >>> Is this possibly something that you guys are thinking about with >>> DiSo? >> So far, most discussions have assumed asynchronous friending, with a >> potetial for sending "X has friended" you notifications over PEP or >> similar.
> Can you elaborate more on what you mean by the "asynchronous" part?
> Also, it seems like PEP works off of a given user's existing friend list, so > has much discussion taken place around how "first contact" occurs? I'm not > that familiar with XMPP, but is "first contact" pretty much open to anyone > you want to add to your friend list and send a message to?
> Thanks!
> David
Asynchronous - not Facebook-style...
... in the sense that on Facebook, 'friending' is an ask-and-approve process that results in a bidirectional connection between two people,
whereas the 'Twitter' model of follow and follow-by is 'asynchronous'. You can follow and not be followed-by, and vice-versa.
The Twitter model is much more scalable when you don't have a central authority. And much better matches the 'real' world.
Ok, so in the async model, each person decides to "follow" their friend,
instead of actually sending them a "hey, let's be friends" message...so
there is no such thing as a spam in this model.
However, it seems like this would still have a "first contact" problem.
Even if PEP is thrown into the mix, the "source" of the PEP Event stream has
to make that stuff public, or else the person wanting to "watch" that stream
won't be able to see it. A parallel setup is very common on Facebook -- you
really can't see people's personal info, event stream, etc, until they've
authorized you to have such access (typically).
In the DiSo email thread above, the Open Micro Blogging (
http://openmicroblogging.org/) idea was proposed, but I'm not sure if that's
the same thing that I'm talking about. It looks like it's using OAuth, so
each "Social Network" would need to implement a UI for "so and so wants to
be your friend", using OAuth underneath.
All in all, I guess there are two competing issues here: 1.) How best to do
"open friend requests" and 2) how best to avoid spam when addressing the
problem of "first contact" (incidentally, how does XMPP solve this?)
I'm very interested to hear more opinions on this subject...
Thanks!
david
On Mon, Dec 15, 2008 at 5:07 PM, Terrell Russell
<terrellruss...@gmail.com>wrote:
> On 12/15/08 12:00 PM, David Fuelling wrote:
> > On Mon, Dec 15, 2008 at 3:27 PM, Stephen Paul Weber<
> > singpol...@singpolyma.net> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>> I'm wondering if any kind of idea or spec exists that addresses the
> >>> notion of "open friends requests" in the context of Social Networks?
> >>> Is this possibly something that you guys are thinking about with
> >>> DiSo?
> >> So far, most discussions have assumed asynchronous friending, with a
> >> potetial for sending "X has friended" you notifications over PEP or
> >> similar.
> > Can you elaborate more on what you mean by the "asynchronous" part?
> > Also, it seems like PEP works off of a given user's existing friend list,
> so
> > has much discussion taken place around how "first contact" occurs? I'm
> not
> > that familiar with XMPP, but is "first contact" pretty much open to
> anyone
> > you want to add to your friend list and send a message to?
> > Thanks!
> > David
> Asynchronous - not Facebook-style...
> ... in the sense that on Facebook, 'friending' is an ask-and-approve
> process that results in a bidirectional connection between two people,
> whereas the 'Twitter' model of follow and follow-by is 'asynchronous'.
> You can follow and not be followed-by, and vice-versa.
> The Twitter model is much more scalable when you don't have a central
> authority. And much better matches the 'real' world.
> However, it seems like this would still have a "first contact" problem. > Even if PEP is thrown into the mix, the "source" of the PEP Event stream has > to make that stuff public, or else the person wanting to "watch" that stream > won't be able to see it. A parallel setup is very common on Facebook -- you > really can't see people's personal info, event stream, etc, until they've > authorized you to have such access (typically).
Well, I think what you're struggling with is the conflation of this loaded term 'Friend' and what it means when it comes to the actual decision-making process of sharing and access.
The authorization 'tokens' we get/give through OAuth are only representative of the access I, as a human, am willing to give you, as a human. If I happen to issue those tokens based on your 'account' being in a list/group I call 'friends', then so be it.
The use of the word friend is overloaded and we need to be clear what it is we're talking about. In terms of 'first contact', I think it's safe to say that most people don't use the word 'friend' when they first encounter people in the real world. I think we're better served considering how to take representative action (give access) instead of sending notification (announcing friendness).
I think the entire idea of distributed 'friend requests' are kind of silly. We're actually talking about 'permission to see your stuff(s)'.
Again, I'd like to model how we actually behave as people, instead of as accounts in today's proprietary business models.
> On 12/15/08 12:22 PM, David Fuelling wrote: > > However, it seems like this would still have a "first contact" problem. > > Even if PEP is thrown into the mix, the "source" of the PEP Event stream > has > > to make that stuff public, or else the person wanting to "watch" that > stream > > won't be able to see it. A parallel setup is very common on Facebook -- > you > > really can't see people's personal info, event stream, etc, until they've > > authorized you to have such access (typically).
> Well, I think what you're struggling with is the conflation of this > loaded term 'Friend' and what it means when it comes to the actual > decision-making process of sharing and access.
> The authorization 'tokens' we get/give through OAuth are only > representative of the access I, as a human, am willing to give you, as a > human. If I happen to issue those tokens based on your 'account' being > in a list/group I call 'friends', then so be it.
> The use of the word friend is overloaded and we need to be clear what it > is we're talking about. In terms of 'first contact', I think it's safe > to say that most people don't use the word 'friend' when they first > encounter people in the real world. I think we're better served > considering how to take representative action (give access) instead of > sending notification (announcing friendness).
> I think the entire idea of distributed 'friend requests' are kind of > silly. We're actually talking about 'permission to see your stuff(s)'.
Do you mean this shouldn't be distributed? Or that the "authorization" is out of scope for something like DiSo (e.g., contact somebody via email if you want them to show you their stuff(s))?
> Again, I'd like to model how we actually behave as people, instead of as > accounts in today's proprietary business models.
Great points. Likely "friend" is the right term to model a real-world relationship, although semantically I think Facebook has created a new definition of this term. For example, you and I are not "friends" in the traditional sense of the word -- we don't hang out, talk on the phone, etc (we have no real relationship outside of this mailing list, in fact). At best, we could be called aquaintences.
However, I might decide that I really like the input you're providing me on this list, and I may decide that I want to be your "Facebook Friend", and invite you to be "Facebook Friends". Of course, if you accept such an invitation, it doesn't mean we are now "friends" in the traidional sense of the word, but it does mean that I can view your stuff.
So, if we imagine the world in 3.625 years, when Facebook and all other social networks have completely moved their platform over to something based on DiSo, then how would I contact you to let you know, "Hey, show me your stuff -- I've been reading your blog, or "listening" to you on the DiSo list")?
I suppose one answer is to just say, "If you want somebody to give you access to their 'private' stuff, contact them 'out of band', and get them to open it up". However, it would be nice if such a feature could be part of the DiSo experience. I think that's the true intent of my query.
On Mon, Dec 15, 2008 at 6:54 PM, David Fuelling <sappe...@gmail.com> wrote: > On Mon, Dec 15, 2008 at 5:41 PM, Terrell Russell <terrellruss...@gmail.com> > wrote:
>> The authorization 'tokens' we get/give through OAuth are only >> representative of the access I, as a human, am willing to give you, as a >> human. If I happen to issue those tokens based on your 'account' being >> in a list/group I call 'friends', then so be it.
I think it is even independant on whether you add somebody to a contacts list or not.
There might be a distinction between:
- I am adding people to a list of contacts and - I am giving people access
Both cases are usually coming together of course. And it very much depends on the usecase on what list you actually need.
>> The use of the word friend is overloaded and we need to be clear what it >> is we're talking about. In terms of 'first contact', I think it's safe >> to say that most people don't use the word 'friend' when they first >> encounter people in the real world. I think we're better served >> considering how to take representative action (give access) instead of >> sending notification (announcing friendness).
I guess that's right.. At some point though I would also like to manage this list of contacts, group people together e.g. into friends and then give certain groups certain access, like see my photos marked as "private". Part of this might be implementation detail, some part migth need specification in order to transmit this information from site to site.
>> I think the entire idea of distributed 'friend requests' are kind of >> silly. We're actually talking about 'permission to see your stuff(s)'.
Right, a "friend request" would be a "request for authorization". The receiving party then knows that I am interested in it's stuff and can give me some permission to do something with it (usually "view").
> Do you mean this shouldn't be distributed? Or that the "authorization" is > out of scope for something like DiSo (e.g., contact somebody via email if > you want them to show you their stuff(s))?
My personal idea about all this is:
- your social graph is located centrally, a place which you define. Like the OpenID model. - your data might be elsewhere, services might access your socialgraph (which also gives out permissions), subscribe to your profile data (also stored centrally) and take appropriate action.
In this model each user or identity (persona) would be easily identifiable via some URL. That URL might then have discovery information for e.g. sending it a "friend request" which contains the URL of the sending identity.
>> Again, I'd like to model how we actually behave as people, instead of as >> accounts in today's proprietary business models.
> Great points. Likely "friend" is the right term to model a real-world > relationship, although semantically I think Facebook has created a new > definition of this term. For example, you and I are not "friends" in the > traditional sense of the word -- we don't hang out, talk on the phone, etc > (we have no real relationship outside of this mailing list, in fact). At > best, we could be called aquaintences.
I would keep this up to the user how he defines his groups. It comes down in the end to permissions and you should be able to give those permissions to individual contacts/identities or to groups of them.
> However, I might decide that I really like the input you're providing me on > this list, and I may decide that I want to be your "Facebook Friend", and > invite you to be "Facebook Friends". Of course, if you accept such an > invitation, it doesn't mean we are now "friends" in the traidional sense of > the word, but it does mean that I can view your stuff.
> So, if we imagine the world in 3.625 years, when Facebook and all other > social networks have completely moved their platform over to something based > on DiSo, then how would I contact you to let you know, "Hey, show me your > stuff -- I've been reading your blog, or "listening" to you on the DiSo > list")?
"Hi, I am mrtopf.de, show me all your stuff!!!" ? ;)
> I suppose one answer is to just say, "If you want somebody to give you > access to their 'private' stuff, contact them 'out of band', and get them to > open it up". However, it would be nice if such a feature could be part of > the DiSo experience. I think that's the true intent of my query.
Right, so it's just an authorization request you are sending. I might get answered or not but you are still free to open things up on your side.
I guess one of the big problems of all this will be to get the user experience right though.
-- Christian Scholz Tao Takashi (Second Life name) taotaka...@gmail.com Blog/Podcast: http://mrtopf.de/blog
> On Mon, Dec 15, 2008 at 6:54 PM, David Fuelling<sappe...@gmail.com> wrote: >> On Mon, Dec 15, 2008 at 5:41 PM, Terrell Russell<terrellruss...@gmail.com> >> wrote:
>>> The use of the word friend is overloaded and we need to be clear what it >>> is we're talking about. In terms of 'first contact', I think it's safe >>> to say that most people don't use the word 'friend' when they first >>> encounter people in the real world. I think we're better served >>> considering how to take representative action (give access) instead of >>> sending notification (announcing friendness).
> I guess that's right.. At some point though I would also like to > manage this list of contacts, group people together e.g. into friends > and then give certain groups certain access, like see my photos marked > as "private". Part of this might be implementation detail, some part > migth need specification in order to transmit this information from > site to site.
I actually drew this up a little bit the other night.
I'd love for it to be a part of DiSo - but couldn't find any PHP rules engines...
The groups of contacts is completely controlled by my jabber roster...
>>> I think the entire idea of distributed 'friend requests' are kind of >>> silly. We're actually talking about 'permission to see your stuff(s)'.
> Right, a "friend request" would be a "request for authorization". The > receiving party then knows that I am interested in it's stuff and can > give me some permission to do something with it (usually "view").
>> Do you mean this shouldn't be distributed? Or that the "authorization" is >> out of scope for something like DiSo (e.g., contact somebody via email if >> you want them to show you their stuff(s))?
No, it should most definitely be distributed. I just meant the idea of asking to be a 'friend' is silly. That's for them to define.
You're just distributedly asking for permission to see stuff.
> My personal idea about all this is:
> - your social graph is located centrally, a place which you define. > Like the OpenID model. > - your data might be elsewhere, services might access your socialgraph > (which also gives out permissions), subscribe to your profile data > (also stored centrally) and take appropriate action.
Yes - Yes - See the post linked above. I'm in charge of my people, darnit. Let me be the gatekeeper.
>> So, if we imagine the world in 3.625 years, when Facebook and all other >> social networks have completely moved their platform over to something based >> on DiSo, then how would I contact you to let you know, "Hey, show me your >> stuff -- I've been reading your blog, or "listening" to you on the DiSo >> list")?
> "Hi, I am mrtopf.de, show me all your stuff!!!" ? ;)
>> I suppose one answer is to just say, "If you want somebody to give you >> access to their 'private' stuff, contact them 'out of band', and get them to >> open it up". However, it would be nice if such a feature could be part of >> the DiSo experience. I think that's the true intent of my query.
Yes, out of band is a strong answer, but I agree - we need more.
And so with that coded request, we need to be able to name the resource for which you are asking for authorization... including but not limited to... 'all your stuff!!!'.
> Right, so it's just an authorization request you are sending. I might > get answered or not but you are still free to open things up on your > side.
> I guess one of the big problems of all this will be to get the user > experience right though.
The UX is key, definitely - but so is the underlying philosophy and model. If we don't allow for granular sharing, we can't granularly share. If we do, we can always clump and lump and group and give access to the groupings, later. That's the easy part. :)
> > So far, most discussions have assumed asynchronous friending, with a > > potetial for sending "X has friended" you notifications over PEP or > > similar.
> Can you elaborate more on what you mean by the "asynchronous" part?
Ah, I have no idea how I ended up typing that. I meant "asymmetrical".
- -- Stephen Paul Weber, @singpolyma Please see <http://singpolyma.net> for how I prefer to be contacted. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
> Right, a "friend request" would be a "request for authorization". The > receiving party then knows that I am interested in it's stuff and can > give me some permission to do something with it (usually "view").
I see this developing from a protocol perspective in two ways.
(1) The protocol specifying the "Request for authorization" merely operates at a "resource" level -- there's no intelligence about what the resource is or does (maybe the resource is a URL serving an Atom feed, e.g.). The server controlling the resource can allow the owner of the resource to select which data should be put in there. So, I might stick my event stream in there for you, but only my photos for someone else. So, the message would look like, "Bob would like to be your DiSo Friend. Would you like to become friends with Bob?". After clicking "Yes", you get another message saying, "What would you like to allow Bob to see?", where you can pick your photos, event stream, etc, and those get put into the feed. In this world, the "friending" protocol doesn't really care about resource types.
or
(2) The protocol specifies a million different "resource types" that can be included in the "request for authorization". So the message would look more like, "Bob has requested to view your photos and your event stream. Would you like to grant Bob access to this?".
Personally, it seems like #1 is preferable, and simpler. Does anything like this exist? Seems like a flow similar to this occurs already with XMPP (with the "resource" being the ability to communicate), but I'm not versed well enough on XMPP to know its internals.
> Great points. Likely "friend" is the right term to model a real-world > relationship, although semantically I think Facebook has created a new > definition of this term. For example, you and I are not "friends" in the > traditional sense of the word -- we don't hang out, talk on the phone, etc > (we have no real relationship outside of this mailing list, in fact). At > best, we could be called aquaintences.
> However, I might decide that I really like the input you're providing me on > this list, and I may decide that I want to be your "Facebook Friend", and > invite you to be "Facebook Friends". Of course, if you accept such an > invitation, it doesn't mean we are now "friends" in the traidional sense of > the word, but it does mean that I can view your stuff.
> So, if we imagine the world in 3.625 years, when Facebook and all other > social networks have completely moved their platform over to something based > on DiSo, then how would I contact you to let you know, "Hey, show me your > stuff -- I've been reading your blog, or "listening" to you on the DiSo > list")?
> I suppose one answer is to just say, "If you want somebody to give you > access to their 'private' stuff, contact them 'out of band', and get them to > open it up". However, it would be nice if such a feature could be part of > the DiSo experience. I think that's the true intent of my query.
I'm very on board with this. The system doesn't even have to be tied to the OAuth process or anything that complex. Here, I'll give a use case of what this has conjured up in my mind:
1) Bob comes to my website (singpolyma.net) and is a reader of my stuff. He sees that I have some content (say, my email address, or my rougher posts) "hidden" from the public. Bob logs in, and some content becomes visible (I have some things set to display to anyone who can manage an OpenID dance), but not the content he wants to see.
2) Bob clicks a "I want to see this stuff please" button (like the Twitter "Request to see updates" button).
3) I have configured the button (likely a WP plugin in my case, that generates said button) to notify my of this request in whatever way is best for me (I could get an IM, an email, an identi.ca dm, or it could just show up as a notification in my WP dashboard, however I want) that says "Bob (bob.example.com) wants permissions to see X content on your site."
4) I decide Bob is a cool guy, and I add him to the appropriate ACL (category on my blogroll, in this case).
5) Later, when Bob again visits my site, he can see the content.
This plugin wouldn't even be that hard to write with what we have today.
- -- Stephen Paul Weber, @singpolyma Please see <http://singpolyma.net> for how I prefer to be contacted. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
>> Great points. Likely "friend" is the right term to model a real-world
>> relationship, although semantically I think Facebook has created a new
>> definition of this term. For example, you and I are not "friends" in the
>> traditional sense of the word -- we don't hang out, talk on the phone, etc
>> (we have no real relationship outside of this mailing list, in fact). At
>> best, we could be called aquaintences.
>> However, I might decide that I really like the input you're providing me on
>> this list, and I may decide that I want to be your "Facebook Friend", and
>> invite you to be "Facebook Friends". Of course, if you accept such an
>> invitation, it doesn't mean we are now "friends" in the traidional sense of
>> the word, but it does mean that I can view your stuff.
>> So, if we imagine the world in 3.625 years, when Facebook and all other
>> social networks have completely moved their platform over to something based
>> on DiSo, then how would I contact you to let you know, "Hey, show me your
>> stuff -- I've been reading your blog, or "listening" to you on the DiSo
>> list")?
>> I suppose one answer is to just say, "If you want somebody to give you
>> access to their 'private' stuff, contact them 'out of band', and get them to
>> open it up". However, it would be nice if such a feature could be part of
>> the DiSo experience. I think that's the true intent of my query.
> I'm very on board with this. The system doesn't even have to be tied to
> the OAuth process or anything that complex. Here, I'll give a use case
> of what this has conjured up in my mind:
> 1) Bob comes to my website (singpolyma.net) and is a reader of my stuff.
> He sees that I have some content (say, my email address, or my rougher
> posts) "hidden" from the public. Bob logs in, and some content becomes
> visible (I have some things set to display to anyone who can manage an
> OpenID dance), but not the content he wants to see.
> 2) Bob clicks a "I want to see this stuff please" button (like the
> Twitter "Request to see updates" button).
> 3) I have configured the button (likely a WP plugin in my case, that
> generates said button) to notify my of this request in whatever way is
> best for me (I could get an IM, an email, an identi.ca dm, or it could
> just show up as a notification in my WP dashboard, however I want) that
> says "Bob (bob.example.com) wants permissions to see X content on your
> site."
> 4) I decide Bob is a cool guy, and I add him to the appropriate ACL
> (category on my blogroll, in this case).
> 5) Later, when Bob again visits my site, he can see the content.
> This plugin wouldn't even be that hard to write with what we have today.
Right, this seems straightforward. And it would be possible to also
add service discovery via XRD so that other websites can first check
what sort of services you have to offer (at least those you can decide
to let everybody see).
It becomes more complex of course if you want a more automatic process
between parties, like some common UX with a defined interface to
request permissions. In your case you need to search a button to click
but imagine I encounter you on some different site and I want to get
your permission to see stuff you have stored on that site. Then it's
some dance between your identity provider (probably your blog), the
service which hosts your stuff (e.g. photos) and my identity provider.
So permissions are controlled on your identity provider while the
service just subscribes to them.
Maybe I have some time tonight to write down a proper use case for
such scenarios.
-- Christian
> - --
> Stephen Paul Weber, @singpolyma
> Please see <http://singpolyma.net> for how I prefer to be contacted.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> On Mon, Dec 15, 2008 at 8:05 PM, Stephen Paul Weber > <singpol...@singpolyma.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1
> >> Great points. Likely "friend" is the right term to model a real-world > >> relationship, although semantically I think Facebook has created a new > >> definition of this term. For example, you and I are not "friends" in > the > >> traditional sense of the word -- we don't hang out, talk on the phone, > etc > >> (we have no real relationship outside of this mailing list, in fact). > At > >> best, we could be called aquaintences.
> >> However, I might decide that I really like the input you're providing me > on > >> this list, and I may decide that I want to be your "Facebook Friend", > and > >> invite you to be "Facebook Friends". Of course, if you accept such an > >> invitation, it doesn't mean we are now "friends" in the traidional sense > of > >> the word, but it does mean that I can view your stuff.
> >> So, if we imagine the world in 3.625 years, when Facebook and all other > >> social networks have completely moved their platform over to something > based > >> on DiSo, then how would I contact you to let you know, "Hey, show me > your > >> stuff -- I've been reading your blog, or "listening" to you on the DiSo > >> list")?
> >> I suppose one answer is to just say, "If you want somebody to give you > >> access to their 'private' stuff, contact them 'out of band', and get > them to > >> open it up". However, it would be nice if such a feature could be part > of > >> the DiSo experience. I think that's the true intent of my query.
> > I'm very on board with this. The system doesn't even have to be tied to > > the OAuth process or anything that complex. Here, I'll give a use case > > of what this has conjured up in my mind:
> > 1) Bob comes to my website (singpolyma.net) and is a reader of my stuff. > > He sees that I have some content (say, my email address, or my rougher > > posts) "hidden" from the public. Bob logs in, and some content becomes > > visible (I have some things set to display to anyone who can manage an > > OpenID dance), but not the content he wants to see.
> > 2) Bob clicks a "I want to see this stuff please" button (like the > > Twitter "Request to see updates" button).
> > 3) I have configured the button (likely a WP plugin in my case, that > > generates said button) to notify my of this request in whatever way is > > best for me (I could get an IM, an email, an identi.ca dm, or it could > > just show up as a notification in my WP dashboard, however I want) that > > says "Bob (bob.example.com) wants permissions to see X content on your > > site."
> > 4) I decide Bob is a cool guy, and I add him to the appropriate ACL > > (category on my blogroll, in this case).
> > 5) Later, when Bob again visits my site, he can see the content.
> > This plugin wouldn't even be that hard to write with what we have today.
> Right, this seems straightforward. And it would be possible to also > add service discovery via XRD so that other websites can first check > what sort of services you have to offer (at least those you can decide > to let everybody see).
> It becomes more complex of course if you want a more automatic process > between parties, like some common UX with a defined interface to > request permissions. In your case you need to search a button to click > but imagine I encounter you on some different site and I want to get > your permission to see stuff you have stored on that site. Then it's > some dance between your identity provider (probably your blog), the > service which hosts your stuff (e.g. photos) and my identity provider. > So permissions are controlled on your identity provider while the > service just subscribes to them.
> Maybe I have some time tonight to write down a proper use case for > such scenarios.
> -- Christian
Great that this discussion is coming up now, as I've been thinking about this recently.
Basically, I was looking for some protocol that allows one website to notify another that the first has added the latter as a contact, without needing to come up with a whole new standard. If something like this is implemented in DiSo, that would be a great reason for me to be able to implement it as well.
