Intro, OpenSocial as an interface to Distributed Social Networks

[Christopher St John]

Howdy. Wanted to give a quick intro and share a an
experiment I'm working on.

My name is Christopher St. John, and my specific interest
in DiSo came out of some concerns that developed while
playing around hooking up a destination site to various
social networks. The technology to do that is
straightforward, but the fact that users don't own (or
even truly control) their own data means that a lot of
cool stuff is impossible in practice.

Over the next week or so (hopefully in time for
the Semantic Web Austin mixer on the 17th) I'm hoping
to get a prototype running of the Shindig OpenSocial
wrapper running with a backend of "the web", specifically
the kind of semantic data that DiSo is targeting. (note
the "prototype" qualifier: the victory conditions are
quite modest :-) )

The first big task (in addition to some tedious but fairly
easy coding) is to identify the specific backend formats
to target. This is tricky. The considerations include:

- what's best
- what's common
- what networks are most complete

I don't suppose there's the equivalent of an OpenSocial
sandbox for DiSo, is there? (Searching the archives,
browsing the Wiki and generally just googling around
didn't reveal any obvious candidates, but I could easily
have missed something) I suspect I may have to build
my own (or start pressuring some friends to add stuff
to their blogs :-) ) but I thought I'd ask.

If it's of interest, I'll post the occasional update as
things progress,

-cks

--
Christopher St. John
http://artofsystems.blogspot.com

[Chris Messina]

Hi Christopher,

Welcome to the list -- happy to have you! ;)

As for your question, no, there's really no sandbox yet per se, though Stephen Weber is running a lot of the plugins on his blog:

http://singpolyma.net

As for backend data formats... I'm not quite sure what you mean by "backend" but we're using a combination of ATOM, microformats, a new portable contacts schema based on vcard that will be out soon, and eventually (note hand-waving) XMPP. We're also relying heavily on XRDS-Simple to advertise and discover services and OAuth to provide token authorization access to protected resources.

Our model is rather different than OpenSocial as I understand it, as we're trying to architect this in such a way that anyone can host their own friends list (for example) and not necessarily defer to Google, MySpace, etc... for starters. 

I don't know if you've seen any of my presentations, but you can check them out to get a sense for the conceptual component building blocks of DiSo:

http://www.slideshare.net/factoryjoe/tags/diso

Let me know what you think and if we can better answer your question. I'm personally very interested in the overlap between DiSo and fbConnect and OpenSocial, so if we can do anything to improve integration points, let us know!

Chris

--
Chris Messina
Citizen-Participant &
Open Source Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is: [ ] bloggable [X] ask first [ ] private

[Stephen Paul Weber]

> a new portable contacts
> schema based on vcard that will be out soon

I've been increasingly disturbed by the mentions of this I see
cropping up. I snooped around and found the SVN today. I can't know
exactly what is going on (transparent communities, anyone?) but I get
the feeling that it may be inventing unnecessary extras. Especially
this "based on vcard"... what's wrong with VCARD/hcard proper?

--
- Stephen Paul Weber (Singpolyma)

code pwns specs

[Chris Messina]

Sorry for the mystery Stephen. Joseph Smarr mentioned it at Google I/O and we've been waiting on getting a proper spec together before really putting anything out there. The temporary site is up at:

http://portablecontacts.net/

We're not sure if that's even what we want to call it yet, but that and Joseph's slides are the only other mentions of this project (look for PPT link):

http://josephsmarr.com/2008/05/30/opensocial-openid-and-oauth-oh-my-google-io/

Eran has been charged with writing up the first go at the spec, but we've all been really busy lately and things have slid a bit.

To your point regarding vcard/hcard, here are the current problems:

1. it's highly unlikely that we'll get the big providers (i.e. Friend Connect/fbConnect) to support hcard/vcard. 

2. vcard works for basic profile data, but not for the kind of data that the Facebook and OpenSocial platforms store and want to provide; therefore, we can start with vcard but we need some additional fields, many of which have come from the Social Graph API or XFN (see my post on this issue: http://factoryjoe.com/blog/2008/06/04/inventing-contact-schemas-for-fun-and-profit-ugh/)

3. hcard/vcard doesn't provide a convenient, developer-friendly way of doing two-way sync.

4. it would be useful to provide a lighter-weight approach/more API-like protocol than using fatter HTML pages, although embedding contact data in web pages is still valuable and something that should continue to be promoted; it's simply not the way to pass around hundreds of contacts at run-time for thousands or millions of users.

5. we need something that replaces the current methodology of the password anti-pattern, where most people are scraping address books

6. we want to leverage the work that's been put into JCard

7. we would like to offer some basic kind of filtering/querying that is also RESTful

8. we're aiming to invent as little new as possible and to inherit as much existing behavior as possible, while also creating a protocol that is efficient, developer-friendly and that will likely see adoption in a number of contexts, not the least of which are passing around profile data and sharing contact lists.

Anyway, we're not quite ready with something that we want to show for public review yet, but we're getting close. Once we have the basic first draft finished, we'll release it for discussion, just as we did with the OAuth work. Perhaps I shouldn't have mentioned it previously but we are getting close and it's important to know that there is work being done on this problem, and that we're all eager to have a solid solution that is going to be adopted to address the problem that we're all keenly aware of.

Chris

[Joseph A Holsten]

Chris Messina wrote:

Sorry for the mystery Stephen. Joseph Smarr mentioned it at Google I/O and we've been waiting on getting a proper spec together before really putting anything out there. The temporary site is up at:

http://portablecontacts.net/

[snip]

Got a wiki to document the existing [anti]patterns that should be considered?

http:// Joseph Holsten.com

[Chris Messina]

What kind of anti-patterns? The ones that Jeff Atwood pointed out?

http://www.codinghorror.com/blog/archives/001128.html

Try the microformats wiki:

http://microformats.org/wiki/social-network-anti-patterns

Chris

[Joseph A Holsten]

"A pattern is a solution to a problem," says Fowler.
http://martinfowler.com/articles/
writingPatterns.html#PatternsAreSolutions

Chris Messina wrote:
> What kind of anti-patterns?

The (good & bad) solutions to the problems you mentioned:

Things like existing implementations, components, standards and
semantics. That way we can have things to compare against the
forthcoming spec. Something like the analysis of resume formats on
http://microformats.org/wiki/resume-examples
http:// Joseph Holsten.com

[Christopher St John]

On Sun, Jun 8, 2008 at 12:47 PM, Chris Messina <chris....@gmail.com> wrote:
>
> As for backend data formats... I'm not quite sure what you
> mean by "backend"
>

Well, "backend" for my purposes, since I intend to "skin" the
existing distributed social web (what there is of it) with
OpenSocial.

> Our model is rather different than OpenSocial as I understand it, as we're
> trying to architect this in such a way that anyone can host their own
> friends list (for example) and not necessarily defer to Google, MySpace,
> etc... for starters.
>

Hmm, looks like a disconnect, I suspect I explained poorly.
I'm going to risk repeating stuff I know everyone already
knows in the interest of making sure I'm expressing myself
clearly, apologies in advance. So, assumed common
definitions:

- OpenSocial is an API for writing Gadgets that plug into
social networks. It's also an API for backend server-server
communication. As part of that it has a data model
covering about 80% of everything existing social
networks need (including pretty much all the basics).

- Shindig is an OpenSocial wrapper. That is, it exposes out
the OpenSocial APIs, takes care of a bunch of housekeeping,
but doesn't actually implement a social network (storage,
notifications, etc, any of it). It wraps existing social
networks (Orkut, Hi5, etc) but in theory it can sit on top of
anything. You implement a set of integration classes that
map an underlying implementation.

- DiSo defines a set of methods for publishing your part of
the social graph, along with profile data, and even a start
on things like notifications. (It's definitely at least that,
but it may also be more than that, I'm a bit unclear and
need to do some more reading) DiSo mostly (entirely?)
re-uses existing little-s semantic web standards like
microformats, xfn, etc, etc. It lets you not just own, but
entirely control your own data, all the way to hosting
it yourself at the edges rather than centrally.

So, Shindig + stuff-like-DiSo = OpenSocial implemented
on top of the distributed social web. It means I can
implement something for not-Facebook and get DiSo
(or similar) for free.

So you get to host your own part of the distributed
social graph, but you can also sit any of the thousands
of existing OpenSocial applications on top of it.

Well, maybe. That's why it's an experiment :-) I know
that most of it will map, but I'm curious about the edge
cases. What I'm doing overlaps to some degree with
about a million other projects, and part of the point is
to learn about some of those as well.

[Chris Messina]

Yes, your description here is spot on:

 - DiSo defines a set of methods for publishing your part of
 the social graph, along with profile data, and even a start
 on things like notifications. (It's definitely at least that,
 but it may also be more than that, I'm a bit unclear and
 need to do some more reading) DiSo mostly (entirely?)
 re-uses existing little-s semantic web standards like
 microformats, xfn, etc, etc. It lets you not just own, but
 entirely control your own data, all the way to hosting
 it yourself at the edges rather than centrally.

So, Shindig + stuff-like-DiSo = OpenSocial implemented
on top of the distributed social web. It means I can
implement something for not-Facebook and get DiSo
(or similar) for free.

I think a big open question that we've not really at all investigated is how to use Shindig ON TOP OF a DiSo "endpoint"... mapping the data sources that Shindig looks for to DiSo data sources...

Maybe you can help with this, cks?

Chris