Open Friend Request Protocol?
sappenin
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.
Thanks!
David
Martin Atkins
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.
Stephen Paul Weber
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.
- --
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)
iD8DBQFJRndQ6oSxepE9BOsRArkkAJ49DqBzjITNiOfXfzZ5urZkytXDXgCgjp8X
v5eZrmtTRnj8ZQKrV+4UlCc=
=MudP
-----END PGP SIGNATURE-----
David Fuelling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So far, most discussions have assumed asynchronous friending, with a
> 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?
potetial for sending "X has friended" you notifications over PEP or
similar.
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
Terrell Russell
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.
Terrell
David Fuelling
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).
As I've been searching through the DiSo archives (specifically here), it seems like the "friending" problem I'm talking about, whatever it eventually comes to mean, is really a problem of "first contact" (see here), even if the twitter model of "following/followed-by" is used (see paragraph above).
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.
Also, there's a brainstorm page here: http://diso-project.org/wiki/messaging-brainstorming, but I'm not sure how it would overcome the spam problem of a completely open "friending" system.
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
Terrell Russell
> 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.
Terrell
David Fuelling
Well, I think what you're struggling with is the conflation of this
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).
loaded term 'Friend' and what it means when it comes to the actual
decision-making process of sharing and access.
I agree.
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.
Christian Scholz / Tao Takashi (SL)
On Mon, Dec 15, 2008 at 6:54 PM, David Fuelling <sapp...@gmail.com> wrote:
> On Mon, Dec 15, 2008 at 5:41 PM, Terrell Russell <terrell...@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)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T
Terrell Russell
> Hi!
>
> On Mon, Dec 15, 2008 at 6:54 PM, David Fuelling<sapp...@gmail.com> wrote:
>> On Mon, Dec 15, 2008 at 5:41 PM, Terrell Russell<terrell...@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...
http://weblog.terrellrussell.com/2008/12/all-my-hosted-stuff-with-dynamic-sharing/
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. :)
Terrell
Stephen Paul Weber
Hash: SHA1
> > 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)
iD8DBQFJRqaz6oSxepE9BOsRAhCeAJ9I76GiwUiuudepiSi23urE5YFumACfamXE
5A5i1RrbYq6eABV20T8YZ64=
=Pnu+
-----END PGP SIGNATURE-----
David Fuelling
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").
(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.
Stephen Paul Weber
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.
- --
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)
iD8DBQFJRqps6oSxepE9BOsRAi0sAKDDQq7FKKfsj3FHIZu6MMJc2DnrowCeMGdq
kXP5AgeYV0EEOCiSZ6Ut9Pw=
=ezPz
-----END PGP SIGNATURE-----
Christian Scholz / Tao Takashi (SL)
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)
>
> iD8DBQFJRqps6oSxepE9BOsRAi0sAKDDQq7FKKfsj3FHIZu6MMJc2DnrowCeMGdq
> kXP5AgeYV0EEOCiSZ6Ut9Pw=
> =ezPz
> -----END PGP SIGNATURE-----
>
> >
>
Vincent
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.
This post might be interesting, for those who haven't read it: http://evan.prodromou.name/Open_relationships
--
Vincent