I am not an expert. I have been building somewhat social websites for about 4 years now. I'm a skilled web developer and I am interested in the outcomes of the projects discussed here especially considering my latest social network site.
One concern that I have about the completion of a decentralized social graph is that this complete graph could be used by corporations and government agencies to link real IDs with the social graph's IDs thus forming a friends database which could generate statistics about individuals whereby the government says that if you have X friends involved in Y activity you are at "high risk" for being involved in Y activity and appropriate action might be legally reasonable based on your risk through social exposure to Y activity.
For instance a chain nothing like Wal-Mart could link it's thefts to the graph, then identify "high risk thieves" by credit card simply through X friends on social networking sites being caught for thievery. (slightly more complicated decisions based on the data)
Another example would be your association with several drivers who have been issued traffic tickets for repetitive speeding being used by insurance agencies as evidence that your social group involves itself in speeding simply to raise your rates.
The possibilities are boundless and I am not against the idea of it's formation. Another note would be that I do not actively participate in social networking sites because of the implications of the results of identifying who you are in relation to who other people are in relation to media involving both persons.
On Aug 22, 3:27 am, Brent <thepcn...@gmail.com> wrote: ...
> One concern that I have about the completion of a decentralized social > graph is that this complete graph could be used by corporations and > government agencies to link real IDs with the social graph's IDs thus > forming a friends database which could generate statistics about > individuals whereby the government says that if you have X friends > involved in Y activity you are at "high risk" for being involved in Y > activity and appropriate action might be legally reasonable based on > your risk through social exposure to Y activity.
Here is where privacy and anonymity becomes truly important. What we need are virtual IDs in these social graphs that cannot be linked back to our "real" IDs unless we want them to. Careful management of our online presence can achieve this to a certain extent, but not completely, due to IP logging, etc.
Perhaps a "virtual ID portal" that we can use to keep separate our virtual presence from our real-world lives might be in order.
I see this as a much bigger obstacle than the tech issues (not that I know much about the tech issues). Do people really want to be graphed so thoroughly? I agree that it would be great to be able to port my networks of contacts, but the average user barely understands anything about on-line privacy. How could anyone be assured of their privacy, or the security of their identity? There are far, far too many potential "evil" uses of a decentralized social graph. Even if the technical obstacles are overcome, will the public buy the idea?
you will see that there is no need to have everyone see the foaf file. You can make sure that only authenticated users can see their foaf file. A service could also be more flexible and allow the user to see only his direct friends foaf files. Whatever. There is no need to necessarily make the foaf publically available.
In fact there could be different representations returned for a foaf id depending on the authorization of the user. A person on the public internet could get something that says
> I see this as a much bigger obstacle than the tech issues (not that I > know much about the tech issues). Do people really want to be graphed > so thoroughly? I agree that it would be great to be able to port my > networks of contacts, but the average user barely understands anything > about on-line privacy. How could anyone be assured of their privacy, > or the security of their identity? There are far, far too many > potential "evil" uses of a decentralized social graph. Even if the > technical obstacles are overcome, will the public buy the idea?
> I see this as a much bigger obstacle than the tech issues (not that I > know much about the tech issues). Do people really want to be graphed > so thoroughly? I agree that it would be great to be able to port my > networks of contacts, but the average user barely understands anything > about on-line privacy. How could anyone be assured of their privacy, > or the security of their identity? There are far, far too many > potential "evil" uses of a decentralized social graph. Even if the > technical obstacles are overcome, will the public buy the idea?
People are already providing such information to centralised social networking services. As it stands, the end user has only limited control of what the service providers do with the data. Yet Facebook seems popular...
There will no doubt be abuse of data made public, but (as with the Web) the benefits are likely to outweigh the negative aspects. We certainly have a lot of techonology available to control who sees what (I'll defer to Henry on the detail :-)
But your concerns are valid. We do need to make sure a decentralised social graph has the net effect of increasing end user's control. Such data would be a goldmine for marketeers, e.g. when recommendation engines can hop between vertical systems (as Bill de hÓra pointed out [1]). But marketeers, politicians and other such dubious types are already making assumptions about people, which may or may not be accurate. In such an environment, surely being able to actively assert information about yourself is a positive thing.
On 22/08/07, Danny Ayers <danny.ay...@gmail.com> wrote:
> People are already providing such information to centralised social > networking services. As it stands, the end user has only limited > control of what the service providers do with the data. Yet Facebook > seems popular...
Partially the illusion of privacy; because Facebook appears to be a walled garden, people think they can do stuff and get away with it. We know that tyour notes, status updates &c are actually effectively public, but most users don't.
When I pointed out to people that their status updates were public, there was a reaction of horror. A bit of me regrets it, they're a lot more dull these days...
The big problem we'll have to overcome is people buying into an illusion of privacy elsewhere that we're effectively dispelling. But that's a marketing problem, really.
> > I see this as a much bigger obstacle than the tech issues > (not that I > > know much about the tech issues). Do people really want to > be graphed > > so thoroughly? I agree that it would be great to be able to port my > > networks of contacts, but the average user barely > understands anything > > about on-line privacy. How could anyone be assured of their > privacy, > > or the security of their identity? There are far, far too many > > potential "evil" uses of a decentralized social graph. Even if the > > technical obstacles are overcome, will the public buy the idea?
> People are already providing such information to centralised > social networking services. As it stands, the end user has > only limited control of what the service providers do with > the data. Yet Facebook seems popular...
> There will no doubt be abuse of data made public, but (as with the > Web) the benefits are likely to outweigh the negative > aspects. We certainly have a lot of techonology available to > control who sees what (I'll defer to Henry on the detail :-)
> But your concerns are valid. We do need to make sure a > decentralised social graph has the net effect of increasing > end user's control. Such data would be a goldmine for > marketeers, e.g. when recommendation engines can hop between > vertical systems (as Bill de hÓra pointed out [1]). But > marketeers, politicians and other such dubious types are > already making assumptions about people, which may or may not > be accurate. In such an environment, surely being able to > actively assert information about yourself is a positive thing.
This is actually part of a much larger issue of requiring fine-grained access and access rights management for this type of data.
Users need to be able to specify not only who gets access to what data, but also what the accessor can do with that information.
I may want to restrict certain social network providers to certain social groups (perhaps defined by me, perhaps defined by membership in some other service). For example, I may want my personal/socially oriented MySpace account to know about my tribe.com membership--or even my membership in a particular tribe at tribe.com, but not have any knowledge or access to my professional relationships at LinkedIn and Ryze.
And I almost certainly want to restrict social network providers to certain uses of my data:
1. non-progation: they can't forward the data to any other services or companies
2. transience: they can query my aggregated social data in real-time, but are not allowed to store information beyond this session
3. no autonomous invitations/outreach: the social network provider is--or is not--allowed to communicate to those in my social network for the purposes of invitations or introduction of new services.
I may also require certain provisions as part of a rights agreement package:
4. reciprocity: if MySpace wants read access to my aggregated information, I may choose to make that available only if they reciprocate by exporting their social data into my aggregation service.
Or I may extend the data rights for limited purposes:
5. audit & analysis privileges: the provider can access this data post-query for up to N days for subsequent usage analysis. (Combined with service-time transience, this is a moderate in-between of the extremes of purely transient data access where service providers don't have the ability to perform post-hoc analysis of the extant data, and vendor data silos where the vendor can do whatever analysis they want for as long as they want.)
I think figuring out a set of simple, common access rights packages that provide reasonable options for both users and network providers is going to be critical to get adoption.
> I want to go to a new SN site (say facebook). In my local Address > Book [1] I decide who or which groups of people I would like to to be > part of it. Then I post a foaf file to an end point of that Social > Network using Atom Publication Protocol. It uses that to find people > on that network I know.
As you can see in a decentralized system SN sites have access to the full database. And at least in some portion any rogue server in the mesh would have access to a good portion of data. It would only take a certain amount of time to index the entire FOAF database by faking requests for friends of each FOAF just as any other server in the decentralized system would.
I think no matter how many levels of security are put on top of the decentralized network there will always be a way to link real people to any kind of ID within the system and that is where the trouble begins.
If it comes down to only letting known servers join the network, then all it takes is a fake Social Networking site to pop up just for the data, a current one offered cash for the results, or a current one hacked for the foaf graph.
ID1 knows ID2, ID3, and ID4. Numbers quickly turn into labels, and labels can quickly be used to label groups of numbers based on being friends.
On Aug 22, 12:09 pm, Henry Story <henry.st...@gmail.com> wrote:
> you will see that there is no need to have everyone see the foaf > file. You can make sure that only authenticated users can see their > foaf file. A service could also be more flexible and allow the user > to see only his direct friends foaf files. Whatever. There is no need > to necessarily make the foaf publically available.
> In fact there could be different representations returned for a foaf > id depending on the authorization of the user. A person on the public > internet could get something that says
> <> a foaf:Person.
> Someone who is part of the service could get
> <> a foaf:Person; > foaf:nick "bblfish" .
> etc...
> Henry
> On 22 Aug 2007, at 17:57, citydan wrote:
> > I see this as a much bigger obstacle than the tech issues (not that I > > know much about the tech issues). Do people really want to be graphed > > so thoroughly? I agree that it would be great to be able to port my > > networks of contacts, but the average user barely understands anything > > about on-line privacy. How could anyone be assured of their privacy, > > or the security of their identity? There are far, far too many > > potential "evil" uses of a decentralized social graph. Even if the > > technical obstacles are overcome, will the public buy the idea?
I need to catch up on the proposals in the other thread before commenting properly, but a thought just sprang to mind -
Right now we have to prove to social networking services who we are before we give them *our data* (which they might begrudgingly offer us access to it in a feed or somesuch).
Shouldn't it be those services proving to us who *they* are, that we can trust them?
On Aug 22, 2:09 pm, "Joe Andrieu" <j...@andrieu.net> wrote:
> Danny Ayers wrote (Wednesday, August 22, 2007 10:42 AM) > This is actually part of a much larger issue of requiring fine-grained > access and access rights management for this type of data.
The concepts in your proposal are sharp but the issue still stands that in a decentralized network it will be impossible to limit who sees what data for sake of data integrity over the network.
No matter what, you will be linked to your friends through one ID. Maybe transparently you will only have friends in this site that wont link up with friends in another site in a form that you have permission-based "groups" of friends, but the issue still stands that the decentralized system will need methods to maintain an accurate graph of the entire network in order to propagate changes in the graph evenly throughout the decentralization for integrity.
The idea of a social graph, in a decentralized network or a centralized network needs to be abolished in favor of a simpler method of linking friends between sites on a per-ask basis.
So all that is needed is:
1. A decentralized network of IDs(FOAFs) linked to various social networking IDs (FOAFs). No friend data in the decentralized network, let me repeat this, no friend data in the decentralized network. 2. A social network to social network protocol that, with the users permission, can transfer a user's friend's decentralized IDs(FOAFs) in Social Network A to Social Network B for purpose of identifying friends on Social Network B that were in Social Network A but unknown to Social Network B.
Brent <thepcn...@gmail.com> Wed, 22 Aug 2007 18:40:46
>The idea of a social graph, in a decentralized network or a >centralized network needs to be abolished in favor of a simpler method >of linking friends between sites on a per-ask basis.
Would anyone like to hazard a guess as to:- - How many FOAF files/URLs there are publicly available? (10m) - How many people this represents? (15m) - How many RDF triples this represents? (100m)
And then same for XFN.
-- Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173 Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433 Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat *** Just Say No To DRM ***
> permission-based "groups" of friends, but the issue still stands that > the decentralized system will need methods to maintain an accurate > graph of the entire network in order to propagate changes in the graph > evenly throughout the decentralization for integrity.
olsr open link state routing protocol does a kind of dynamic state based network dns approach.
On Aug 22, 10:54 am, "Mat Bowles" <matbow...@gmail.com> wrote:
> When I pointed out to people that their status updates were public, > there was a reaction of horror. A bit of me regrets it, they're a lot > more dull these days...
Nostalgic good old happy days can be reached here: http://www.facebook.com/privacy.php?view=profile Uncheck "Allow friends to subscribe to my status updates" (or, rather, have the friends do it).
On Aug 22, 12:34 pm, Julian Bond <julian_b...@voidstar.com> wrote:
> Brent <thepcn...@gmail.com> Wed, 22 Aug 2007 18:40:46
> >The idea of a social graph, in a decentralized network or a > >centralized network needs to be abolished in favor of a simpler method > >of linking friends between sites on a per-ask basis.
> Would anyone like to hazard a guess as to:- > - How many FOAF files/URLs there are publicly available? (10m) > - How many people this represents? (15m) > - How many RDF triples this represents? (100m)
> And then same for XFN.
And if you add 2000 'friends' from MySpace, as everyone add's tons of 'contacts' to their FOAF, the FOAF itself becomes pointless and useless. Because the information has no meaning. Who cares that you can make a super graph of ppl listing each other as 'contacts', unless you know the nature of the relationships of those contacts?
As I've mentioned before, this information is somewhat useless, the nature of the relationships is the value, and which subsets of these relationships you want to use to sign-up for new SN's. The relationship nature is currently private information, and *should* remain private.
As a developer of new websites that wants to add social features, getting such a 'dumb' linking of a ton of contacts is *useless*. I don't care that you've acquired 30,000 contacts, and 40,000 ppl have you listed across ten dozen networks. I just want the people that have relationship XXXX to you. I would even haphazard to guess you don't want to blindly dump 3,000 contacts into a new SN you join. Most people would absolutely love a way to manage all those contacts and divide them into meaningful relationships, so its easier to decide what subsets to put into new systems. And those relationship values should stay private.
Ben Bangert <gasp...@gmail.com> Wed, 22 Aug 2007 15:40:01
>I would even haphazard to guess you don't >want to blindly dump 3,000 contacts into a new SN you join.
Well I know people who do. (Robert Scoble!) I of course don't have a life and so don't have 3000 people following me. ;)
-- Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173 Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433 Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat *** Just Say No To DRM ***
On Wed, Aug 22, 2007 at 08:34:48PM +0100, Julian Bond wrote:
> Brent <thepcn...@gmail.com> Wed, 22 Aug 2007 18:40:46 > >The idea of a social graph, in a decentralized network or a > >centralized network needs to be abolished in favor of a simpler method > >of linking friends between sites on a per-ask basis.
> Would anyone like to hazard a guess as to:- > - How many FOAF files/URLs there are publicly available? (10m)
Much more than that. LiveJournal alone has 10m members, Hi5 is publishing Foaf now, which adds another 90m+ FOAFs (with 30m actives per month)
All Typepad and Vox users have FOAF too. And I'm sure there are plenty more..
> - How many people this represents? (15m)
Given dupes between services you will have less people than actual FOAF files.
Then the site would be able to test this filter against the emails it new about and then let me know of people I may potentially already know about. This way I would not be giving a networking site a huge amount of non personal info.
Henry
PS. Remember that the foaf:knows relation does not tell these groups a huge amount other than that I may have interacted with the person (if I am not lying).
> FROM: "the simple solution" thread >> I want to go to a new SN site (say facebook). In my local Address >> Book [1] I decide who or which groups of people I would like to to be >> part of it. Then I post a foaf file to an end point of that Social >> Network using Atom Publication Protocol. It uses that to find people >> on that network I know.
> As you can see in a decentralized system SN sites have access to the > full database. And at least in some portion any rogue server in the > mesh would have access to a good portion of data. It would only take a > certain amount of time to index the entire FOAF database by faking > requests for friends of each FOAF just as any other server in the > decentralized system would.
> I think no matter how many levels of security are put on top of the > decentralized network there will always be a way to link real people > to any kind of ID within the system and that is where the trouble > begins.
> If it comes down to only letting known servers join the network, then > all it takes is a fake Social Networking site to pop up just for the > data, a current one offered cash for the results, or a current one > hacked for the foaf graph.
> ID1 knows ID2, ID3, and ID4. Numbers quickly turn into labels, and > labels can quickly be used to label groups of numbers based on being > friends.
> On Aug 22, 12:09 pm, Henry Story <henry.st...@gmail.com> wrote: >> If you look at "the simple solution" thread
>> you will see that there is no need to have everyone see the foaf >> file. You can make sure that only authenticated users can see their >> foaf file. A service could also be more flexible and allow the user >> to see only his direct friends foaf files. Whatever. There is no need >> to necessarily make the foaf publically available.
>> In fact there could be different representations returned for a foaf >> id depending on the authorization of the user. A person on the public >> internet could get something that says
>> <> a foaf:Person.
>> Someone who is part of the service could get
>> <> a foaf:Person; >> foaf:nick "bblfish" .
>> etc...
>> Henry
>> On 22 Aug 2007, at 17:57, citydan wrote:
>>> I see this as a much bigger obstacle than the tech issues (not >>> that I >>> know much about the tech issues). Do people really want to be >>> graphed >>> so thoroughly? I agree that it would be great to be able to port my >>> networks of contacts, but the average user barely understands >>> anything >>> about on-line privacy. How could anyone be assured of their privacy, >>> or the security of their identity? There are far, far too many >>> potential "evil" uses of a decentralized social graph. Even if the >>> technical obstacles are overcome, will the public buy the idea?
I'm not sure I agree with the "useless" label. Technically I think you mean useless to anyone who is not the person whose network it is; i.e., useless to 3rd parties who can't extrapolate meaning. But *I,* "Mr. End User," personally don't need any extra contextual information when I view my "big graph" because *I* can understand it, *de facto*. If you can fetch me my del.icio.us , LinkedIn, MySpace, etc. and simply sort it by SN then I will be able to understand who are my work colleagues and who are my college buddies. So developers don't really need more info to get me what I want.
That said, it is possible for third parties to extrapolate some meaning about my network without me providing more data than is already available. Google does it with Gmail. They can tell which of our contacts are good ones, which email addresses are the best, etc. by virtue of our send/receive behavior. Similarly, by counting "for:" tags in my del.icio.us feed, it's possible to get an idea of who my good contacts are in that network and who is just in my network because people get link-happy and think having 20,000 friends makes them cool. My good contacts are the ones I send lots of links to and who send them to me. It looks like this<http://bp0.blogger.com/_4I3iR6s_Psk/RrvK1SLaRtI/AAAAAAAACJI/leb6yQJ4o...>. But again, I'm not arguing against your position on ownership, user-defined management, etc. Those stand on their own. I just don't think you/we should assume that the "big graph" is useless by default.
> On Aug 22, 12:34 pm, Julian Bond <julian_b...@voidstar.com> wrote: > > Brent <thepcn...@gmail.com> Wed, 22 Aug 2007 18:40:46
> > >The idea of a social graph, in a decentralized network or a > > >centralized network needs to be abolished in favor of a simpler method > > >of linking friends between sites on a per-ask basis.
> > Would anyone like to hazard a guess as to:- > > - How many FOAF files/URLs there are publicly available? (10m) > > - How many people this represents? (15m) > > - How many RDF triples this represents? (100m)
> > And then same for XFN.
> And if you add 2000 'friends' from MySpace, as everyone add's tons of > 'contacts' to their FOAF, the FOAF itself becomes pointless and > useless. Because the information has no meaning. Who cares that you > can make a super graph of ppl listing each other as 'contacts', unless > you know the nature of the relationships of those contacts?
> As I've mentioned before, this information is somewhat useless, the > nature of the relationships is the value, and which subsets of these > relationships you want to use to sign-up for new SN's. The > relationship nature is currently private information, and *should* > remain private.
> As a developer of new websites that wants to add social features, > getting such a 'dumb' linking of a ton of contacts is *useless*. I > don't care that you've acquired 30,000 contacts, and 40,000 ppl have > you listed across ten dozen networks. I just want the people that have > relationship XXXX to you. I would even haphazard to guess you don't > want to blindly dump 3,000 contacts into a new SN you join. Most > people would absolutely love a way to manage all those contacts and > divide them into meaningful relationships, so its easier to decide > what subsets to put into new systems. And those relationship values > should stay private.
kevin curry wrote (Thursday, August 23, 2007 2:14 PM )
Ben,
I'm not sure I agree with the "useless" label. Technically I think you mean useless to anyone who is not the person whose network it is; i.e., useless to 3rd parties who can't extrapolate meaning. But I, "Mr. End User," personally don't need any extra contextual information when I view my "big graph" because I can understand it, de facto. If you can fetch me my del.icio.us <http://del.icio.us/> , LinkedIn, MySpace, etc. and simply sort it by SN then I will be able to understand who are my work colleagues and who are my college buddies. So developers don't really need more info to get me what I want.
That said, it is possible for third parties to extrapolate some meaning about my network without me providing more data than is already available. Google does it with Gmail. They can tell which of our contacts are good ones, which email addresses are the best, etc. by virtue of our send/receive behavior. Similarly, by counting "for:" tags in my del.icio.us <http://del.icio.us/> feed, it's possible to get an idea of who my good contacts are in that network and who is just in my network because people get link-happy and think having 20,000 friends makes them cool. My good contacts are the ones I send lots of links to and who send them to me. It looks <http://bp0.blogger.com/_4I3iR6s_Psk/RrvK1SLaRtI/AAAAAAAACJI/leb6yQJ4o... 00-h/me_traffic_radial_faded_backgraph.bmp> like this. But again, I'm not arguing against your position on ownership, user-defined management, etc. Those stand on their own. I just don't think you/we should assume that the "big graph" is useless by default.
Kevin,
Your argument suggests that the user's view of the graph is what is important & understandable. I think that's quite a bit different from the "big graph".
Automatically aggregating (with appropriate permissions) a user's social network data for use by that individual is a fine goal. That is really just one slice through the global social graph that I understood was the initial focus of this effort.
I can see lots of reasons to aggregate across networks and build the user's slice of the graph. I can also easily imagine ways to address privacy with that context. It's the larger graph that (1) has huge privacy problems (2) few compelling use cases built for your average individual. Sure, people will disagree and I'm sure many services will set out to solve that problem. Fine, but I think it is more work than it is worth.
The main reason I'm here is because augmenting a web service based on all of a user's networked contacts without independently building a social network is appealing. But I don't need the global graph... nor would I want to mingle my customer data into it.
I didn't mean to suggest that the user's view is most important. I was only pointing out that graphs with thousands of connections are not meaningless at face value.
When we run across someone with a graph of thousands of connections we can filter down that graph based on other data, ex., sharing behavior. We can analyze those connections by asking questions: Do people in this network know each other? How many people who this person is claiming are friends actually claim this person as a friend, too? Is this a rock band? :^)
Does that make sense? Or perhaps I am misunderstanding what is being described as "useless." In any event, I reckon we are now getting beyond the portability issue. I think Fitzpatrick and Recordon are looking for a standard that is vendor agnostic, that allows us to move all or part of our network from one vendor to another, that allows us to maintain connections to people we know in SN A when we belong to SN B...or even don't belong to any SN.
Incidentally, is anyone else wondering where Fitzpatrick has been in this dicussion? Haven't heard a peep since this started.
> kevin curry wrote (Thursday, August 23, 2007 2:14 PM )
> Ben,
> I'm not sure I agree with the "useless" label. Technically I think you > mean useless to anyone who is not the person whose network it is; i.e., > useless to 3rd parties who can't extrapolate meaning. But *I,* "Mr. End > User," personally don't need any extra contextual information when I view my > "big graph" because *I* can understand it, *de facto*. If you can fetch > me my del.icio.us , LinkedIn, MySpace, etc. and simply sort it by SN then > I will be able to understand who are my work colleagues and who are my > college buddies. So developers don't really need more info to get me what I > want.
> That said, it is possible for third parties to extrapolate some meaning > about my network without me providing more data than is already available. > Google does it with Gmail. They can tell which of our contacts are good > ones, which email addresses are the best, etc. by virtue of our send/receive > behavior. Similarly, by counting "for:" tags in my del.icio.us feed, > it's possible to get an idea of who my good contacts are in that network and > who is just in my network because people get link-happy and think having > 20,000 friends makes them cool. My good contacts are the ones I send lots > of links to and who send them to me. It looks like this<http://bp0.blogger.com/_4I3iR6s_Psk/RrvK1SLaRtI/AAAAAAAACJI/leb6yQJ4o...>. > But again, I'm not arguing against your position on ownership, user-defined > management, etc. Those stand on their own. I just don't think you/we > should assume that the "big graph" is useless by default.
> Kevin,
> Your argument suggests that the user's view of the graph is what is > important & understandable. I think that's quite a bit different from the > "big graph".
> Automatically aggregating (with appropriate permissions) a user's social > network data for use by that individual is a fine goal. That is really just > one slice through the global social graph that I understood was the initial > focus of this effort.
> I can see lots of reasons to aggregate across networks and build the > user's slice of the graph. I can also easily imagine ways to address privacy > with that context. It's the larger graph that (1) has huge privacy problems > (2) few compelling use cases built for your average individual. Sure, > people will disagree and I'm sure many services will set out to solve that > problem. Fine, but I think it is more work than it is worth.
> The main reason I'm here is because augmenting a web service based on all > of a user's networked contacts without independently building a social > network is appealing. But I don't need the global graph... nor would I want > to mingle my customer data into it.
I didn't mean to suggest that the user's view is most important. I was only pointing out that graphs with thousands of connections are not meaningless at face value.
When we run across someone with a graph of thousands of connections we can filter down that graph based on other data, ex., sharing behavior. We can analyze those connections by asking questions: Do people in this network know each other? How many people who this person is claiming are friends actually claim this person as a friend, too? Is this a rock band? :^)
Kevin,
The reason I said that is because of your statement "But I, "Mr. End User," personally don't need any extra contextual information when I view my "big graph" because I can understand it, de facto." Which requires the user for the "big graph" to demonstrate the value you claim. Your following comments (quoted above) further support that filtering the graph to that subset which touches the user is how we get value out of the "big graph".
In other words, it's the contact or context through the eyes of the user which makes the graph useful at all.
Contrast this with part of the original problem statement[1]: What I mean by "social graph" is a the global mapping of everybody and how they're related.
This definition of "social graph" implies that the global mapping of everybody has some intrinsic value and that our goal is to connect all the social networks in the planet to create the one true graph. This not only creates a harder problem, it generates privacy and control problems.
What you, and others, have pointed out is that the value of the "ubiquitous" social network is in what we can provide for the user. I think that ubiquity will come /not/ from building one single big social graph, but rather aggregating every social network into separate aggregations for each user and allowing the user to /apply/ that aggregation at any service provider who has a way to provide value with it.
There is no need for any service provider or application to ever know everything in this distributed graph and no "big graph" need ever be extant except in the same way we might think of the World Wide Web as one big graph. Accessing such a graph (while respecting user control and privacy) would entail such a profusion of authentication and authorization requirements that it would be essentially impractical for overt benefit. (I'll leave Homeland Security and spammers out of the conversation for now.) This directly parallels the complexity and tractability of indexing the entire World Wide Web. When it is that distributed, nobody ever actually deals with the "big graph".
My point is that the "big graph" or "global mapping of everybody" as discussed in the problem statement is both intractable and non-useful. What I think we want is a ubiquitous social network context maintained for every user.
Creating the protocols for ubiquitous access to personal social graphs, so that any user can maintain their own graph and any service can access it, in a read/write fashion, with appropriate permissions and controls... /that/ seems both viable and incredibly valuable.
In short, I think a bit of shift in the problem statement away from the one big global mapping could actually create a lot of value in where we place our attention.
That said, I concur with your closing point. The platform-agnostic extraction of social networking data is a huge first step and should create a lot of value on its own.
[mailto:social-network-portability@googlegroups.com] On Behalf Of kevin curry Sent: Thursday, August 23, 2007 4:13 PM To: social-network-portability@googlegroups.com Subject: Re: Evil Third-Party Graph Analysis
Joe,
I didn't mean to suggest that the user's view is most important. I was only pointing out that graphs with thousands of connections are not meaningless at face value.
When we run across someone with a graph of thousands of connections we can filter down that graph based on other data, ex., sharing behavior. We can analyze those connections by asking questions: Do people in this network know each other? How many people who this person is claiming are friends actually claim this person as a friend, too? Is this a rock band? :^)
Does that make sense? Or perhaps I am misunderstanding what is being described as "useless." In any event, I reckon we are now getting beyond the portability issue. I think Fitzpatrick and Recordon are looking for a standard that is vendor agnostic, that allows us to move all or part of our network from one vendor to another, that allows us to maintain connections to people we know in SN A when we belong to SN B...or even don't belong to any SN.
Incidentally, is anyone else wondering where Fitzpatrick has been in this dicussion? Haven't heard a peep since this started.
kevin curry wrote (Thursday, August 23, 2007 2:14 PM )
Ben,
I'm not sure I agree with the "useless" label. Technically I think you mean useless to anyone who is not the person whose network it is; i.e., useless to 3rd parties who can't extrapolate meaning. But I, "Mr. End User," personally don't need any extra contextual information when I view my "big graph" because I can understand it, de facto. If you can fetch me my del.icio.us <http://del.icio.us/> , LinkedIn, MySpace, etc. and simply sort it by SN then I will be able to understand who are my work colleagues and who are my college buddies. So developers don't really need more info to get me what I want.
That said, it is possible for third parties to extrapolate some meaning about my network without me providing more data than is already available. Google does it with Gmail. They can tell which of our contacts are good ones, which email addresses are the best, etc. by virtue of our send/receive behavior. Similarly, by counting "for:" tags in my del.icio.us <http://del.icio.us/> feed, it's possible to get an idea of who my good contacts are in that network and who is just in my network because people get link-happy and think having 20,000 friends makes them cool. My good contacts are the ones I send lots of links to and who send them to me. It looks like this <http://bp0.blogger.com/_4I3iR6s_Psk/RrvK1SLaRtI/AAAAAAAACJI/leb6yQJ4o... 00-h/me_traffic_radial_faded_backgraph.bmp> . But again, I'm not arguing against your position on ownership, user-defined management, etc. Those stand on their own. I just don't think you/we should assume that the "big graph" is useless by default.
Kevin,
Your argument suggests that the user's view of the graph is what is important & understandable. I think that's quite a bit different from the "big graph".
Automatically aggregating (with appropriate permissions) a user's social network data for use by that individual is a fine goal. That is really just one slice through the global social graph that I understood was the initial focus of this effort.
I can see lots of reasons to aggregate across networks and build the user's slice of the graph. I can also easily imagine ways to address privacy with that context. It's the larger graph that (1) has huge privacy problems (2) few compelling use cases built for your average individual. Sure, people will disagree and I'm sure many services will set out to solve that problem. Fine, but I think it is more work than it is worth.
The main reason I'm here is because augmenting a web service based on all of a user's networked contacts without independently building a social network is appealing. But I don't need the global graph... nor would I want to mingle my customer data into it.
This is an excellent thread -- I'm coming in late and reading it as a whole, and I'm very happy to see evil as a featured topic.
On Aug 23, 1:49 am, Julian Bond <julian_b...@voidstar.com> wrote:
> >I would even haphazard to guess you don't > >want to blindly dump 3,000 contacts into a new SN you join.
> Well I know people who do. (Robert Scoble!) I of course don't have a > life and so don't have 3000 people following me. ;)
Do you think Scoble would really want to add all 3000 contacts from, say, MySpace into each new social network he finds? Maybe, but a lot of people wouldn't. Furthermore, I think it might be nice to be invisible in some cases; in the model where you bounce your contact list against the sites current registrars, people can find you unless you go to the effort to use, say, a different email address for each site. I think it would be useful to somehow maintain a "right of refusal" to be "outed" simply because someone else using a system knows your email address. Even if its possible to ignore an invite, one can imagine situations where a user would simply prefer not to be recognized.
JoeGermuska <joegermu...@gmail.com> Wed, 29 Aug 2007 00:56:00
>Do you think Scoble would really want to add all 3000 contacts from, >say, MySpace into each new social network he finds?
Yes.
>Maybe, but a lot >of people wouldn't. Furthermore, I think it might be nice to be >invisible in some cases; in the model where you bounce your contact >list against the sites current registrars, people can find you unless >you go to the effort to use, say, a different email address for each >site. I think it would be useful to somehow maintain a "right of >refusal" to be "outed" simply because someone else using a system >knows your email address. Even if its possible to ignore an invite, >one can imagine situations where a user would simply prefer not to be >recognized.
Yes. And here lies the difference between following and friend. I don't have a problem with appearing in lots of people's "following" list. I do have a problem with having to confirm that lots of people are my friend. And if I don't want to be seen (follow but not followed by), the new YASN should offer a privacy control to allow me to be hidden.
So I don't see this as a design problem for a graph portability, but rather one for YASN design.
-- Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173 Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433 Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat *** Just Say No To DRM ***
Yes, it seems once you get to actually syncing data around you'd want a way to say "always import these 20 people", "ask me about these 15", and "don't bother with these 400 unless I search for one".
> JoeGermuska <joegermu...@gmail.com> Wed, 29 Aug 2007 00:56:00 >> Do you think Scoble would really want to add all 3000 contacts from, >> say, MySpace into each new social network he finds?
> Yes.
>> Maybe, but a lot >> of people wouldn't. Furthermore, I think it might be nice to be >> invisible in some cases; in the model where you bounce your contact >> list against the sites current registrars, people can find you unless >> you go to the effort to use, say, a different email address for each >> site. I think it would be useful to somehow maintain a "right of >> refusal" to be "outed" simply because someone else using a system >> knows your email address. Even if its possible to ignore an invite, >> one can imagine situations where a user would simply prefer not to be >> recognized.
> Yes. And here lies the difference between following and friend. I > don't have a problem with appearing in lots of people's "following" > list. I do have a problem with having to confirm that lots of > people are my friend. And if I don't want to be seen (follow but > not followed by), the new YASN should offer a privacy control to > allow me to be hidden.
> So I don't see this as a design problem for a graph portability, > but rather one for YASN design.
> -- > Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 > 2173 > Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 > 433 > Personal WebLog: http://www.voidstar.com/ skype:julian.bond? > chat > *** Just Say No To DRM ***
|
