What's happening at OpenSocial?
Julian Bond
my reading of it.
It started as Google's reaction to Facebook. They already had a gadget
spec aimed at iGoogle and wanted to compete with Facebook. But Orkut and
iGoogle weren't getting the publicity and traction that Facebook were
getting so they played the politics card and turned it into The World vs
Facebook in the hope of creating a critical mass of App developers and
Container developers that could compete.
The first spec was very much Google driven and based on what Orkut and
iGoogle does. There were quite a few oddities about this. For instance,
fairly obvious missing fields because they were also missing in Orkut.
It used Google technologies like GData and AuthSub. But having roped all
the non-Facebook people in then faced push back from people saying they
didn't want GData and AuthSub in a global standard.
Then in the space of a week, we get OpenSocial Foundation, Yahoo
supporting OpenSocial, MS announcing Live Contacts and Google announcing
the Contacts API. Viewed in the context of the MS-Yahoo buyout attempt,
this begins to look like poison pills and more political posturing.
Now we have the OpenSocial spec being passed over to the OpenSocial
Foundation and being treated as a community developed spec in the style
of Atom. It's very much based on the first Google proposals but is
losing it's Google flavour in favour of a more open, vendor neutral
approach. The big drivers here are Apache with the Shindig container
project and MySpace as a major player and implementer.
The big question now for me is to what extent the open-speced version of
OpenSocial gets rolled back into Google and implemented there. There's
really quite a lot of overlap between things like the OS People Data API
and Google's Contacts API. Or between OpenSocial's Gadget API and the
iGoogle gadget API. And proprietary AuthSub (and BBAuth) vs oAuth.
The push to open up the spec to compete with Facebook is going to feed
back into Google's own APIs and mean they lose control of them to some
extent. This isn't entirely new since Google makes extensive use of Atom
and are very much involved in the creation and development of that
standard. They're walking a difficult line here between open-ness and
closed-ness.
There's quite a few areas here that are core to data portability and
DataPortability. Moving profiles and contacts lists is one of
DataPortability's key use cases. Having contacts APIs multiplying is
both good and bad. It's good that APIs are appearing. It's bad that
there's so many of them and they're all different.
--
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
Insert Tab Here
anders conbere
It's also a bit of a false promise since those contacts remain inside
data silo's, they aren't being contributed back out into an accessible
global social network.
~ Anders
Kevin Marks
>
>
> On Tue, Apr 1, 2008 at 12:27 AM, Julian Bond <julia...@voidstar.com> wrote:
> >
> > Something really quite strange is happening over at OpenSocial. here's
> > my reading of it.
> >
> > It started as Google's reaction to Facebook. They already had a gadget
> > spec aimed at iGoogle and wanted to compete with Facebook. But Orkut and
> > iGoogle weren't getting the publicity and traction that Facebook were
> > getting so they played the politics card and turned it into The World vs
> > Facebook in the hope of creating a critical mass of App developers and
> > Container developers that could compete.
> >
> > The first spec was very much Google driven and based on what Orkut and
> > iGoogle does. There were quite a few oddities about this. For instance,
> > fairly obvious missing fields because they were also missing in Orkut.
> > It used Google technologies like GData and AuthSub. But having roped all
> > the non-Facebook people in then faced push back from people saying they
> > didn't want GData and AuthSub in a global standard.
This history is a bit of a parody; the point of OpenSocial is to make
the web social, which means we need interoperating implementations.
This happens by consensual discussions between implementers.
> > Then in the space of a week, we get OpenSocial Foundation, Yahoo
> > supporting OpenSocial, MS announcing Live Contacts and Google announcing
> > the Contacts API. Viewed in the context of the MS-Yahoo buyout attempt,
> > this begins to look like poison pills and more political posturing.
Correlation does not imply causation. Why not evaluate each protocol
and proposal on its merits, rather than as some confused metanarrative
driven on speculation about motives?
> > Now we have the OpenSocial spec being passed over to the OpenSocial
> > Foundation and being treated as a community developed spec in the style
> > of Atom. It's very much based on the first Google proposals but is
> > losing it's Google flavour in favour of a more open, vendor neutral
> > approach. The big drivers here are Apache with the Shindig container
> > project and MySpace as a major player and implementer.
Thats the idea, yes, make it an open standard that is clearly not
controlled by any vendor.
> > The big question now for me is to what extent the open-speced version of
> > OpenSocial gets rolled back into Google and implemented there. There's
> > really quite a lot of overlap between things like the OS People Data API
> > and Google's Contacts API. Or between OpenSocial's Gadget API and the
> > iGoogle gadget API. And proprietary AuthSub (and BBAuth) vs oAuth.
Various bits of it are implemented in various bits of Google. Expect
to see more over time. OAuth support is coming from Google. OpenSocial
APi si built on the iGoogle Gadgets API - Shindig implements iGoogle
gadget hosting.
> > The push to open up the spec to compete with Facebook is going to feed
> > back into Google's own APIs and mean they lose control of them to some
> > extent. This isn't entirely new since Google makes extensive use of Atom
> > and are very much involved in the creation and development of that
> > standard. They're walking a difficult line here between open-ness and
> > closed-ness.
Google is involved in lots of open-source and open standards projects,
from Linux kernel to Python to Webkit to HTML5.
The Shindig code is running inside Google on iGoogle and Orkut. I'm
not sure I get your subtext here.
> > There's quite a few areas here that are core to data portability and
> > DataPortability. Moving profiles and contacts lists is one of
> > DataPortability's key use cases. Having contacts APIs multiplying is
> > both good and bad. It's good that APIs are appearing. It's bad that
> > there's so many of them and they're all different.
The point of OpenSocial is to provide a way to unify these.
> It's also a bit of a false promise since those contacts remain inside
> data silo's, they aren't being contributed back out into an accessible
> global social network.
Who says people want an accessible global social network exclusively?
If they do, there is the Social Graph API to provide one. However,
OpenSocial lets users take advantage of the social network information
within sites, and app developers to use that data without copying it
elsewhere. If you're a web developer, imagine not having to write user
registration code at all.
anders conbere
Yeah that's cool, but it's a data portability false promise. You're
still keeping all your relationship data in a silo. And I don't know
if exposing that data properly is something that people are clamoring
for. But if you're excited about the idea of never having to write
registration.. .if that's what excites you, I see no reason why you
shouldn't be excited about getting that data out globally.
And I'm not sure it's fair to say, "oh you want a globally distributed
social network... use Social Graph", because that again doesn't serve
that purpose. Social Graph by it's nature get's out of date data from
indexed files, it helps you understand relationships, but it doesn't
help you build new ones, it doesn't have api's for injecting back into
the system, it's very static, and in the time scales that we work on
in human relationships it's old.
I'm not saying that I think that these tools by google were /bad/
ideas, I just think that their short comings should be talked about.
It's /nice/ that I can build an facebook like app that works across
any social network that supports the Open Social API's, but it sucks
that I can't connect to users in another social network from with in
it. I'm still bound to the social network I chose, entry and exit
still aren't free. And I propose that they should be.
~ Anders
>
>
>
> >
>
Julian Bond
Oops. I stand corrected! ;)
>> > There's quite a few areas here that are core to data portability and
>> > DataPortability. Moving profiles and contacts lists is one of
>> > DataPortability's key use cases. Having contacts APIs multiplying is
>> > both good and bad. It's good that APIs are appearing. It's bad that
>> > there's so many of them and they're all different.
>
>The point of OpenSocial is to provide a way to unify these.
I'm having trouble seeing how that's going to happen. Why should
OpenSocial become the de facto standard any more than Plaxo Sync, MS
Live Contacts, or FOAF and hCard? Or whatever's in my Outlook contacts.
>> It's also a bit of a false promise since those contacts remain inside
>> data silo's, they aren't being contributed back out into an accessible
>> global social network.
I don't understand the objection that the data is remaining inside silos
if there's an API to get it out. Or do you think that there should be
one true source and apps shouldn't take copies but access it on the fly.
>Who says people want an accessible global social network exclusively?
>If they do, there is the Social Graph API to provide one. However,
>OpenSocial lets users take advantage of the social network information
>within sites, and app developers to use that data without copying it
>elsewhere. If you're a web developer, imagine not having to write user
>registration code at all.
As a developer I'm not convinced by this argument. I think any real
world application is going to need to hold local accounts because there
will always be queries you want to do that are simply impossible without
it. Perhaps it might be possible to populate a profile page on the fly
but anything involving lists of people mixed with local data is going to
be hard if it depends on looking up profile data on the fly for each
row. eg Show me photos from people who live in London. Perhaps we have
to build cacheing schemes but if you're cacheing profile data in a
database, the problem becomes one of keeping sync.
The approaches here are critical to data portability. Whether it's about
porting data from one place to another or accessing it from anywhere.
--
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
Contains Small Parts
Julian Bond
>I'm not saying that I think that these tools by google were /bad/
>ideas, I just think that their short comings should be talked about.
>It's /nice/ that I can build an facebook like app that works across
>any social network that supports the Open Social API's, but it sucks
>that I can't connect to users in another social network from with in
>it. I'm still bound to the social network I chose, entry and exit
>still aren't free. And I propose that they should be.
Anders, OpenSocial is not just the gadget and container APIs. It's also
the Data APIs and I believe these are intended to include (optional)
insert, update and delete methods. What is it in the APIs you think is
missing to do what you want?
--
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
Contains Small Parts
anders conbere
>
> anders conbere <acon...@gmail.com> Tue, 1 Apr 2008 08:45:55
>
> >I'm not saying that I think that these tools by google were /bad/
> >ideas, I just think that their short comings should be talked about.
> >It's /nice/ that I can build an facebook like app that works across
> >any social network that supports the Open Social API's, but it sucks
> >that I can't connect to users in another social network from with in
> >it. I'm still bound to the social network I chose, entry and exit
> >still aren't free. And I propose that they should be.
>
> Anders, OpenSocial is not just the gadget and container APIs. It's also
> the Data APIs and I believe these are intended to include (optional)
> insert, update and delete methods. What is it in the APIs you think is
> missing to do what you want?
What I want most of all (if insert, update and delete methods are
included) is a way to bridge communication between networks. I want to
be able to build an application (like a facebook app), that allows
Alice in flickr to share photos with Bob in picassa. As far as my
reading of the OpenSocial api (admittedly only when it first came
out), the open social platform has only been about build apps on top
of existing networks. It had no way to uniquely reference users across
networks.
Now I can imagine that the reason behind this is that the big networks
would never support a tools that began to limit the power of their
vendor lock in. But to me that's one of the big problems in the social
networking space.
So the solutions thus far have involved "exporting the user data as
xfn or foaf", which is not really that great because now I get a
static copy of my friends from one network in another, and the tools
for re-aggregation and or pinging changes back just aren't there / are
too much work to bother with.
Not to mention serveral different services all with the same copy of
my relationship data seems ... wasteful. To me this is something that
XMPP provides with their roster tools, and I can imagine solving with
FOAF plus some web services. Centralized stores of data in
decentralized networks with the ability to update themselves
dynamically to attempt to preserve some of the immediacy of human
interaction.
~ Anders
Paul Madsen
although a Tony was also hanging around ) that drove the specification
of the Liberty People Service
- http://connectid.blogspot.com/2008/01/what-about-bob.html
-
http://connectid.blogspot.com/2006/01/liberty-people-service-for-group-based.html
-
http://www.projectliberty.org/liberty/content/download/890/6246/file/liberty-idwsf-people-service-v1.0.pdf
paul
--
Paul Madsen e:paul.madsen @ gmail.com
p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com
Christian Scholz / Tao Takashi (SL)
What I want most of all (if insert, update and delete methods are
On Tue, Apr 1, 2008 at 2:19 PM, Julian Bond <julia...@voidstar.com> wrote:
>
> anders conbere <acon...@gmail.com> Tue, 1 Apr 2008 08:45:55
>
> >I'm not saying that I think that these tools by google were /bad/
> >ideas, I just think that their short comings should be talked about.
> >It's /nice/ that I can build an facebook like app that works across
> >any social network that supports the Open Social API's, but it sucks
> >that I can't connect to users in another social network from with in
> >it. I'm still bound to the social network I chose, entry and exit
> >still aren't free. And I propose that they should be.
>
> Anders, OpenSocial is not just the gadget and container APIs. It's also
> the Data APIs and I believe these are intended to include (optional)
> insert, update and delete methods. What is it in the APIs you think is
> missing to do what you want?
included) is a way to bridge communication between networks. I want to
be able to build an application (like a facebook app), that allows
Alice in flickr to share photos with Bob in picassa. As far as my
reading of the OpenSocial api (admittedly only when it first came
out), the open social platform has only been about build apps on top
of existing networks. It had no way to uniquely reference users across
networks.
I also only read the first spec I must admit and we also discussed this during the Barcamp Berlin with David Recordon (it was just out back then)
and it seemed quite clear back then that there is no direct way provided to connect networks. Thus we feeled that the name was somehow not chosen that well,
maybe being more something like OpenSocialGadgets or so.
It seems possible to let the app you implement export/import contacts it might still be not allowed by the TOS of that container.
I also think that having true sync is a big problem. That's why I also would like to tackle e.g. exporting profile information first (no sync) and go from there.
I don't really see opensocial in that regard though. And also remember that it's also not about technology only but also about policy.
Now I can imagine that the reason behind this is that the big networks
would never support a tools that began to limit the power of their
vendor lock in. But to me that's one of the big problems in the social
networking space.
I think back then the policy was that OpenSocial does give all that control to the platform.
This probably means: only selected apps and TOS to prevent from exporting stuff.
In any case there needs to be a policy discussion.
So the solutions thus far have involved "exporting the user data as
xfn or foaf", which is not really that great because now I get a
static copy of my friends from one network in another, and the tools
for re-aggregation and or pinging changes back just aren't there / are
too much work to bother with.
Here it might be easier to have a central server which gets updated from the SNs and having
an OpenID like model in which you choose your "home" server. But that is of course political problematic.
OTOH syncing something across all networks might be quite hard to do when it's decentralized.
-- Christian
--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T
anders conbere
Exactly.
That being said, i haven't found it very hard to convince the owners
of small social networks here in the seattle area that their valuation
doesn't depend on their particular network. There are a ton of
services based networks out there that would greatly benefit from
having a much larger pool of users to pull from, who don't want to
either a) limit themselves to social networks using open social or tie
themselves to facebook, or b) don't want to work to provide valuation
to other services that could possible be competitors.
It seems to me that opening up the social network space has to start
at the bottom where there is very little value to lockin and a large
value in increasing the size of the market as well as reducing
barriers to entry.
I have to say I'm partial to the centralized relationship source
(perhaps provided by your identity broker), because I think the
solutions for querying and aggregation are significantly simpler (how
do you for instance push changes into an xfn network?)
~ Anders
anders conbere
>
> Hi Anders, it was your exact use case (even to the names of Alice & Bob,
> although a Tony was also hanging around ) that drove the specification
> of the Liberty People Service
>
> - http://connectid.blogspot.com/2008/01/what-about-bob.html
> -
> http://connectid.blogspot.com/2006/01/liberty-people-service-for-group-based.html
> -
> http://www.projectliberty.org/liberty/content/download/890/6246/file/liberty-idwsf-people-service-v1.0.pdf
Neat, I'll have to dig into that. I've been working off the XMPP model
for a while and making some headway into allowing their services to be
used by Social Network Services, but it's a slow and difficult
journey.
~ Anders
Julian Bond
2 Apr 2008 00:08:35
>I also only read the first spec I must admit and we also discussed this
>during the Barcamp Berlin with David Recordon (it was just out back
>then)
>and it seemed quite clear back then that there is no direct way
>provided to connect networks. Thus we feeled that the name was somehow
>not chosen that well,
>maybe being more something like OpenSocialGadgets or so.
The very first spec included RESTful Data APIs, one of which was the
People Data API. I don't really understand why this was missed by all
the commentators who've only managed to see the gadget and container
parts. And see this thread
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/
thread/79d16e82dc6230e7#
Call for consensus: RESTful API Spec
>It seems possible to let the app you implement export/import contacts
>it might still be not allowed by the TOS of that container.
>I also think that having true sync is a big problem. That's why I also
>would like to tackle e.g. exporting profile information first (no sync)
>and go from there.
>I don't really see opensocial in that regard though. And also remember
>that it's also not about technology only but also about policy.
I don't see how to avoid Sync.
- Existing applications are not about to give up their account systems
- New Apps are almost inevitably going to build account systems
If every App has got its own account records, then you can copy data
across at account creation but then later you have to keep it in sync.
>Here it might be easier to have a central server which gets updated
>from the SNs and having
>an OpenID like model in which you choose your "home" server. But that
>is of course political problematic.
>OTOH syncing something across all networks might be quite hard to do
>when it's decentralized.
So where is my master account record? It could be anywhere. It might be
my OpenID provider but current OpenID providers don't have rich
profiles. It could be my blog but current blog platforms don't have rich
AboutMe pages. It could be my XMPP server but that has the same problem.
It could be one of the big Social Networks. Oh. Right.
If we try and centralise the social graph, where is the master copy of
that?
All of this leads me to believe that we have to accept a messy,
de-centralised, many to many world where the user's data could be
anywhere and we have to design to that. One of the key problems in this
is recognising that Alice here is the same as Alice there. But that's
not *so* hard. We can make a pretty good stab at it using IFPs like
email, mbox_sha1sum, OpenID.
anders conbere
This is one of the reasons I like the XMPP solution. In the XMPP
ecosystem any social network could host an XMPP server and grant it's
users accounts on that server, but those accounts could just as easily
come from my own XMPP server or Google's. The Decentralized Server to
Server communications in XMPP allow you to centralize your
relationship and identity without centralizing control of the user
data.
Also to talk to the point of not having the tools to deal with this yet.
I guess I kind of feel like that's why were here. If we aren't here to
change the state of things, then why bother discussing this at all.
There ARE problems with XFN and FOAF and XMPP, but there's not reason
they can't be repaired, and we can't come up with tools to make these
kinds of open platforms attractive to new potential social services.
>
> All of this leads me to believe that we have to accept a messy,
> de-centralised, many to many world where the user's data could be
> anywhere and we have to design to that. One of the key problems in this
> is recognising that Alice here is the same as Alice there. But that's
> not *so* hard. We can make a pretty good stab at it using IFPs like
> email, mbox_sha1sum, OpenID.
These technologies don't help to organize identities without the use
of other tools. like... XFN or FOAF. Unfortunately these tools (as
mentioned above) have particular failings.
Is your position that while portability of my data (Be it images,
relationships or videos etc.) is important, control of that data is
less so? And if that's not the case, why is my relationship data
somehow in a separate bin than the rest of my data?
Brett McDowell
Julian Bond
>>One of the key problems in this
>> is recognising that Alice here is the same as Alice there. But that's
>> not *so* hard. We can make a pretty good stab at it using IFPs like
>> email, mbox_sha1sum, OpenID.
>
>These technologies don't help to organize identities without the use
>of other tools. like... XFN or FOAF. Unfortunately these tools (as
>mentioned above) have particular failings.
Using a common field to identify the same person across heterogeneous
systems is independent of the actual transport protocol isn't it?
mbox_sha1sum grew out of work done by the FOAF crew but that doesn't
stop it being used elsewhere.
>Is your position that while portability of my data (Be it images,
>relationships or videos etc.) is important, control of that data is
>less so? And if that's not the case, why is my relationship data
>somehow in a separate bin than the rest of my data?
Look at the use cases here
http://wiki.dataportability.org/display/dpmain/Use+Cases
A big slice of them are about people, their profiles and their contacts.
That's not all there is, but it's a big part. Yes, control over that
data is important. But it's *almost* enough just to have one big switch.
Visible/Accessible or not. For the last 3 years I've got away with
- If it's visible in html, it's visible in FOAF
- Separate switches for hide email, address detail and phone detail
- 3 level switch for Visible to members / Non-members / Search engines
This leads me to think that provided we're talking about relatively
public data and not things like health records, privacy controls are not
a big deal.
Christian Scholz / Tao Takashi (SL)
So where is my master account record? It could be anywhere. It might be
>Here it might be easier to have a central server which gets updated
>from the SNs and having
>an OpenID like model in which you choose your "home" server. But that
>is of course political problematic.
>OTOH syncing something across all networks might be quite hard to do
>when it's decentralized.
my OpenID provider but current OpenID providers don't have rich
profiles. It could be my blog but current blog platforms don't have rich
AboutMe pages. It could be my XMPP server but that has the same problem.
It could be one of the big Social Networks. Oh. Right.
Well, that's why I don't want to start with that probem but instead first would be able to export and import data.
When this hopefully is in more widespread use we might think again if sync makes sense or is possible at all.
But of course doing a manual sync can lead to lots of problem such as the question what the most recent data is and how to collect all your data (it might mean logging in to most of the sites you are a member of).
If we try and centralise the social graph, where is the master copy of
that?
It could follow an openid like model and you can choose which one to take.
All of this leads me to believe that we have to accept a messy,
de-centralised, many to many world where the user's data could be
anywhere and we have to design to that. One of the key problems in this
is recognising that Alice here is the same as Alice there. But that's
not *so* hard. We can make a pretty good stab at it using IFPs like
email, mbox_sha1sum, OpenID.
I think so, too, at least for the beginning. Then we can reconsider based on how business models and the like look in the future or if some services simply want to push ahead.
-- Christian
anders conbere
>
> anders conbere <acon...@gmail.com> Tue, 1 Apr 2008 23:50:19
>
> >>One of the key problems in this
> >> is recognising that Alice here is the same as Alice there. But that's
> >> not *so* hard. We can make a pretty good stab at it using IFPs like
> >> email, mbox_sha1sum, OpenID.
> >
> >These technologies don't help to organize identities without the use
> >of other tools. like... XFN or FOAF. Unfortunately these tools (as
> >mentioned above) have particular failings.
>
> Using a common field to identify the same person across heterogeneous
> systems is independent of the actual transport protocol isn't it?
> mbox_sha1sum grew out of work done by the FOAF crew but that doesn't
> stop it being used elsewhere.
>
>
> >Is your position that while portability of my data (Be it images,
> >relationships or videos etc.) is important, control of that data is
> >less so? And if that's not the case, why is my relationship data
> >somehow in a separate bin than the rest of my data?
>
> Look at the use cases here
> http://wiki.dataportability.org/display/dpmain/Use+Cases
> A big slice of them are about people, their profiles and their contacts.
> That's not all there is, but it's a big part. Yes, control over that
> data is important. But it's *almost* enough just to have one big switch.
I agree that this is an important first step, as it begins to make
moving between social networks easier thus begins to lower the barrier
to entry for trying new ones, thus begins to have these services
compete on the merit of their product not on a strange social
phenomena that now has everyone locked into it.
I guess it's the "almost" I have issues with :)
I'd like to see the group begin to think beyond some of these more basic issues:
"how do we get people to expose data", to
"what do we do with the data once it's out there", to
"what problems are there when we use this data and how do we solve it?"
And in my line of work I'm running up against the latter, and looking
for solutions.
~ Anders
anders conbere
> Given the decision of the Steering Committee last night, I would suggest we
> kick-off an "experiment" using Liberty's People Service to support this use
> case. We have some Java library implementations of People Service at
> www.openliberty.org as a starting point. Is anyone interested in working on
> this project? Can someone help me figure out how to best leverage the DP
> wiki to document this as an official "experiment"?
I can't speak to having large amounts of time free, but I would at
least be interested in chatting and seeing where you guys are heading
and what your service can do.
~ Anders
Brett McDowell
bngu
On Apr 2, 1:33 pm, "Brett McDowell" <brettmcdow...@gmail.com> wrote:
> Paul Madsen, Anders Conbere and I are going to start discussing this
> experiment off-list for the moment. If anyone else is interested please let
> one of us know. Maybe we'll setup a new list just for this.
>
> vCard<http://www.ictprojects.com/Brett_McDowell_LAP.vcf>|
> Calendar<http://www.google.com/calendar/hosted/ictprojects.com/embed?src=brett...>
>
> On Wed, Apr 2, 2008 at 11:51 AM, anders conbere <aconb...@gmail.com> wrote:
>
> > On Wed, Apr 2, 2008 at 6:39 AM, Brett McDowell <brettmcdow...@gmail.com>
> > > Given the decision of the Steering Committee last night, I would suggest
> > we
> > > kick-off an "experiment" using Liberty's People Service to support this
> > use
> > > case. We have some Java library implementations of People Service at
> > > this project? Can someone help me figure out how to best leverage the
> > DP
> > > wiki to document this as an official "experiment"?
>
> > I can't speak to having large amounts of time free, but I would at
> > least be interested in chatting and seeing where you guys are heading
> > and what your service can do.
>
> > ~ Anders
>
> > > Brett McDowell | Liberty Alliance | vCard | Calendar
>
>
> > > > Hi Anders, it was your exact use case (even to the names of Alice &
> > Bob,
> > > > although a Tony was also hanging around ) that drove the specification
> > > > of the Liberty People Service
>
> > > > -http://connectid.blogspot.com/2008/01/what-about-bob.html
> > > > -
>
> > > > -
>
> >http://www.projectliberty.org/liberty/content/download/890/6246/file/...
> > > > paul
>
> > > > anders conbere wrote:
> > > > > On Tue, Apr 1, 2008 at 2:19 PM, Julian Bond <
> > > wrote:
>
> > > > >> anders conbere <aconb...@gmail.com> Tue, 1 Apr 2008 08:45:55