OpenSocial
Sean Colombo
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
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
>
> 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
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
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
Benjamin Nowack
>
>... 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
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
melvster
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
>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
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
Daniel Feygin
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
the same app you have on each network. OpenSocial doesn't seem to do
anything in the way of consolidating identities.
Daniel
Alexey Gabsatarov
Daniel Feygin
Julian Bond
>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.
杨远骋
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
But something tells me there is still a long way towards it...
anders conbere
> 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
> Could not agree more. But one does not exclude the other.
They don't /exclude/ each other because they're barely related :)
~ Anders
杨远骋
Max Engel
- Max
Rao Meka
Daniel Feygin
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
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
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
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
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
> 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
anders conbere
>
> 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
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
anders conbere
> 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
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
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.