Re: [Social-discuss] project ideas and use cases

[Blaine Cook]

On 17 March 2010 16:54, Hellekin O. Wolf <address@hidden> wrote:
> *** I agree with most of what you say, just wanted to highlight this
> very important point: the web is made to share/retrieve documents, not
> to interact with people.  It's a stateless protocol and however glue
> you put on top of that, it won't be able to manage the state of your
> network graph, the trust you give to people of your credentials to
> this or that service. The web isonly the (public) face of things.

I *totally* disagree with this; it's true that HTTP is a stateless
protocol, but since the invention of CGI, we've had persistent web
services that have been used for communication. There are two billion
users backing me up – the web (i.e., applications built on the web) is
the only system that's been used to manage a social graph. Email and
IRC are able to conjure transient social graphs, but in no way give
people flexibility and fluidity as to how they manage their
relationships.

> Moreover, it's not a question of "begin able to move", but a question
> of who owns the data. You should Own Your Own Words (thanks Stewart
> Brand for this one) and I should own mine. Whatever I post, wherever I
> post it, I should still have a local copy so that I can repurpose that
> data however I want. This simple observation comes from numerous
> frustrations with sites (mostly blogs) disappearing from the web, with
> their (our, your, my) comments, or simply a lost bookmark that makes
> the content invisible to (me, you, us). Put it on the cloud, or
> wherever you want, but the "Service" should be a CLIENT to *our*
> *individual* database, not the other way around (sorry google).

There's a subtle point that I think is really important here – While I
agree that individuals should *be able to* own their own data, in
practice it is of extreme importance that they don't have to.
Middlemen are great, sometimes. If the structure is designed in such a
way that allows individuals to be their own middlemen (as TCP, SMTP,
HTTP, the postal service, and so on have been structured), then both
Google's and GNU's goals are satisfied.

If the service is structured such that users must maintain their own
software, we've already lost. What you're describing necessitates some
kind of true P2P network, which means that without some pretty extreme
contortions (c.f., Internet Mail 2000 over P2P) when a user drops of
the internet, so does their identity. The asynchronous nature of
social networks builds upon the success of email and the widespread
use of offline bots / screen for IRC. Ignore that history at your
peril.

> So, the infamous "export data" button should not only be mandatory,
> but built-in the protocol itself.

Agreed! There is more than one way to envision such a future, though.
The way that will be successful is one that takes into account how
things are already done out in the wild. Take Crabgrass, for example –
it was built, as Elijah suggets, to emulate the [massively successful]
Facebook approach to social networking. Re-imagining such a platform
as a P2P network would likely be an incredible hurdle. Approaching the
problem instead as one of simple bridging between already installed
networks means that not only Crabgrass, but networks like FourSquare,
Twitter, Flickr, and Facebook itself, to name but a few, could easily
integrate with each-other where integration makes sense.

The future that I envision is exactly like email; if you want to run
your own server, go ahead and do so – the data is yours, and no-one
can ever take it away from you. If, however, you're happy with someone
else running a server for you, even if it's one where millions of
other users are hosted, that's your choice. Networks should compete on
features and usability, not protocols.

b.