[OS3 Proposal] The Federated Social Context
James Snell
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. sa...@example.org,
j...@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.
sa...@example.org ==>
https://example.org/.well-known/fsc/278c9ba29aadb0e96aa6d96edcfbd67d
j...@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":{"displayName":"John"},
"object":{"objectType":"note","content":"Welcome to my project"}
}
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":{"displayName":"Sally"},
"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.
- James
iamahern
solving a a couple of problems and not how do I represent groups &
group owned content in OpenSocial.
I know there is more their, but the core problems this seems to
attempt to address are:
1. How do I represent people cross system
2. How do I aggregate events into a users home system / stream
3. How do I create EE / gadgets that have their OS data services tied
to their home server
4. How do I aggregate events from multiple systems into a single
stream
5. How do I maintain control of event authorization in the host system
...Others?
Some of the problems here are common to other things so it probably
makes sense to break apart.
(1, 2) This will be HARD to scale. Lets taking this mailing list and
the 50 or so orgs on it; that means each event needs to be published
50 times. Obviously mailing lists work and although you can make it
work in a prototype; for a production system you need to be able to
handle retry on fail; queue'ing; etc. There are such systems, but
there is a lot of machinery backing them.
(3) This is a common problem for all gadgets.
(4) Once a spaces concept is defined. If there is an endpoint to
publish, then the generating spaces aware system just publishes to
that endpoint. Is this different from today's AS model except with
the Spaces ID on it?
(5) So when an event is published to the stream, you just need the
client credential to always be specific to the viewer; which again
seems common to AS use cases and / or if gadgets are hosted on an
individuals Profile page. I don't want the gadget to show up if the
viewer is not authorized to see the content. If you look at the
Profile use case it leads to other cases where you would want an
'isAuthorized/authorizable' server endpoint to show / hide content
depending on the viewer. As above I'd split out the use cases though.
Probably just need numbers in the original post to make it easier to
see :)
Thanks,
-Mike
Laurent-Walter Goix
basis for this topic? and in general, to have this kind of concept
discussed/proposed within the W3C Federated Social Web Community
Group? i guess it would be valuable to get feedback from that
community to achieve a common solution.
walter
>
> read more »
James Snell
together into this... it's a bit early to begin floating it too
extensively but I wanted to get the ideas out on the table for
discussion. If we decide to pursue this at all that feedback would be
greatly valuable.
> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>