The Distributed Social Networking Puzzle: Putting The Pieces Together
Distributed social networking - where users can connect their profile, friends and other data across multiple sites - is still a relatively new concept and not fully developed. There are plenty of companies and projects vying to be a major piece of the distributed social networking puzzle. The big Internet companies have initiatives such as OpenSocial (Google), Facebook Connect, MySpace Data Availability, Yahoo! Open Strategy. There are also smaller company and open source projects such as DiSo and Noserub (we explain these below).
For users the following scenario explains the end goal, albeit too simplistically: in a distributed social networking world you would be able to access your Facebook friends in MySpace, and vice versa. Of course, it's far from a perfect world and the Facebook-MySpace sharing scenario in particular is unlikely to happen any time soon. But slowly social networking is beginning to open up - and not just in the major social networks either.
We spotted an interesting screencast in the ReadWriteWeb Friendfeed room, The Future of Tech, that explains distributed social networking more.
Distributed Social Networking - An Introduction from pixelsebi on Vimeo.
The screencast was created by Sebastian Küpers, an Open Web and Virtual Worlds Evangelist from Germany. He starts by explaining that profiles are a building block of social networks - for example there's a lot of useful profile data in his Facebook account that he'd like to use elsewhere. Friends/contacts, messaging, groups, and activity streams are other building blocks of social networks, explained Sebastian.
He mentioned two projects that are aiming to create distributed social networks by using open standards - DiSo Project (our coverage here and here) and Noserub (a German app). DiSo is basically an umbrella project for many of the leading open standards in the social Web currently - microformats, OpenID, OAuth and more. Noserub describes itself as a "protocol" and uses standards like OpenID, RSS and FOAF.
Sebastian outlined the following use case: if you are a MySpace user and want to add someone who isn't a MySpace user to your friends list, right now you can't. But if MySpace supported the open standards that Noserub, DiSo and others are advocating (microformats, OpenID, etc), then it would be possible for MySpace to support that scenario.
Key Differences Between DiSo/Noserub and OpenSocial/fbConnect
One question that people have about distributed social networks, which Sebastian might like to address in a future screencast, is what is the relation between open source projects like DiSo and Noserub, and 'open data' projects of the bigcos such as Google's OpenSocial and Facebook Connect? Chris Messina, one of the founders of DiSo, pointed out one key difference in DiSo's Google Group in June:
"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."
So for DiSo, they are using the Wordpress blogging platform as their main vehicle for now. However in the same message, Chris mentioned that he's "personally very interested in the overlap between DiSo and fbConnect and OpenSocial." See also Marc Canter's comments on DiSo, because Marc's "open mesh" theories are very relevant here.
If Everything is So Open, Why Can't We Connect Yet?
There is confusion right now because all the commercial vendors are positioning themselves as open - yet they don't necessarily connect to each other! For example Google has been using the term "Open Stack" to explain what OpenSocial is doing. OpenSocial is still in development and it's important to point out that Google doesn't 'own' it, although it is obviously driving it. But OpenSocial isn't being used by key players like Facebook and Microsoft; and when it is being used by bigcos it can be buggy - a RWW commenter recently remarked that MySpace's OpenSocial implementation is "incredibly buggy". So the fact that all of the main pieces of the distributed social networking puzzle are still in beta, goes some way to explaining why ordinary people can't connect many of their profiles just yet.
We'd like to get some more feedback on distributed social networks in the comments - how would you explain the key differences between DiSo/Noserub and OpenSocial/fbConnect to people? How do you see all the different projects connecting together eventually?
Note: the idea for this post came from the ReadWriteWeb Friendfeed room, The Future of Tech. Thanks to Sebastian Küpers for posting it. If you're want to inspire the RWW crew to write posts on certain topics, our Friendfeed room is a great place to let us know! Thanks also Zee for managing that room for us.
Share
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
The word 'open' has lost all meaning.
The point is not open, but interoperable.
You can only achieve interoperability if we are all speaking the same language. The language and syntax is a pre-determined set of open standards and protocols implemented in a pre-determined way. Without this, while the platforms are 'open' (i.e. there is SOME way to reach into them) we still have to code defensibly against each API/Platform.
All the projects you mentioned are essentially the 'Apache' of data portability. They are concrete implementations.
What's needed is agreement on how the web request (or in this case, the data request) is handled. The HTTP and HTML of the data web.
These will emerge from the projects and companies you mentioned, and will be highlighted by the Data Portability project and then advocated by bloggers and early adopters.
We're getting there slowly but surely.
Richard, your quote from Chris Messina is rather out of date. OpenSocial doesn't rely on a few specific large sites, it defines an interoperable specification that anyone can implement, and there are Open Source implementations of it available and in use by many sites big and small. Ning's support means you can build your own small social networks, and Google Friend Connect enables any site to become an OpenSocial container, by building on the Open Stack you describe.
The point of the Open Stack is that each of the pieces are well-specified and can be combined to provide a greater whole. MySpace does support OpenID, OAuth and OpenSocial REST (and hence PortableContacts)
If you want objective data on OpenSocial compliance, instead of hearsay from a commenter, have a look at the Compliance tests or the test matrix
As Chris Saad comments, interoperability is key, but his analogy is a bit confused - there are interoperable implementations of all the pieces in the Open Stack, and they are being deployed by the different containers.
OpenSocial, MySpace Data Availability and Yahoo! Open Strategy all support the same Open Stack.
Kevin, thanks for the clarifications. I will dig deeper into the compliance tests you mentioned. I clicked through now and noticed a lot of red 'Failed' marks beside MySpace's name though. Which seems like it proves the commenter's point?
Facebook Connect has a massive advantage in this area. The fact that site operators can virally promote via the social graph on facebook is a huge bonus. As a site operator, there is no marketing benefit to adopting OpenID at present. Most people still don't know what it is. People know facebook however.
OpenID need to formally adopt the email address instead of a domain. This will allow users to share their email and password combo across facebook and Open ID. Perhaps in the near future, Facebook registration will also automatically generate an Open ID at the same time. This would dramatically speed the adoption and usefulness of OpenID.
Hamish Robertson
Chief Executive Officer
Rowdii.com
Hi Richard,
This work is like herding cattle...reason enough for why it is taking so long...everyone is on OFP (Own F'ing Program).
Cheers.
Thanks for bringing this up, Richard.
I think that the different between DiSo and OpenSocial is still relevant to point out, as I would ideally like to see the ability to 1) use an identity provider of my choice or means (rather than merely one that's been whitelisted) and 2) to pick and choose which services I use for different services -- with the ability to mix and match and swap them out on the fly, as I do with desktop applications.
OpenSocial seems to provide a platform for building applications that get installed into the context of a user's social network profile... I think that there are definitely great aspects of OpenSocial, and I've come to appreciate the work being done on the project (far beyond my initial impression as only a gadgets API). At the same time, I think it's important the perspective of the individual blogger or website owner/operator is represented in this work.
Fortunately the "Open Stack" that is emerging is made up of building block components that can be used separately or
Posted by: factoryjoe.com
|
December 3, 2008 11:52 PM
OpenSocial and projects like NoseRub work very well together. I'm currently waiting for some more and better documentation on what kind of "hooks" an application needs to implement in order to create an OpenSocial container.
Right now, Shindig (http://incubator.apache.org/shindig/) seems the best choice for my purpose.
Once this is settled, I would love to have an OpenSocial containe with each NoseRub installation. And I guess that DiSo would like to have a WordPress PlugIn to support OpenSocial as a container as well.
You then would be able to use those apps from LinkedIn & Co on your own site. *That* is another step to a really distributed social network.
Richard have a look at the work of JanRain and their RPX. https://rpxnow.com/
This is a very interesting project that combines the various "open" solutions to provide interoperability. Apart from Microsoft another player missing from this party is Twitter.
According to Alex Payne on twitter dev group support for Oauth is coming soon. So there is hope.
The worry for the openweb evangelists is that FB connect is doing a good job of the user experience and most users careless about the underlying technology. Once we have interoperability the next challenge will be data portability but once hurdle at a time.
Finally if you have not see www.thesocialweb.tv videos I highly recommend them.
There is work on working with foaf and openid and even simple https (foaf+ssl) on the newly created foaf-protocols list
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
One new OpenID based idea in development is
http://blogs.sun.com/bblfish/entry/foaf_ssl_adding_security_to
All of these have many pieces in common, and the semantic web allows them to be interoperable in a distributed environment.
First of all thanks a lot for mentioning my screecast. I feel quite honored :)
The difference between Distributed Social Networking and OpenSocial is in my eyes quite easy and obvious and contains two different aspects:
First Aspect:
The OpenSocial REST API could be just another way to provide data about profiles, friends and activities within a distributed environment, as DiSo and Noserub do it now with Microformats and FoaF.
Therefore a social network/website, which wants to participate in a distributed environment, could also point (i.e. with XRDS-Simple) to it's OpenSocial REST API, instead or in addition to a RDF/Microformats approach.
Therefore OpenSocials REST API could be another "channel" to provide data in a distributed environment.
Second Aspect:
Of course it would also be very interesting to run OpenSocial Gadgets in an distributed environment. And as I know (please correct me if I am wrong) that this is not the case yet, but of course could be in the future.
If you have seen the screencast, the easiest example would be, that if I host my profile on my Wordpress blog, it also would be great to become an container (OpenSocial Container Wordpress plugin?)and be able to install apps on my profile.
If I have a friend who still uses a social network as we know it today, but which supports distributed social networking in terms of "cross-platform friend adding", we might have installed both the same OpenSocial Gadget. Let's imagine an Gadget which allows me to send my friends virtual flowers. Does that work in a "cross-container/platform" way?
Or to say it with the example of the article and my screecast: will the myspace user one day be able to send virtual flowsers to his facebook friend, who has the same gadget running?
Due to the distributed social networking architecture I could of course also provide these gadgets with data about me and my social graph (profile, friends and activities) - because I can fetch the data of my friends on demand or with a proxie - like Noserub does it right now - but the question is, what needs to be done, that these apps really are able to work in a "cross-container" way.
To sum it up - if I would have to describe it somebody who has no real clue about it at all:
1. Distributed Social Networking is an architecture approach for the social web.
2. DiSo and Noserub are implemenations of this "social web architecture"
3. OpenSocial REST API is one of many ways to provide data in this distributed environment.
4. OpenOScial based Gadgets might run some time at any node/junction of this distributed environment and might be able to handle this distributed social web architecture.
Best Regards,
Sebastian
Hi friends,
i read all the Comments but not understandable some one can tell me in shortly wt happened there.
http://look4leads.com/blogger/index.php?null
http://www.look4leads.com/
http://look4leads.com/forum/index.php
http://look4leads.com/SellerServ?method=sellerRegistrationForm&&userType=2
saurabh.prakash.gupta@gmail.com
"If Everything is So Open, Why Can't We Connect Yet?"
Greed. Pure and Simple.
Everyone seems to be ignoring the gorilla in the room - big companies treat us users like a commodity, buying, selling, trading us for a few pennies a head to the spammers and junk emailers ( read the ToSes! ).
Distributed social networking will never happen as long as the trifecta is skewed to always favor the platform owners and the advertisers. Us long suffering Users ( http://mashable.com/2008/05/14/plaxo-comcas/ ) must go up one level and be equally represented at the table and be treated as first class citizen at the least
...if anything our aggregate attention and mouse clicks are so valuable we are in fact in a position to dictate that Distributed social networking standards be in our control.
This is a subject close to my heart. As the CEO of a niche social network, I have long been looking to "standards" to see users active on other social networks able to use ours without needing to go through the pain of registering a building a friends list from scratch.
Although I have seen some promise in DiSo (or rather OpenID, OpenAuth and OpenSocial) and Facebook, I think I'd rather see another way of doing it.
For me, the most sense is that a central repository, based on open standards/open source, holds an identity profile and data around how they relate to other people with indentity profiles (their "social graph"). Then, any social network or other website can be granted access to the central repository to authenticate them into new or existing sites and to extend the social elements of those sites out to the existing friends list. You effectively need only one identity and one friends list, but can use it anywhere.
Of course, the central repository could be virtual (so, in fact, spread across the user databases of Facebook, Google, MySpace etc.) but all the data is held, or at least accessible, in a standard format which the destination website can use.
If any of the bodies trying to determine standards could focus on this and then give out a spec by which the large networks code to for the purposes of their databases being part of the repository then all could be swell, no?
Closest I have seen to this is OpenID, but it lacks the centralised friends list and is a pig to use even for only authentication.
Ian Hendry
CEO, WeCanDo.BIZ
http://www.wecando.biz
Ian,
If open models are so important, why are you not allowing OpenID to create a membership? It appears on your new sign up page that I'm required to set up yet another account, into which I can import all of my external contacts.
Where's the "open" love?
Sam, thanks for the mention of http://rpxnow.com. We're interested in more market feedback like yours on Twitter and what other forms of identity and data could be rolled into our SaaS offering.
What's most important is to understand what website operators and end users want w.r.t. functionality, ease of use, data management, etc. JanRain and other members of the OpenID and user-centric, open web communities have been working hard to evolve the basic technologies including OAuth, Portable Contacts, hCards, Open Social, etc. into platforms that will ultimately benefit websites and end users. You can see some of the history on this at http://blog.janrain.com/2008/12/response-to-wired-blog-on-facebook.html/ and http://blog.janrain.com/2008/11/openid-user-experience-data.html
We look forward to more constructive feedback like yours, thanks again.
sorry, silly fingers...
Ian, let me explain. OpenID is but one example of being open. I could have said Information Card instead. (Noted that OpenID has wider adoption.)
There's a concept that you're likely familiar with called VRM (a temporary name). The basic idea is that there is a conversation to be found and developed between buyers and sellers. See, for example, any number of posts and discussions linked to and from http://blogs.law.harvard.edu/vrm/
Your business is potentially suited to be an ideal intermediary in this space. There's no question that one's contacts and network are a valuable in this equation. However, I believe you could do better to touch the network rather than own a version of it.
I encourage you to consider setting up your space to allow for buyers and sellers to have "want to buy" and "want to sell" conversations in their own space, with you as facilitator, helping connect the buyers and sellers. This way your data stays current and with the flow, and your customers have ongoing reason to work with you (as opposed to "it worked (or not) once").
Note that this does not mean abandon your current membership model, just open it up. Take a look at REL buttons and related concepts (e.g., site above). See if there's anything in this open space that you can try first. You're potentially in a powerful position to move this open idea forward. I urge you to consider this power.
chris is partly right.
the key issue is "interoperability."
the use of open, standards-based protocols is just ONE way to achieve interoperability. case in point is email. but i'd argue that open, standards-based protocols are NOT necessary to achieve interoperability.
look at SMS. SMS is interoperable across multiple carrier networks, but the carriers did not use ONLY open, standards-based protocols and did not connect directly.
instead, third-parties sprang up in each country to handle the intake and integration of closed, proprietary protocols, and acted as central hubs to receive messages from proprietary protocol A, convert it, and transmit it to proprietary protocol B.
So, what you are all after is "open interoperability" where anyone can get involved and interoperate with anybody else. but in reality what you're likely to get is "closed interoperability" where ONLY THE LARGEST social networks peer up and the small guys are left out in the cold.
Todd is right. there's too much money at stake for the largest social networks to throw away their network effect.
OK... so you'd prefer SMS or Hailstorm rather than Email or the Web?
Welcome to our new Facebook overlords then I guess.
me personally? no, i would not prefer it. but i was commenting more on what WILL happen, not what SHOULD happen. Plus, regarding preferences here, it really depends on the agent and the agent's interests.
average users: don't care either way, as long as it works.
power users: open interoperability, because they're informed
startups: open interoperability
established companies: closed interoperability, if any at all