Federated Social Context Proposal
- JamesS
This is a proposal for a new capability for the OS 3.x Timeframe.
======================================
The "Federated Social Context" is an expansion on the fundamental notion of shared social contextual spaces (spaces proposal) that can span across multiple, independent OpenSocial and non-OpenSocial based systems. Here's basically how it would work.
Let's assume we have three users, John, Sally and Joe. Each work for separate companies, each with their own systems.
- John's company uses Lotus Connections... (this is a hypothetical use case... this obviously isn't supported or planned yet)
- Sally's company uses Jive...
- and Joe's company uses a system developed in-house that does not currently support OpenSocial.
John, Sally and Joe have to collaborate on a single project.
The "Federated Social Context" provides a model for allowing them to do so directly within their own application frameworks, with content and capabilities shared seamlessly across the systems.
First, John creates a Community within his local system. Typically, with todays implementation, John would only ever be able to add members to that community that belong to the same system. With the Federated Social Context, however, John can send invitations to Sally and Joe using their email addresses, e.g. sally@example.org, joe@example.com.
Here's what happens when John sends the invitations... we'll call John's server S1, Sally's S2 and Joe's S3..
S1 (John's server)... will take Sally and Joe's email addresses and use those to discover their individual profiles on S2 and S3. This is done by transforming the email addresses into profile queries... e.g.
sally@example.org ==>
https://example.org/.well-known/fsc/278c9ba29aadb0e96aa6d96edcfbd67d
joe@example.com ==>
https://example.com/.well-known/fsc/f5b8fb60c6116331da07c65b96a8a1d1
In case that's not obvious, this builds on the Well Known URL spec RFC 5785 and takes a simple md5 hash of the users email address to perform a profile lookup. Sending a simple GET to the .well-known URL would return either a simplified, reduced version of the users profile or redirect to the users profile. Either way, a successful response tells S1 that each of the invited users exist.
Once S1 has established that the users are valid, it will send a "Social Context Invitation" to each of the profile URLs. This invitation includes the Context ID, URL, and a Pre-authorized OAuth Authorization Token. For example, the following would be sent to Sally's server (S2)
POST /.well-known/fsc/278c9ba29aadb0e96aa6d96edcfbd67d HTTP/1.1
Host: example.org
Content-Type: application/json
{
"objectType":"context",
"id":"https://example.net/api/context/1234abcd",
"url:"https://example.net/api/context/1234abcd",
"authorization":"abcdefghijklmop",
"token-service":"http://example.org/oauth/token",
...
}
Once S2 receives this invitation, it will notify Sally that she's been invited to join the Social Context John created. S2 can send a GET request to the Context's URL to retrieve some basic information about the context so it can present the basic information to Sally. A similar request is sent to Joe's server (S3).
If Sally accepts the invitation, her server, S2 will exchange the authorization token for an access token, then send a "Context Subscription" request back to the Context URL using a simple POST. That request will consist of nothing more than a Link with rel="monitor" and the URL where notifications for the Social Context are to be delivered... (more on this in a second)
POST /api/context/1234abcd HTTP/1.1
Host: example.net
Authorization: bearer 123123123123
Link: <https://example.org/.well-known/fsc/278c9ba29aadb0e96aa6d96edcfbd67d/0d519b6fafdbd6a4fa8ef678b4a5eb1f>;
rel="monitor"
If Joe also accepts the invitation, his server, S3 would send a similar request back to the context URL on S1.
At this point, the three systems are linked. S2 and S3 each know the context ID and context URL and have subscribed to the Context by sending their own URL's back to S1. At this point, all three systems can begin participating in the Federated Social Context.
Now, let's suppose that John, using his own application, creates a post for the project that Sally and Joe are both participating in. His server, S1, will store that locally then send a JSON Activity Document to each of the subscribed endpoints (S2 and S3). For example:
POST /.well-known/fsc/278c9ba29aadb0e96aa6d96edcfbd67d/0d519b6fafdbd6a4fa8ef678b4a5eb1f
HTTP/1.1
Host: example.org
Content-Type: application/json
{
"verb":"post",
"actor":
,
"object":
}
The posted activity will show up within each of Sally and Joe's own local systems.
If Sally, then, posts a comment, or posts her own item to the Social Context, her server, S2, would send a POST back to the Context URL, which would then be forwarded on to each of the other subscribed endpoints...
POST /api/context/1234abcd HTTP/1.1
Host: example.net
Authorization: bearer 123123123123
Content-Type: application/json
{
"verb":"post",
"actor":
,
"object":{"objectType":"note","content":"Thank you for inviting
me to this project"}
}
Suppose Sally then wishes to use some feature of her local system that currently does not exist within either of John or Joe's systems. For instance, assuming she's using some feature of Jive that is specific to that platform, but wishes to make contributions to the project that are available and accessible to both John and Joe. To do so, her system will use Embedded Experiences within the Activity posted to the Context URL. Both John and Joe's system, when it displays the Activity locally, will display the Embedded Experience, allowing features from individual vendor platforms to be shared across multiple, independent systems. Since it's done via Embedded Experiences, the originating system still maintains complete control over the content, access control, associated costs, etc.
So at this point, communication in the Federated Social Context is essentially a pub/sub model... the originating server (S1) becomes the central publishing hub for the context. The other participants, S2 and S3 are subscribers. They can contribute to the shared context by posting their own activity entries that are then distributed to everyone else.
If Sally or Joe wish to leave the context, they simply send an unsubscribe request back to the context URL.
If Sally or Joe wish to work in an offline mode rather than active pub/sub.. they can do so by sending a GET to the Context URL and receiving the current Activity Stream document showing all the recent activity occurring within the shared context.
The whole model is secured by OAuth, with all parties being authenticated to one another through their own respective OAuth providers.
Individually participating systems maintain control over their own contributions to the shared context, including the presentation and distribution of content to other members.
The model leverages capabilities that already exist within OpenSocial (Activity Streams, Embedded Experiences) but does not require that all participants implement full support for OpenSocial. In fact, the model is open to any system that would be capable, at a minimum, of using OAuth 2.0, Activity Streams and Embedded Experiences.
The system supports online and offline participation modes.
The system expands the concepts introduced by the "spaces proposal" to include multiple, independent systems to communicate and cooperate within shared social contexts.
The profile discovery model allows an OpenSocial system to manage relationships between individuals across independent systems, rather than limiting the social of an individual profiles social graph to a single local island, the social graph can span across multiple systems, regardless of whether those systems fully support OpenSocial.
I was able to build a working prototype of this in a day, which I plan to demonstrate at the upcoming face-to-face at the end of February.