What happens if someone doesn't wish to be found?
It sounds like there's going to be some great tools for people to
construct their graphs, and relocate friends. But like any tool, it
can be used for evil as well as good. We all know of folk who've been
stalked or trolled by an individual, Frequently the response to having
a stalker is to abandon your user name and go join another network, or
create a new name and 'ditch' the stalker that way. Although most
people reconnect with their friends again.
Problem is: if the social graph is open and all the sites
interconnect... that's not going to be possible anymore.
Then what?
Silicon Shaman
----------------------
Any technology distinguishable from magic, isn't advanced enough !
----------------------
http://www.piratejournal.co.uk
But like any tool, it can be used for evil as well as good.
The solution to this sort of thing has *always* been to start a new
identity and make sure there was no connection between the new and old
identities.
To the extent that people have a tendency to 'reconnect' with old
acquaintances, they are already giving a sufficiently determined stalker
(or blackmailer, or creditor, or law enforcement, or ex-spouse, etc.) an
opening to track them down again.
Which is why if you're *serious* about leaving problems behind, you
*can't* 'reconnect' with anyone. Ever. Thus, the Witness-Protection
Program.
Casual 'ditching' was only ever a 'Club' solution [1]. It only works
against *in*sufficiently determined generic harassers and trolls because
they transfer their negative attention to someone else rather than
tracking you down. This doesn't actually solve the 'dealing with
harassment' problem, it just makes it someone else's problem.
Social network portability is also at least in part a response to
inadvertent or unintentional loss of online identities, so you can't fix
the failure mode (being found when you don't want to be) without
crippling the central function, or making it too unwieldy.
You're right that as a result of the proposed infrastructure, 'ditching'
an identity partially (as opposed to completely) goes away as a viable
solution. As a result, I predict that we'll simply see a return (in some
form or another) of the killfile[2], which can also now work more
robustly because of the very same relocation and reconnection functions.
Oh, look! We're re-inventing more features of Usenet[3]! ;-)
- Michael R. Bernstein
michaelbernstein.com
--
[1] http://diveintomark.org/archives/2002/10/29/club_vs_lojack_solutions
[2] http://en.wikipedia.org/wiki/Kill_file
[3] http://en.wikipedia.org/wiki/Usenet#Usenet_terms
For example, a fundamental use case would be when I, Max, who am a
member of "Social Network A" with friends "1", "2", and "3" sign up to
"Social Network B". By choosing to join this new social network, I
can additionally elect to bring my social graph into the site, thereby
allowing me to discover that friends "1" and "3" from "Social Network
A" are also members of "Social Network B". So, in regards to the
condition where a user does not wish to be found, if the above ethos
is followed, then a user can only be found where they want to be
found. Further, the user should always have the privacy to controls
to determine how and by whom they can be found on each site.
This is quite different from the use case where "Social Network B"
would have accessibility to a user's social graph without that user
giving their express consent.
The goal must always be to allow the user to control their data and
how and where it is used, and social network portability will not only
aide this task, but also lower the barrier-to-entry for new social
applications that need to leverage relational information.
That's very true, Max. let me see if I can scale it up a little. Our domain
is a world of users, and we each have a social graph, which we own. We also
have a variety of relationships with one another, with varying degrees of
trust.
> For example, a fundamental use case would be when I, Max, who
> am a member of "Social Network A" with friends "1", "2", and
> "3" sign up to "Social Network B". By choosing to join this
> new social network, I can additionally elect to bring my
> social graph into the site, thereby allowing me to discover
> that friends "1" and "3" from "Social Network A" are also
> members of "Social Network B". So, in regards to the
> condition where a user does not wish to be found, if the
> above ethos is followed, then a user can only be found where
> they want to be found. Further, the user should always have
> the privacy to controls to determine how and by whom they can
> be found on each site.
I am not convinced that "bringing my social graph into the site" is the
right paradigm, long term. I want to own my social graph, and I want be able
to use it to interrogate sites and filter them. For example, if I join a
cool group (like this one), I'd like to match the membership to my social
graph and see if any of you are buddies with anyone in my network. If I read
a comment on somebody's blog and think "s/he's smart", I want to find out
how many degrees apart we are. And I want to let people find out that kind
of information about me. BUT ... I want my privacy respected.
So if somebody finds out I'm in Julian Bond's network and asks permission to
connect, my answer could be:
1) Okay, we're now connected;
2) Okay, you can see my limited profile;
3) Maybe, show me your profile;
4) Maybe, ask Julian to make an introduction;
5) Thanks but no thanks;
6) I won't even allow you to see I'm in Julian's network.
Option 1 is the default on Ecademy, Option 3 is Facebook, and Option 4 is
LinkedIn (I think).
> This is quite different from the use case where "Social Network B"
> would have accessibility to a user's social graph without
> that user giving their express consent.
>
> The goal must always be to allow the user to control their
> data and how and where it is used, and social network
> portability will not only aide this task, but also lower the
> barrier-to-entry for new social applications that need to
> leverage relational information.
I'd like to be able to configure my privacy based on how much I trust
Julian, and whether he trusts the person who's looking for me. I should also
be able to decide how much I trust a site or an application. For example, I
trust Facebook, I trust SuperPoke, I don't trust Zombies, I don't trust
MySpace.
Gordon Rae
On Sep 12, 11:08 am, "Gordon Rae" <gor...@premiumadvice.net> wrote:
> > I think it is important to make a key distinction about one
> > of the core goals of social network portability. My
> > understanding is that the objective is not to create a social
> > graph that is accessible to any party, but instead to empower
> > the user to have ownership of their social connections and be
> > able to take that information with them.
>
> That's very true, Max. let me see if I can scale it up a little. Our domain
> is a world of users, and we each have a social graph, which we own. We also
> have a variety of relationships with one another, with varying degrees of
> trust.
Marc
Are there fundamental reasons for not considering a decentralized
design where each node has a representation of the graph? In real
life there isn't a concept of a graph holder. We each have our own
piece of the graph and stitch it together. In such a design,
everybody would own their part of the graph and federate it out (like
trade?) for others to consume. An obvious downside will be
consistency of the perceived global graph, but for large scale
systems, this is impossible anyway.
- Steve
--------------
Steve G. Bjorg
http://www.mindtouch.com
http://www.opengarden.org
> Are there fundamental reasons for not considering a decentralized
> design where each node has a representation of the graph?
None that I've heard. Jabber pretty much does this.
Decentralisation is great, but things migrate towards shared
infrastructure for all kinds of good reasons. Take IM. We're not
going to all keep our laptops on 24x7, so having buddylists and
profiles done on service-provider machines makes practical sense. But
there's a world of difference between everyone using Jabber/XMPP,
versus everyone using MSN or AIM. Decentralisation can come in
degrees. I expect we'll see hosting providers who'll offer blogging,
Web hosting, IM and will also crawl and sync a nearby fragment of the
social Web of interest to their users.
> In real
> life there isn't a concept of a graph holder. We each have our own
> piece of the graph and stitch it together. In such a design,
> everybody would own their part of the graph and federate it out (like
> trade?) for others to consume. An obvious downside will be
> consistency of the perceived global graph, but for large scale
> systems, this is impossible anyway.
Many "social network" sites have asymmetric interpersonal links, and
UI/narrative to explain why that's OK. Flickr for example says, "this
is a bit like bookmarking a person". Or Dopplr, Twitter and others. It
depends what you mean by consistent, also. If I say I know you, but
you don't choose to mention that you know me ... that's not logically
inconsistent. It might be problematic for you in other ways (privacy,
nuisance etc). There are also issues with update propagation when
dealing with relationship data that spans hosting sites. I might add
you on Flickr, but maybe it doesn't show up in a downstream site for a
couple days. Is that a terrible problem?
Dan
Well, I think the discussion we've been having has primarily been
about portability. Yes, Facebook might be "storing" my information,
but that information is me. If I go elsewhere, my friends and profile
don't change. The end goal here, I think, is to make it really easy
for me to move around from social network to social network (freedom
of choice).
I think it is important to differentiate what the "nodes" are that you
are referring to here.
If the nodes are social networking sites, then I would say yes. I
think the primary problem with this is a lack of control / privacy for
the user. If a Social Network has the ability to get all of your
data, you can't count on it to only access that which you would _like_
it to access.
If the nodes are the users, then I think that is the safest thing to
consider. The actual data shouldn't be decentralized, just the
users. For the user to truly own (and _control_) their data, they
should have a copy of their own connections/data and be given the
right to choose how and when to give it out. In order to do this,
they would need a tool that would allow them to aggregate their
content, then another tool (hopefully integrated with the first) that
allows them detailed control of how that data may be used by other
sources.
On Sep 22, 12:45 pm, "Steve G. Bjorg" <steve.bj...@gmail.com> wrote: