OpenSocial

5 views
Skip to first unread message

Sean Colombo

unread,
Oct 31, 2007, 11:58:49 AM10/31/07
to Social Network Portability
... so now that Google is allegedly releasing OpenSocial tomorrow...
who's planning on staying up late implementing it, and what cool
things are you planning on doing with it?

I'm probably going to be making it a major backbone of SiloSync:
http://silosync.org/wiki

Everyone else, post your projects! :)

Nate Westheimer

unread,
Oct 31, 2007, 12:23:46 PM10/31/07
to Social Network Portability
Yeah, I'm very interested in hearing what this community thinks about
OpenSocial. It seems we'll be able to use it to turn BricaBox into a
"container" (yeah! we get to scrap our proprietary plans!) but I
haven't derived yet how the open social graph plays into it. How much
social information will these APIs let pass through from LinkedIn to
Friendster to Google to... BricaBox?

What's this community's stance? Will Google-Open be open enough?


Nate Westheimer
BricaBox.com
innonate.com

anders conbere

unread,
Oct 31, 2007, 12:32:51 PM10/31/07
to social-networ...@googlegroups.com
On Oct 31, 2007 9:23 AM, Nate Westheimer <Nate.We...@gmail.com> wrote:
>
> Yeah, I'm very interested in hearing what this community thinks about
> OpenSocial. It seems we'll be able to use it to turn BricaBox into a
> "container" (yeah! we get to scrap our proprietary plans!) but I
> haven't derived yet how the open social graph plays into it. How much
> social information will these APIs let pass through from LinkedIn to
> Friendster to Google to... BricaBox?
>
> What's this community's stance? Will Google-Open be open enough?

I don't think we'll have anything but speculation until they actually
show us what they'll be opening. Show use the api's. Until then it's
just voodoo :)

~ Anders

Phillip Rhodes

unread,
Oct 31, 2007, 1:04:04 PM10/31/07
to social-networ...@googlegroups.com
As Anders said, it's hard to say much until they actually publish the
API spec. But
based on the hearsay that's out there, I expect OpenQabal
<http://openqabal.dev.java.net> to
take a serious look at supporting OpenSocial.


TTYL,


Phil

JP

unread,
Oct 31, 2007, 1:42:30 PM10/31/07
to Social Network Portability
(I posted this on Oreilly's Radar)

So is google addressing the issue of data aggregation? For example,
say you have a profile in 3 social networks {Ning, Orkut, and
LinkedIn} but not in Hi5; How does the application using the APIs know
which one's to check for data? I think one of the next steps needs to
be for designers to begin thinking about the web in terms of a single
"disk/db" abstract model, and the API will allow for them to say "give
me all {friends, images, videos} of openID N" and it pulls them
regardless of server or network. Just like programming at various
layers of say the OSI Networking Layer model, at each level you think
of the data in different abstractions, and I think thats where we will
end up going here.

Yeah, our project will probably implement this since we are in beta
anyway, and its gonna get traction more than likely since google has a
critical mass of users to leverage. My design goal remains the same,
however --- to have a user who has never used our media mashup app to
be able to login via an openID-type login, and then have the app auto-
discover the user's data via some "dhcp-for-data" mechanism, which
then shows up in the application. So we make it so the user experience
has no signup, no install, no setup, just jump right into a tutorial-
>usage. I think the web is heading towards a "any computer feels like
my computer" experience, but before we get there we need that next
abstraction layer.


On Oct 31, 11:58 am, Sean Colombo <s...@motiveforcellc.com> wrote:

Armand du Plessis

unread,
Oct 31, 2007, 1:59:44 PM10/31/07
to social-networ...@googlegroups.com
We won't know until we see what they release. Initially my thinking was that they would be releasing a couple of standards/API specs for which the endpoints would be implemented by the hosts but the more I read the little info available it sounds more like Windows Live/widget/javascript-like client libraries and less like a full-blown API.

Depending on the final format of the API and how the interaction with the different hosts were working I was hoping to simplify the back-end of my prototype OpenID server [1] which at the moment only uses Facebook as an identity store. I was busy reworking the back-end to be able to easily plug-in other providers and OpenSocial sounds ideal, only one client library to implement for aggregating and making available information from multiple hosts/sources. 

Armand


Benjamin Nowack

unread,
Oct 31, 2007, 2:08:18 PM10/31/07
to social-networ...@googlegroups.com
On 31.10.2007 15:58:49, Sean Colombo wrote:
>
>... so now that Google is allegedly releasing OpenSocial tomorrow...
>who's planning on staying up late implementing it, and what cool
>things are you planning on doing with it?
I heard they are only announcing tomorrow, not really releasing.


>I'm probably going to be making it a major backbone of SiloSync:
>http://silosync.org/wiki

From the info that's out there, it doesn't seem to be too useful
for online social graph consolidation (at least not on the backend).
It's said to be based on JS which suggests that it's just an aid
for widget/inline-app developers to make code more reusable (and
drag developers away from facebook). One thing that it *could*
perhaps make possible (via XSS-by-script-tag), is that you could
generate two "friends" widgets, one for SNS1, and one for SNS2,
with the ability to drag contacts from one network to the other.
I'm not sure if the OpenSocial APIs are going to support writes
and cross-site querying, though, or if they are single-container
or read-only. In the latter case I'd prefer less browser-centric
solutions such as microformats and/or rss which can be read and
processed by server-side scripts more easily.

I'd wait a bit with enthusiasm until it's clear how open that
stuff really is. Just standardizing some API calls is, well,
just that: standardization. That's great and everything, but
still a different thing than an open online social graph/network.


Just my three cents,
Benji

--
Benjamin Nowack
http://bnode.org/

James Simmons

unread,
Oct 31, 2007, 10:16:59 PM10/31/07
to social-networ...@googlegroups.com
I really, really like "dhcp-for-data." ;)

Cheers!

James Simmons
http://www.semanticfocus.com

melvster

unread,
Nov 2, 2007, 9:31:05 AM11/2/07
to Social Network Portability
It's out, plaxo have released, but you need to be whitelisted. Orkut
sandbox is available through invititaion. It's based on the google
gadgets API and so far I'm pretty impressed. I can see this having a
large (perhaps even dominant) role in SNP.

On Nov 1, 3:16 am, James Simmons <ja...@avatrion.com> wrote:
> I really, really like "dhcp-for-data." ;)
>
> Cheers!
>

> James Simmonshttp://www.semanticfocus.com

Julian Bond

unread,
Nov 2, 2007, 10:56:39 AM11/2/07
to social-networ...@googlegroups.com
melvster <melv...@gmail.com> Fri, 2 Nov 2007 06:31:05

>It's out, plaxo have released, but you need to be whitelisted.

Whitelisted?

--
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 ***

Dale Newfield

unread,
Nov 2, 2007, 11:25:06 AM11/2/07
to social-networ...@googlegroups.com
From my brief reading at
http://code.google.com/apis/opensocial/
it sounds like this is a platform for building apps on a (single)
generic social network. Are there identity mapping tools that I've
missed that might help an app bridge more than one social network?

-Dale

kevin curry

unread,
Nov 2, 2007, 11:25:28 AM11/2/07
to social-networ...@googlegroups.com
Approved, allowed in.

Daniel Feygin

unread,
Nov 2, 2007, 12:02:05 PM11/2/07
to social-networ...@googlegroups.com
Based on my initial read of the spec, here are the things that appear
to be missing:

1. No universal user/profile ID, so user identities on different
social networks are distinct. Perhaps <link rel="related"> or some
such can be used to indicate alternate identities for the same user at
user's discretion, but it is not spec'ed and seems unlikely this will
be picked up by containers.

2. No service authentication API is part of the spec. Obviously, each
social network is going to require applications to authenticate, since
they will apparently impose their own TOS restricting application
providers' use of social network data. So authentication is going to
be done in different ways by each one and service providers will have
to implement authentication differently for each container.

3. No service discovery. Each social network is apparently going to
have to have its own directory and service providers will have to list
their service and maintain listing in each directory separately.

Perhaps someone can identify these things in the spec to me, but I
made an effort to find them and I did not.

On top of that, Orkut sandbox is only available to Orkut users, so the
pool of Orkut developers is limited to Orkut social network users. Now
invite-only registration makes some sense if you are there to
socialize. It makes a lot less sense if you are just looking to
provide an application to others to socialize in particular ways.
(Would be grateful for an invite, anyone?)

Daniel

P.S. Before I am accused of being an undercover Facebook agent, I
would like to add that I view OpenSocial as a tremendously valuable
effort. I am just suggesting the things that I would like to see
addressed as the spec moves forward.

Daniel Feygin

unread,
Nov 2, 2007, 12:12:10 PM11/2/07
to social-networ...@googlegroups.com
You noticed that too.. Looks like you will be a different person to
the same app you have on each network. OpenSocial doesn't seem to do
anything in the way of consolidating identities.

Daniel

Alexey Gabsatarov

unread,
Nov 2, 2007, 12:18:24 PM11/2/07
to social-networ...@googlegroups.com
An this make sense if you think of OpenSocial as platfrom API aggregator. Identity data belongs to "hosts" - Facebook etc.

Daniel Feygin

unread,
Nov 2, 2007, 12:22:21 PM11/2/07
to social-networ...@googlegroups.com
Yes, speaking in these terms I was hopeful it would belong to the user.

Julian Bond

unread,
Nov 2, 2007, 11:55:06 AM11/2/07
to social-networ...@googlegroups.com
kevin curry <kmc...@gmail.com> Fri, 2 Nov 2007 11:25:28

>On 11/2/07, Julian Bond <julia...@voidstar.com> wrote:
>
> melvster <melv...@gmail.com> Fri, 2 Nov 2007 06:31:05
> >It's out, plaxo have released, but you need to be whitelisted.
> Whitelisted?


>Approved, allowed in.

Yes, I know what whitelisting means. ;-) I'm curious as to by who
though. Presumably you mean that a gadget has to be whitelisted by Plaxo
before it can be embedded in the Plaxo container page. Right? Or were
you saying it's more generic than that and gadgets have to be
whitelisted by Google before they can be embedded in a 3rd party
container page, such as Plaxo's.

杨远骋

unread,
Nov 2, 2007, 12:42:06 PM11/2/07
to social-networ...@googlegroups.com
OpenSocial is not the way as I thought it was to be. It's just a API rule which disappointed me so much.

Talks to whitelisted, image that if all the whitelisted work will be done by Google, what'll happen when some hosts want to blacklist a application-coder while others whitelisted him?
--
杨远骋 Yuancheng 13488888177
http://www.YangYC.com

Alexey Gabsatarov

unread,
Nov 2, 2007, 12:49:21 PM11/2/07
to social-networ...@googlegroups.com
Could not agree more. But one does not exclude the other. In case the API is a success the data will hopefully follow and eventually become truly distibuted and managed by end users.

But something tells me there is still a long way towards it...

anders conbere

unread,
Nov 2, 2007, 12:49:59 PM11/2/07
to social-networ...@googlegroups.com
On Nov 2, 2007 9:42 AM, 杨远骋 <koji...@gmail.com> wrote:
> OpenSocial is not the way as I thought it was to be. It's just a API rule
> which disappointed me so much.
>
> Talks to whitelisted, image that if all the whitelisted work will be done by
> Google, what'll happen when some hosts want to blacklist a application-coder
> while others whitelisted him?

I agree. This is /not/ an network portability solution. This is a
network aggregation solution. And the touch on VERY different
problems.

Network portability relies on having unique id's, authorization, and a
standard for passing trust information.

Network aggregation relies on providing in the open profile, media,
and associated meta data.

While the former is really quite difficult to approach as a proper
implementation requires a serious shift in the way we deal with social
networking these days. As in order to maintain a secure solution that
scales and where user data isn't restricted to a single network
requires a distributed network, with standards in place to
authenticate, request trust relations, etc.

The latter however is pretty easy, sure... getting the social networks
to all agree on a single methodology for accessing this kind of user
data is hard, but in many of the networks this data has already been
available in some way or another through their own api's. This might
save social networking application developers a little bit of time and
energy in creating and disseminating their applications. But it does
little or nothing to open up the global social network.

~ Anders

anders conbere

unread,
Nov 2, 2007, 12:51:18 PM11/2/07
to social-networ...@googlegroups.com
On Nov 2, 2007 9:49 AM, Alexey Gabsatarov <alexey.g...@gmail.com> wrote:
> Could not agree more. But one does not exclude the other.

They don't /exclude/ each other because they're barely related :)

~ Anders

杨远骋

unread,
Nov 2, 2007, 1:14:28 PM11/2/07
to social-networ...@googlegroups.com
The former is what the Social Graph's final goal. But final goal could not be achieved with only one step, so we need some other steps to graduately realize it. I think Google's OpenSocial is a great step.

Max Engel

unread,
Nov 2, 2007, 1:16:05 PM11/2/07
to social-networ...@googlegroups.com
Exactly.  OpenSocial is an standardized alternative for developers that is analogous to Facebook's FBML (markup language) and FQL (query language).  While this certainly eases coding efforts for developers by providing a framework that allows them to write it once and then plug-in to many social networks, it does nothing in the terms of the goals of empowering users to gain control and portability over their profile, social graph, vitality, reputation, nor provides any freedom to authenticate at multiple locations to build a ubiquitous identity.

- Max

Rao Meka

unread,
Nov 2, 2007, 1:29:07 PM11/2/07
to social-networ...@googlegroups.com
This is just a way of Google trying to show they can make news in this space too.  What is new about this thing?  And are we saying all the 6000 app developers are not going to stop supporting their apps on FB if FB does not follow the OpenSocial API?  I had bigger expectations from the Google geeks that they would solve the fundamental issue which is to provide inter SN communication like an email does today.  As an end user I still have to put my profile on the top three depending upon where my friends are?  And as an end user it does not matter if the App developer uses FBML or OpenSocial.  I am sure the top 10 Apps who are making big money on FB will port it to other top 10 SN's.

Daniel Feygin

unread,
Nov 2, 2007, 2:18:36 PM11/2/07
to social-networ...@googlegroups.com
OpenSocial certainly does not seem to open up social network silos for
good. It just provides a standardized API for service developers to
add features to social networks in a more or less uniform way. This
will definitely shift the balance away from Facebook and will not
threaten any of the existing social silos supporting OpenSocial.
Google wins, other social networks win.

However it is important to recognize that service developers also win
(more opportunities, lower barrier to entry of each social silo) and
so do the users who will have more services available to them.
OpenSocial is a significant and useful effort, which will change the
way a good portion of the Web develops going forward.

And, market forces permitting, perhaps we will see more in the future
(though things like identity portability don't seem likely to come
from where this came from).

Daniel


On 11/2/07, Max Engel <m...@8bitkid.com> wrote:
>

Rao Meka

unread,
Nov 2, 2007, 2:54:47 PM11/2/07
to social-networ...@googlegroups.com
Here are my fundamental questions:

I totally agree w.r.to app developing, but if an app is popular/useful and millions of them are using in FB, what stops the app developer to port it to other top 10 SN's ?


You might say oh it is expensive to port to 10 other SN's for the app developers.  Well if my app is that popular and being used by millions of them on FB, I guarantee any VC from Sandhill will come running with money to port it to other 10 SN's.

But if my app is not being used in FB where I can make a living or attract funding, I would be wasting my time trying to support that app.

Oh then you might say if more people use it they will know the real use and more people will use it.  - That is a marketing issue.  And it is not like on FB there are about 100 members only, there are about 50Milion and that is enough sampling to see if your app is really useful or not and to support it going forward.


What is the inherent advantage for the SN with this API?  Especially the smaller SN's with 100-1000( or 10k, 100k what ever small means)  members.  Eventually if majority of my friends are on the top 5 or 10 SN's I will go there because none of these apps are useful without my friends even though I get them at the smaller SN's.  - Is this true?  Or am I missing something here?


I guess my point is if we want to take on FB or any of the big SN's then we need to attack the fundamental issue, which is

I have 50 friends 20 are on FB, 10 are on XYZ, 10 are on ABC, 5 are on PQR and the other 3 on (i am running out of names :)), 2 on timbuktu etc.,  And I can still have a social life.  That's how you take on FB and with such a huge open source movement and people like us around the world I think this is the holy grail and that's when we stop the monopoly.

My 2 cent ( or 20 cents).

Rao

anders conbere

unread,
Nov 2, 2007, 3:05:58 PM11/2/07
to social-networ...@googlegroups.com

Absolutely. We can't start to see change in this market until the
economy of networks is changed. Right now the valuation of a social
network is based on the number and the degree of activity of it's
users. This is an economy that supports lockin models and is not
overall beneficial to consumers. With low costs to entry but high
costs of exit these services are not battling in a free market based
on the quality of their services but on the number of my friends that
use it.

The only way to attack that economy is to begin to build a truely open
and distributed social data network built on open and published
standards.

And there /are/ technologies today that provide for this kind of
interaction. I think that the xfn/hcard interactions we've seen have
been very promising for an initial move (but they require too much
work on the part of the user, and the way we might distribute this
kind of data isn't well answered). FOAF has made a big push into this
area, but we're still left we our data being hosted somewhere, self
managing, or importing and exporting foaf files between networks.

The bigger problem with both of these is that we rely on social
networks in a lockin economy to open up this data and provide pathways
for this to work.

This is why I continue to push for some serious effort being put into
looking at some of the other currently available standards. And the
way that we can begin creating social applications on top of these
globally accessibly free networks that have very low barrier to entry
(friend imported instantly) and very low barrier to exit (your trust
relationships are not bound to that service to moving to a new and
better one is trivial).

~ Anders

Rao Meka

unread,
Nov 2, 2007, 3:26:21 PM11/2/07
to social-networ...@googlegroups.com
And I am very much disappointed by Google.  I think this shows them in a very poor light.  It looks like they are scared of what FB is doing.  They should have said, let's hit the real problem with the power they have (bigger Megaphone where people will listen and bigger dollars).  They should have come up or said let's come up with a inter SN architecture, that would have made FB take notice, because if I can interact with my 80% friends on FB and other 20% on niche players there is no need for people to go signup on FB (there by decreasing the signups on FB) or other major players because I can still interact with them.  That's when people will stop signing up at FB or other players just because they are on those SN's.  This API is not a big deal to shake up FB.  I would love to see who will stick with Google if they say SN's should be inter operable.  There goes MySpace, IBibo, Hi5 etc.,

This API is good for app developers, google and top 10 SN's.  Once this API is in place all the smaller SN players will think that users will come because of the new APP and I say they wont and go and change their products to work with the API and release it and wait for the users to come.  But they wont.  However even if they come they can convince about 100-200-1000 members to use it.  And if there are about 1000 such SN's which can use the APP what is the advantage for the SN?  1000 membersx1000 SN's will give the app developer enough aggregated members to get some ad dollars (which most probably) will be served by Google (Google AdSense) and the SN's will be the suckers wondering how come the other users are not coming to them even though they have the most popular app on their SN also.  And the losers are smaller SN players who have to eventually close down no matter how many apps they have.  If the apps are useful for an individual user (like Flickr storage, bandwidth, backup etc.,) no need for being part of any SN. 

This is a time to weed out the small (I think there might a million of these) SN's, then each one of the end user will sign up with 2-3 top SN's to cover all their friends and the stagnant period of SN starts like email, unless you are a app developer or the industry lets inter SN communication, which I believe even Google is not really interested in.

I am hoping i make sense or am I high and only I see this whole thing this way?!!  (need to stop watching beauty and the geek)

Interesting times.

Rao

Daniel Feygin

unread,
Nov 2, 2007, 3:59:59 PM11/2/07
to social-networ...@googlegroups.com
I do not see why OpenSocial disproportionately benefits the larger
networks. I do see how it benefits those who were caught off guard by
Facebook. It simply gives them something to create an incentive for
application developers to develop to their API in addition to or
instead of Facebook's API. This something is application portability.

The underlying market forces are unchanged: the more users the network
has, 1) the more sticky (valuable to its users) it is and 2) the more
attractive it is to new users. This is the network effect and it is
independent of OpenSocial. Same applies to IM and any other
communication service, whether online or off. The same dynamic
underlies the ongoing migration of application-specific networks onto
horizontal social networks -- more value in bigger network, and the
only way to be big is to be generic.

Of course, social network portability can disrupt that and you
wouldn't have to build the biggest network, you would just have to be
part of a "meta-network" and every network's value grows when a new
user signs on to any of its nodes. As much as I would like it to
happen, I just don't see a business case for it (doesn't mean there is
none or that none will ever be). Portability would have to offer an
appreciably enhanced user experience for it to get any kind of mass
adoption.

Daniel

Uldis Bojars

unread,
Nov 2, 2007, 4:15:21 PM11/2/07
to social-networ...@googlegroups.com
On 11/2/07, Max Engel <m...@8bitkid.com> wrote:
> Exactly. OpenSocial is an standardized alternative for developers that is
...

> networks, it does nothing in the terms of the goals of empowering users to
> gain control and portability over their profile, social graph, vitality,
> reputation, nor provides any freedom to authenticate at multiple locations
> to build a ubiquitous identity.

Its a solution for Social Application Portability but does little to
help with social network migration, at least in the form that Google
OpenSocial is now.

There can be many paths to social network migration including social
network sites opening up our social graph (e.g., LiveJournal does
that), people each advertising their presence on social networks in
their personal profiles, etc.

OpenSocial API (and other social applications frameworks) can also be
extended with functionality to support social graph portability. Maybe
we will see that happen soon. API call is needed for finding users on
the social network. Also, a call that lets you add them to your
friends list would help.

E.g., a new function findPeople() could be added which takes a
parameter uniquely identifying a person (email, OpenID, etc.) and
returns an ID that can be used by other OpenSocial API calls. Would
that be very difficult to do?

Also, if OpenSocial were using a hash of email address as the
{person-id} then we would not even need to use such a call but could
address the person directly as, for example:
http://orkut.com/feeds/people/{person-id}/

P.S. A data source with your social graph (open on the web or accessed
using your login/pwd) is that you would feed to this findPeople() call
is still needed anyway.

Uldis

[ http://captsolo.net/ ]

anders conbere

unread,
Nov 2, 2007, 4:47:33 PM11/2/07
to social-networ...@googlegroups.com
On Nov 2, 2007 1:15 PM, Uldis Bojars <capt...@gmail.com> wrote:
>
> On 11/2/07, Max Engel <m...@8bitkid.com> wrote:
> > Exactly. OpenSocial is an standardized alternative for developers that is
> ...
> > networks, it does nothing in the terms of the goals of empowering users to
> > gain control and portability over their profile, social graph, vitality,
> > reputation, nor provides any freedom to authenticate at multiple locations
> > to build a ubiquitous identity.
>
> Its a solution for Social Application Portability but does little to
> help with social network migration, at least in the form that Google
> OpenSocial is now.

I disagree with the user of "social network migration" here. That's
not what I feel we're trying to achieve. Dictating to the worlds
social web applications that they export the network data as foaf is
simple but prohibitive to most users. When we say we want
"portability" I think we mean we want to seemlessly move from service
to service, without migrating data.

>
> There can be many paths to social network migration including social
> network sites opening up our social graph (e.g., LiveJournal does
> that), people each advertising their presence on social networks in
> their personal profiles, etc.

I agree those are all paths to "migration" but migration isn't what we
want. Migration is unidirectional, migration is user intensive, and
it's stateless.

>
> OpenSocial API (and other social applications frameworks) can also be
> extended with functionality to support social graph portability. Maybe
> we will see that happen soon. API call is needed for finding users on
> the social network. Also, a call that lets you add them to your
> friends list would help.

This entire idea of working on portability from the area of semantic
web is backwards. This is attempting to build a backend stateful
service from a layer of aggregation. It might be a nice stop gap
measure. But it will be VERY difficult to solve portability this way.

It's is however VERY good at linking data sources together. This is an
aggregation layer, the cream on top of the web that we use to
understand data. Not the backbone deep underneath that provides
service like unique identification, and trust relations.

>
> E.g., a new function findPeople() could be added which takes a
> parameter uniquely identifying a person (email, OpenID, etc.) and
> returns an ID that can be used by other OpenSocial API calls. Would
> that be very difficult to do?

This is nearly impossible as opensocial doesn't dictate how to store
users, so a lookup becomes exceptionally difficult.

>
> Also, if OpenSocial were using a hash of email address as the
> {person-id} then we would not even need to use such a call but could
> address the person directly as, for example:
> http://orkut.com/feeds/people/{person-id}/

Yes but open social is limited in that it's attempting to appeal to a
wide variety of existing services, and none of them are going to want
to change the way they store users.

Rao Meka

unread,
Nov 2, 2007, 6:39:32 PM11/2/07
to social-networ...@googlegroups.com
I am Rao.

I am on SN1.  On that SN1 I have three of my friends (f1,f2,f3).  It has Apps A1,A2,A3.
On SN2 - I have my other three friends(f4,f5,f6). SN2 also has Apps A1,A2,A3.


Daily I log into SN1 and do my social activities with my other friends f1,f2,f3.  But I cannot communicate with f4,f5,f6.

Same thing with f4 on SN2, he/she logs in every day on SN2 and communicates with f5,f6.  But cannot communicate with me.

If I cannot fix that problem what is the real use of A1,A2,A3 ?



I would like to ask the following?

1. Is this a problem in the first place?

2. If it is why are people not targeting this problem?

Rao




On 11/2/07, anders conbere <acon...@gmail.com> wrote:

anders conbere

unread,
Nov 2, 2007, 6:52:37 PM11/2/07
to social-networ...@googlegroups.com
On Nov 2, 2007 3:39 PM, Rao Meka <mrm...@gmail.com> wrote:
> I am Rao.
>
> I am on SN1. On that SN1 I have three of my friends (f1,f2,f3). It has
> Apps A1,A2,A3.
> On SN2 - I have my other three friends(f4,f5,f6). SN2 also has Apps
> A1,A2,A3.
>
>
> Daily I log into SN1 and do my social activities with my other friends
> f1,f2,f3. But I cannot communicate with f4,f5,f6.
>
> Same thing with f4 on SN2, he/she logs in every day on SN2 and communicates
> with f5,f6. But cannot communicate with me.
>
> If I cannot fix that problem what is the real use of A1,A2,A3 ?
>
>
>
> I would like to ask the following?
>
> 1. Is this a problem in the first place?

This is a problem in the same way that browser market dominance is a
problem and platform lock in with operating systems is a problem.
These are not necessarily problems where solutions are demanded from
consumers to the market, but problems that we should be able to see
and recognize as members of the tech community with little bit of
foresight.

>
> 2. If it is why are people not targeting this problem?

1) there are market pressures that make vendor lock in very profitable.

2) it's a tricky problem for which a good answer doesn't exist yet
2 A) the answer to that problem will probably not be able to be monetized.

3) it's a massive paradigm shift for creators of social networks.

Daniel Feygin

unread,
Nov 2, 2007, 6:57:54 PM11/2/07
to social-networ...@googlegroups.com
1. It's the holy grail.

2. It requires social networks to relinquish control. I explained
earlier in this thread that network effects make this more
disadvantageous the bigger they are. The moment you are able to
communicate (and apps are communication tools) across networks,
network size seizes to be of consequence for adoption.

Daniel

Rao Meka

unread,
Nov 2, 2007, 6:59:39 PM11/2/07
to social-networ...@googlegroups.com
On 11/2/07, anders conbere <acon...@gmail.com> wrote:

On Nov 2, 2007 3:39 PM, Rao Meka <mrm...@gmail.com> wrote:
> I am Rao.
>
> I am on SN1.  On that SN1 I have three of my friends (f1,f2,f3).  It has
> Apps A1,A2,A3.