ActivityStreams and new W3C Working Group Charter

[hha...@ibiblio.org]

Everyone,

As promised, after lots of back and forth internally inside the W3C, here's the charter for the W3C Social Web Working Group:

https://www.w3.org/2013/socialweb/social-wg-charter.html

We consider the feedback of the ActivityStreams Community to be of highest importance and we'll work any feedback in. Overall, the goal would be to get wider implementation of the already fairly mature of AS 2.0 (but work that feedback from implementers in), as well design an HTML5-centric API (likely based somewhat on OpenSocia, but reworked from ground up)  for the consumption and (possibly server-side federation as well) production of ActivityStream updates.

We'd go through normal W3C process: a formal process for tracking/resolving issues, weekly telecons, implementation interop reports with a test-suite, and Royalty-Free licensing - which should help drive adoption. And we totally agree that things need to be as open to the Community, so folks who aren't W3C members who have been involved in the community can be Invited Experts to the Working Group that guarantees a royalty-free legal agreement on the specs. Furthermore, the open mailing list for the public can continue, and the Working Group (at least before finalizing the spec) will *have* to respond to public feedback from anyone on the Internet within scope of the charter.

Happy to answer any questions! Happy to schedule a Google Hangout as well to discuss, or come over to San Francisco personally (although that won't be till December). If you guys here approve in general, we'll start working this heavily at the various companies inside W3C to get an idea about how many implementers we'll get on board via the Working Group.

   yours,
     harry

[James M Snell]

Harry,

Thank you for posting the update.

Everyone else,

If you have any concerns/questions/comments, please let us know. I
will be participating in this WG and have volunteered to continue
acting as the editor for the Activity Streams specification. The WG
has agreed to use the current AS 2.0 draft as the basis for this work
and has agreed to make sure the process remains as open as possible. I
will commit to this list to post a weekly status review of the process
and to represent the concerns of this community as much as possible
within the WG, so if any concerns come up, please speak up on list!

- James

> --
> You received this message because you are subscribed to the Google Groups
> "Activity Streams" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to activity-strea...@googlegroups.com.
> To post to this group, send email to activity...@googlegroups.com.
> Visit this group at http://groups.google.com/group/activity-streams.
> For more options, visit https://groups.google.com/groups/opt_out.

[Melvin Carvalho]

On 4 November 2013 17:06, James M Snell <jas...@gmail.com> wrote:

Harry,

Thank you for posting the update.

Everyone else,

If you have any concerns/questions/comments, please let us know. I
will be participating in this WG and have volunteered to continue
acting as the editor for the Activity Streams specification. The WG
has agreed to use the current AS 2.0 draft as the basis for this work
and has agreed to make sure the process remains as open as possible. I
will commit to this list to post a weekly status review of the process
and to represent the concerns of this community as much as possible
within the WG, so if any concerns come up, please speak up on list!

+1 great news!

[Owen Shepherd]

My comments relate to the following sections of the charter:

The Social Web Working Group may develop a Recommendation-track Web protocol to allow the federation of status updates and other data, such as profile information, between heterogeneous Web-based social networking systems. This work will be based work on a federated social web explored both in HTTP (using Pubsubhububub) and XMPP.

I think, if there's anything we've learned from OStatus, it's that Pubsubhububub is the wrong protocol to be building a federated social network on top of (as is Salmon). I'm also concerned about proposals which seem to imply building upon top of both HTTP and XMPP; that sounds very much like a recipe for a complex protocol which nobody will ever implement.

If there is any protocol we should take as a base for a new federated social networking protocol, IMO it is that of pump.io, because it is simple and concise. The whole API specification is 613 lines of Markdown, and that is very complete. There are a few areas I have issues with, but largely it does its' job well. It's a young protocol with an already vibrant ecosystem (nearing two interoperable servers, many interoperable clients)

This is an area which I feel particularly interested in. I'd love to take the Pump protocol and tidy up the warts in it (in particular, simplifying some of the server-to-server and client-to-remote-server authentication matters)

The Social Web Working Group may develop a Recommendation-track document that defines an API, based on OpenSocial, that lets developers embed of third party information with bidirectional communication inside Web applications. The focus will be on enabling the secure capabilities needed by social applications, which is necessary to bring areas such as social business to their full potential and avoid fragmentation.

This one concerns me. In terms of the deliverable dates, I think it is backwards with that for the above. In particular, OpenSocial contains a bunch of "Server API" specs which are entirely duplicative of those which will naturally fall out of any federation API. Referencing pump.io again (being as it seems to be the most complete ActivityStreams-based social networking solution), the client-to-server API is almost completely a subset of the server-to-server API.

OwenShepherd.net | The day to day musings of me (Also seen as XgF)

[Melvin Carvalho]

On 13 November 2013 00:07, Owen Shepherd <owen.s...@e43.eu> wrote:

My comments relate to the following sections of the charter:

The Social Web Working Group may develop a Recommendation-track Web protocol to allow the federation of status updates and other data, such as profile information, between heterogeneous Web-based social networking systems. This work will be based work on a federated social web explored both in HTTP (using Pubsubhububub) and XMPP.

I think, if there's anything we've learned from OStatus, it's that Pubsubhububub is the wrong protocol to be building a federated social network on top of (as is Salmon). I'm also concerned about proposals which seem to imply building upon top of both HTTP and XMPP; that sounds very much like a recipe for a complex protocol which nobody will ever implement.

+1 IMHO, I agree that complexity is an inhibitor to adoption ...
 

If there is any protocol we should take as a base for a new federated social networking protocol, IMO it is that of pump.io, because it is simple and concise. The whole API specification is 613 lines of Markdown, and that is very complete. There are a few areas I have issues with, but largely it does its' job well. It's a young protocol with an already vibrant ecosystem (nearing two interoperable servers, many interoperable clients)

Im unsure about this, although I certainly appreciate that 613 lines is concise, it would also be advantageous if there was interoperability with hetrogenous systems, and even better, a test suite.

 

This is an area which I feel particularly interested in. I'd love to take the Pump protocol and tidy up the warts in it (in particular, simplifying some of the server-to-server and client-to-remote-server authentication matters)

+1
 

The Social Web Working Group may develop a Recommendation-track document that defines an API, based on OpenSocial, that lets developers embed of third party information with bidirectional communication inside Web applications. The focus will be on enabling the secure capabilities needed by social applications, which is necessary to bring areas such as social business to their full potential and avoid fragmentation.

This one concerns me. In terms of the deliverable dates, I think it is backwards with that for the above. In particular, OpenSocial contains a bunch of "Server API" specs which are entirely duplicative of those which will naturally fall out of any federation API. Referencing pump.io again (being as it seems to be the most complete ActivityStreams-based social networking solution), the client-to-server API is almost completely a subset of the server-to-server API.

I think that backwards compatibility will be a key factor.  However, most systems are not compatible with anything other than themselves.  So, therefore, it is a question to ask, which systems should there be backwards compatibility towards?

[Owen Shepherd]

On 13 November 2013 02:40, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 13 November 2013 00:07, Owen Shepherd <owen.s...@e43.eu> wrote:

My comments relate to the following sections of the charter:

The Social Web Working Group may develop a Recommendation-track Web protocol to allow the federation of status updates and other data, such as profile information, between heterogeneous Web-based social networking systems. This work will be based work on a federated social web explored both in HTTP (using Pubsubhububub) and XMPP.

I think, if there's anything we've learned from OStatus, it's that Pubsubhububub is the wrong protocol to be building a federated social network on top of (as is Salmon). I'm also concerned about proposals which seem to imply building upon top of both HTTP and XMPP; that sounds very much like a recipe for a complex protocol which nobody will ever implement.

+1 IMHO, I agree that complexity is an inhibitor to adoption ...
 

If there is any protocol we should take as a base for a new federated social networking protocol, IMO it is that of pump.io, because it is simple and concise. The whole API specification is 613 lines of Markdown, and that is very complete. There are a few areas I have issues with, but largely it does its' job well. It's a young protocol with an already vibrant ecosystem (nearing two interoperable servers, many interoperable clients)

Im unsure about this, although I certainly appreciate that 613 lines is concise, it would also be advantageous if there was interoperability with hetrogenous systems, and even better, a test suite. 

What is your definition of "hetrogenous systems"? FWIW, pump.io itself is written using Node.js; MediaGoblin (which should soon be joining the federation in Python). There is a test suite (of sorts) in the pump.io codebase; I don't know if it's everything we want for the spec (and it certainly might need adjustment for aspects which are part of the software vs part of the protocol), but license/Evan permitting, it might be a good start.

 

This is an area which I feel particularly interested in. I'd love to take the Pump protocol and tidy up the warts in it (in particular, simplifying some of the server-to-server and client-to-remote-server authentication matters)

+1
 

I might start editing up a W3C-style spec for the protocol. Whether it becomes the basis for the WG work or not, it'll be a useful thing to have for the Pumpiverse anyway.

The Social Web Working Group may develop a Recommendation-track document that defines an API, based on OpenSocial, that lets developers embed of third party information with bidirectional communication inside Web applications. The focus will be on enabling the secure capabilities needed by social applications, which is necessary to bring areas such as social business to their full potential and avoid fragmentation.

This one concerns me. In terms of the deliverable dates, I think it is backwards with that for the above. In particular, OpenSocial contains a bunch of "Server API" specs which are entirely duplicative of those which will naturally fall out of any federation API. Referencing pump.io again (being as it seems to be the most complete ActivityStreams-based social networking solution), the client-to-server API is almost completely a subset of the server-to-server API.

I think that backwards compatibility will be a key factor.  However, most systems are not compatible with anything other than themselves.  So, therefore, it is a question to ask, which systems should there be backwards compatibility towards?

Right. How much traction does OpenSocial have? Certainly its' formats are very distinct from ActivityStreams; that server side portion is going to need lots of changes anyway if we are to have a "unified" format for discussing and distributing activity on the web.

--
OwenShepherd.net | The low level world

[Melvin Carvalho]

On 13 November 2013 17:08, Owen Shepherd <owen.s...@e43.eu> wrote:

On 13 November 2013 02:40, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 13 November 2013 00:07, Owen Shepherd <owen.s...@e43.eu> wrote:

My comments relate to the following sections of the charter:

The Social Web Working Group may develop a Recommendation-track Web protocol to allow the federation of status updates and other data, such as profile information, between heterogeneous Web-based social networking systems. This work will be based work on a federated social web explored both in HTTP (using Pubsubhububub) and XMPP.

I think, if there's anything we've learned from OStatus, it's that Pubsubhububub is the wrong protocol to be building a federated social network on top of (as is Salmon). I'm also concerned about proposals which seem to imply building upon top of both HTTP and XMPP; that sounds very much like a recipe for a complex protocol which nobody will ever implement.

+1 IMHO, I agree that complexity is an inhibitor to adoption ...
 

If there is any protocol we should take as a base for a new federated social networking protocol, IMO it is that of pump.io, because it is simple and concise. The whole API specification is 613 lines of Markdown, and that is very complete. There are a few areas I have issues with, but largely it does its' job well. It's a young protocol with an already vibrant ecosystem (nearing two interoperable servers, many interoperable clients)

Im unsure about this, although I certainly appreciate that 613 lines is concise, it would also be advantageous if there was interoperability with hetrogenous systems, and even better, a test suite. 

What is your definition of "hetrogenous systems"? FWIW, pump.io itself is written using Node.js; MediaGoblin (which should soon be joining the federation in Python). There is a test suite (of sorts) in the pump.io codebase; I don't know if it's everything we want for the spec (and it certainly might need adjustment for aspects which are part of the software vs part of the protocol), but license/Evan permitting, it might be a good start.

By heterogeneous I mean a diverse set of sites.  The Web itself is hetrogeneous via the hyperlink, it's very easy to create connections from one system to another.  For example, it should be possible for anyone following web standards to add an identity to their roster (either for friending or following) to another system and vice versa.  So I can add a connection on status.net to my friends list, say on my own system, which was possible, and something I've done.  The reverse link was never possible to my knowledge in status.net, and I dont know if it can be done on pump.io.  After you have hetrogenous connections, then that opens the door for status updates, read and write.

 

 

This is an area which I feel particularly interested in. I'd love to take the Pump protocol and tidy up the warts in it (in particular, simplifying some of the server-to-server and client-to-remote-server authentication matters)

+1
 

I might start editing up a W3C-style spec for the protocol. Whether it becomes the basis for the WG work or not, it'll be a useful thing to have for the Pumpiverse anyway.

Documentation is always a plus.  I would be interested to see how you handle user identity, what is in scope, and what is out of scope. 

 

The Social Web Working Group may develop a Recommendation-track document that defines an API, based on OpenSocial, that lets developers embed of third party information with bidirectional communication inside Web applications. The focus will be on enabling the secure capabilities needed by social applications, which is necessary to bring areas such as social business to their full potential and avoid fragmentation.

This one concerns me. In terms of the deliverable dates, I think it is backwards with that for the above. In particular, OpenSocial contains a bunch of "Server API" specs which are entirely duplicative of those which will naturally fall out of any federation API. Referencing pump.io again (being as it seems to be the most complete ActivityStreams-based social networking solution), the client-to-server API is almost completely a subset of the server-to-server API.

I think that backwards compatibility will be a key factor.  However, most systems are not compatible with anything other than themselves.  So, therefore, it is a question to ask, which systems should there be backwards compatibility towards?

Right. How much traction does OpenSocial have? Certainly its' formats are very distinct from ActivityStreams; that server side portion is going to need lots of changes anyway if we are to have a "unified" format for discussing and distributing activity on the web.

I followed opensocial quite closely at the start, there was even talk facebook would adopt it.  But I think it lost some of its buzz and I havent followed it too closely lately.  I'd like to see an environment, where anyone following WEB standards should get a pretty good level of interoperability.  What this means is a spec, compliance, and ideally a test suite. 

ie "if you pass this validator" you'll interop with the rest of the social web.  In previous attempts we never saw a validator and people will implement specs in different ways that are not compatible.

 

--
OwenShepherd.net | The low level world

--

[Owen Shepherd]

On 13 November 2013 18:42, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 13 November 2013 17:08, Owen Shepherd <owen.s...@e43.eu> wrote:

On 13 November 2013 02:40, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 13 November 2013 00:07, Owen Shepherd <owen.s...@e43.eu> wrote:

My comments relate to the following sections of the charter:

The Social Web Working Group may develop a Recommendation-track Web protocol to allow the federation of status updates and other data, such as profile information, between heterogeneous Web-based social networking systems. This work will be based work on a federated social web explored both in HTTP (using Pubsubhububub) and XMPP.

I think, if there's anything we've learned from OStatus, it's that Pubsubhububub is the wrong protocol to be building a federated social network on top of (as is Salmon). I'm also concerned about proposals which seem to imply building upon top of both HTTP and XMPP; that sounds very much like a recipe for a complex protocol which nobody will ever implement.

+1 IMHO, I agree that complexity is an inhibitor to adoption ...
 

If there is any protocol we should take as a base for a new federated social networking protocol, IMO it is that of pump.io, because it is simple and concise. The whole API specification is 613 lines of Markdown, and that is very complete. There are a few areas I have issues with, but largely it does its' job well. It's a young protocol with an already vibrant ecosystem (nearing two interoperable servers, many interoperable clients)

Im unsure about this, although I certainly appreciate that 613 lines is concise, it would also be advantageous if there was interoperability with hetrogenous systems, and even better, a test suite. 

What is your definition of "hetrogenous systems"? FWIW, pump.io itself is written using Node.js; MediaGoblin (which should soon be joining the federation in Python). There is a test suite (of sorts) in the pump.io codebase; I don't know if it's everything we want for the spec (and it certainly might need adjustment for aspects which are part of the software vs part of the protocol), but license/Evan permitting, it might be a good start.

By heterogeneous I mean a diverse set of sites.  The Web itself is hetrogeneous via the hyperlink, it's very easy to create connections from one system to another.  For example, it should be possible for anyone following web standards to add an identity to their roster (either for friending or following) to another system and vice versa.  So I can add a connection on status.net to my friends list, say on my own system, which was possible, and something I've done.  The reverse link was never possible to my knowledge in status.net, and I dont know if it can be done on pump.io.  After you have hetrogenous connections, then that opens the door for status updates, read and write.

 

I'm still not sure what you're aiming at. Of course it's possible for you to follow/"friend" somebody across multiple sites. I'm not sure what you're aiming at. A wide variety of implementations? That might take a while, but we are heading there.

 

 

This is an area which I feel particularly interested in. I'd love to take the Pump protocol and tidy up the warts in it (in particular, simplifying some of the server-to-server and client-to-remote-server authentication matters)

+1
 

I might start editing up a W3C-style spec for the protocol. Whether it becomes the basis for the WG work or not, it'll be a useful thing to have for the Pumpiverse anyway.

Documentation is always a plus.  I would be interested to see how you handle user identity, what is in scope, and what is out of scope. 

Pump at present limits IDs to user@domain form (acct: URIs, as per WebFinger). My wish is to extend this to also support http[s]:// URIs for identity (or indeed anything for which there is a well defined WebFinger mapping - i.e. for which it is possible to extract a domain portion). I'm aiming for a set of "normalization rules" which match those of OpenID Connect (i.e. user@domain -> acct:user@domain; domain.com -> https://domain.com) because they picked sensible rules which make things easy in the common case.

 

The Social Web Working Group may develop a Recommendation-track document that defines an API, based on OpenSocial, that lets developers embed of third party information with bidirectional communication inside Web applications. The focus will be on enabling the secure capabilities needed by social applications, which is necessary to bring areas such as social business to their full potential and avoid fragmentation.

This one concerns me. In terms of the deliverable dates, I think it is backwards with that for the above. In particular, OpenSocial contains a bunch of "Server API" specs which are entirely duplicative of those which will naturally fall out of any federation API. Referencing pump.io again (being as it seems to be the most complete ActivityStreams-based social networking solution), the client-to-server API is almost completely a subset of the server-to-server API.

I think that backwards compatibility will be a key factor.  However, most systems are not compatible with anything other than themselves.  So, therefore, it is a question to ask, which systems should there be backwards compatibility towards?

Right. How much traction does OpenSocial have? Certainly its' formats are very distinct from ActivityStreams; that server side portion is going to need lots of changes anyway if we are to have a "unified" format for discussing and distributing activity on the web.

I followed opensocial quite closely at the start, there was even talk facebook would adopt it.  But I think it lost some of its buzz and I havent followed it too closely lately.  I'd like to see an environment, where anyone following WEB standards should get a pretty good level of interoperability.  What this means is a spec, compliance, and ideally a test suite. 

ie "if you pass this validator" you'll interop with the rest of the social web.  In previous attempts we never saw a validator and people will implement specs in different ways that are not compatible.

Right, there is certainly stuff of value in OpenSocial, I just think that if we are to build a cohesive protocol stack we should build it in the right order:

1. The data formats exchanged (ActivityStreams)
2. How servers talk to each other, and how clients talk to servers (which in a well designed protocol stack look similar, because there is overlap)
3. How "widgets" and "applications" can integrate with social networks
   

Obviously each of those three components can be used independently, but the recommendation should be their use together (building on top of each other from 1. to 3.)

As I understand it, a lot of the use cases of OpenSocial are applications which don't "want" federation (e.g. "intranet" communication sites); that's fine; they can deploy the C2S portion of the protocol without the S2S portion (as XMPP does)

[Melvin Carvalho]

On 13 November 2013 19:57, Owen Shepherd <owen.s...@e43.eu> wrote:

On 13 November 2013 18:42, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 13 November 2013 17:08, Owen Shepherd <owen.s...@e43.eu> wrote:

On 13 November 2013 02:40, Melvin Carvalho <melvinc...@gmail.com> wrote:

On 13 November 2013 00:07, Owen Shepherd <owen.s...@e43.eu> wrote:

My comments relate to the following sections of the charter:

The Social Web Working Group may develop a Recommendation-track Web protocol to allow the federation of status updates and other data, such as profile information, between heterogeneous Web-based social networking systems. This work will be based work on a federated social web explored both in HTTP (using Pubsubhububub) and XMPP.

I think, if there's anything we've learned from OStatus, it's that Pubsubhububub is the wrong protocol to be building a federated social network on top of (as is Salmon). I'm also concerned about proposals which seem to imply building upon top of both HTTP and XMPP; that sounds very much like a recipe for a complex protocol which nobody will ever implement.

+1 IMHO, I agree that complexity is an inhibitor to adoption ...
 

If there is any protocol we should take as a base for a new federated social networking protocol, IMO it is that of pump.io, because it is simple and concise. The whole API specification is 613 lines of Markdown, and that is very complete. There are a few areas I have issues with, but largely it does its' job well. It's a young protocol with an already vibrant ecosystem (nearing two interoperable servers, many interoperable clients)

Im unsure about this, although I certainly appreciate that 613 lines is concise, it would also be advantageous if there was interoperability with hetrogenous systems, and even better, a test suite. 

What is your definition of "hetrogenous systems"? FWIW, pump.io itself is written using Node.js; MediaGoblin (which should soon be joining the federation in Python). There is a test suite (of sorts) in the pump.io codebase; I don't know if it's everything we want for the spec (and it certainly might need adjustment for aspects which are part of the software vs part of the protocol), but license/Evan permitting, it might be a good start.

By heterogeneous I mean a diverse set of sites.  The Web itself is hetrogeneous via the hyperlink, it's very easy to create connections from one system to another.  For example, it should be possible for anyone following web standards to add an identity to their roster (either for friending or following) to another system and vice versa.  So I can add a connection on status.net to my friends list, say on my own system, which was possible, and something I've done.  The reverse link was never possible to my knowledge in status.net, and I dont know if it can be done on pump.io.  After you have hetrogenous connections, then that opens the door for status updates, read and write.

 

I'm still not sure what you're aiming at. Of course it's possible for you to follow/"friend" somebody across multiple sites. I'm not sure what you're aiming at. A wide variety of implementations? That might take a while, but we are heading there.

 

 

This is an area which I feel particularly interested in. I'd love to take the Pump protocol and tidy up the warts in it (in particular, simplifying some of the server-to-server and client-to-remote-server authentication matters)

+1
 

I might start editing up a W3C-style spec for the protocol. Whether it becomes the basis for the WG work or not, it'll be a useful thing to have for the Pumpiverse anyway.

Documentation is always a plus.  I would be interested to see how you handle user identity, what is in scope, and what is out of scope. 

Pump at present limits IDs to user@domain form (acct: URIs, as per WebFinger). My wish is to extend this to also support http[s]:// URIs for identity (or indeed anything for which there is a well defined WebFinger mapping - i.e. for which it is possible to extract a domain portion). I'm aiming for a set of "normalization rules" which match those of OpenID Connect (i.e. user@domain -> acct:user@domain; domain.com -> https://domain.com) because they picked sensible rules which make things easy in the common case.

The new acct: scheme is interesting.  Let's see if it catches on.  In order to easily work with pump you'd probably need a stable URL in which you could put an identity, something similar to gnu social's (formerly status.net) implementation of FOAF.  It's good that pump accepts acct: URIs, but if that the *only permitted* URI, it's not going to have much chance of interoperability.

 

 

The Social Web Working Group may develop a Recommendation-track document that defines an API, based on OpenSocial, that lets developers embed of third party information with bidirectional communication inside Web applications. The focus will be on enabling the secure capabilities needed by social applications, which is necessary to bring areas such as social business to their full potential and avoid fragmentation.

This one concerns me. In terms of the deliverable dates, I think it is backwards with that for the above. In particular, OpenSocial contains a bunch of "Server API" specs which are entirely duplicative of those which will naturally fall out of any federation API. Referencing pump.io again (being as it seems to be the most complete ActivityStreams-based social networking solution), the client-to-server API is almost completely a subset of the server-to-server API.

I think that backwards compatibility will be a key factor.  However, most systems are not compatible with anything other than themselves.  So, therefore, it is a question to ask, which systems should there be backwards compatibility towards?

Right. How much traction does OpenSocial have? Certainly its' formats are very distinct from ActivityStreams; that server side portion is going to need lots of changes anyway if we are to have a "unified" format for discussing and distributing activity on the web.

I followed opensocial quite closely at the start, there was even talk facebook would adopt it.  But I think it lost some of its buzz and I havent followed it too closely lately.  I'd like to see an environment, where anyone following WEB standards should get a pretty good level of interoperability.  What this means is a spec, compliance, and ideally a test suite. 

ie "if you pass this validator" you'll interop with the rest of the social web.  In previous attempts we never saw a validator and people will implement specs in different ways that are not compatible.

Right, there is certainly stuff of value in OpenSocial, I just think that if we are to build a cohesive protocol stack we should build it in the right order:

1. The data formats exchanged (ActivityStreams)
2. How servers talk to each other, and how clients talk to servers (which in a well designed protocol stack look similar, because there is overlap)
3. How "widgets" and "applications" can integrate with social networks
   

Obviously each of those three components can be used independently, but the recommendation should be their use together (building on top of each other from 1. to 3.)

Yes this makes sense, I think would be beneficial to see that reach standards track.  Activity Streams 2.0 seems a great basis to create data streams that both clients and servers can use.  Also needed to be solved is identity, verifying identity (authentication), and access control (privacy) so the right people get to see the right content.
 

As I understand it, a lot of the use cases of OpenSocial are applications which don't "want" federation (e.g. "intranet" communication sites); that's fine; they can deploy the C2S portion of the protocol without the S2S portion (as XMPP does)

--