Federated Social Web Charter

The mission of the Federated Social Web Incubator Group is to provide a set of community-driven specifications and a test-case suite for a federated social web.

• End date 30th Nov 2011
• Confidentiality Proceedings are public
• Initial Chairs: Evan Prodromeu and Harry Halpin
• Initiating Members
  • DERI
  • Google
  • OpenLink
  • Vodafone
  • Mozilla?
• Usual Meeting Schedule Teleconferences: Monthly
• Face-to-face: Once Annually

Scope

As our social interactions increasingly become the central point of our communication using the Web, the need for a federated social web where any site, application, and device can easily join and share. In order for their to be massive uptake, the federated social web need to have a compelling experience for users. Furthermore, users would like to have the ability for these applications to respect the privacy of their social data in easy-to-understand and uniform ways.

The Federated Social Web Group's deliverables will primarily be a set of user stories with associated test-cases that build the core functionality of a federated social web and at least one architecture document. One input for this meta-architecture for the Social Web will be OStatus, which is an architecture combining Pubsubhubbub, WebFinger, ActivityStreams, and PortableContacts. However, other architectures be considered. The Federated Social Web Incubator Group will also strive to help mature the specifications that allow web developers to implement federated social web capabilities. These deliverables will apply to both social web-sites ran from the server-side but hopefully also to client-side environments such as desktop and mobile browsers.

Success Criteria

OStatus and, if necessary, any other architecture or specification will be clarified enough to be implemented easily enough to allow interoperability without taking away from innovation.

Each test-case will hopefully have three independent implementations and a clearly defined user-story that can be understood by ordinary users. A test harness should be designed that lets the test-cases be ran as much as possible in a semi-automated fashion.

Deliverables

The Federated Social Web Incubator Group will work on the following:

SWAT User-Stories and Test-Cases

An interoperable number of user stories and associated test-cases for a federated social web, with a focus on a compelling user experience. A strawman input document is available.

OStatus Specification

OStatus is one design pattern for the Federated Social Web. OStatus lets people on different social networks follow each other. It applies a group of related protocols (PubSubHubbub, ActivityStreams, Salmon, Portable Contacts, and Webfinger), and so is a minimal specification for distributed status updates, and may social applications can be modelled as status updates.

Other Deliverables

Other documents as necessary may be worked on such as:

• The various specifications that OStatus builds upon may also be clarified in process of developing the user-stories and test-cases.
• Best Practices documents to support developers when designing federated social web nodes and applications, including focus on user experience.
• Primer for users on federated social web use and benefits.
• Primer or Best Practices for privacy and security.

Milestones

Have a fairly substantial set of user-stories and test-cases with interoperable implementations within a year.

Dependencies and Liaisons

W3C Groups

Web Applications Working Group

This Working Group develops APIs for client-side development and for markup vocabularies for describing and controlling client-side application behavior.

HTML Working Group

This Working Group will maintain and produce incremental revisions to the HTML specification. There may be desire to have client-side browsers as part of the federated social web.

Device APIs and Policy Working Group

This group create client-side APIs that enable the development of Web Applications and Web Widgets that interact with devices services. Access to personal contact data and possibly privacy work through DAP APIs should be co-ordinated with the Federated Social Web Incubator Group.

External Groups

OStatus

OStatus is an architecture combining Pubsubhubbub, WebFinger, ActivityStreams, and PortableContacts. Currently no standards body.

Main specification: http://ostatus.org/sites/default/files/ostatus-1.0-draft-1-specification_0.html

• [LRDD] Hammer-Lahav, E., “Link-based Resource Descriptor Discovery,” March 2010.
• [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
• [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
• [RFC4685] Snell, J., “Atom Threading Extensions,” RFC 4685, September 2006 (TXT).
• [Webfinger] “the WebFinger protocol.”
• [activitiesinatom] Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft),” March 2010.
• [activityschema] Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Base Schema (Draft),” March 2010.
• [georss] “GeoRSS-Simple.”
• [poco] Smarr, J., “Portable Contacts 1.0 Draft C,” August 2008.
• [push] Fitzpatrick, B., Slatkin, B., and M. Atkins, “PubSubHubbub Core 0.3 -- Working Draft,” February 2010.
• [salmon] Panzer, J., “The Salmon Protocol,” February 2010.

OpenID v.Next/OpenID Connect Working Groups

This is the group responsible for OpenID-related standardization. Although OpenID is a moving target, the test-cases and specification should be compatible with OpenID. These upcoming specifications will be hosted by the OpenID Foundation.

Pubsubhubbub

Pubsubhubbub (PUSH) is a server-to-server publish/subscribe protocol as an extension to Atom and RSS. Servers compliant with PubSubHubbub can get near-instant notifications when a feed they're interested in is updated.

Specification: [1]

• [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104.
• [RFC2119] Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119.
• [RFC2606] Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” RFC 2606.
• [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616.
• [RFC2818] Rescorla, E., “HTTP Over TLS,” RFC 2818, May 2000 (TXT).
• [RFC3174] Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” RFC 3174, September 2001 (TXT).
• [RFC3986] Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 3986.
• [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287 (HTML).
• [RSS20] Winer, D., “RSS 2.0.”
• [W3C.REC-html401-19991224] Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).
• [XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe,” XSF XEP 0060.

ActivityStreams

ActivityStreams is an evolving format for syndicating social activities around the web '

Main Specification: http://activitystrea.ms/spec/1.0/atom-activity-01.html

Other related ActivityStreams specifications:

• Draft Activity Schema (List of Nouns/Verbs: http://activitystrea.ms/schema/1.0/activity-schema-01.html
• JSON ActivityStreams Specification: http://activitystrea.ms/head/json-activity.html
• Atom Media Specfication: http://martin.atkins.me.uk/specs/atommedia

From main specification:

• [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.
• [RFC3339] Klyne, G., “Date and Time on the Internet: Timestamps,” July 2002.
• [RFC3987] Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.
• [RFC4287] Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.
• [RFC4685] Snell, J., “Atom Threading Extensions,” September 2006.
• [RSS_2.0] Klyne, G., “Date and Time on the Internet: Timestamps,” July 2002.

Salmon Protocol

As updates and content flow in real time around the Web, conversations around the content are becoming increasingly fragmented into individual silos. Salmon aims to define a standard protocol for comments and annotations to swim upstream to original update sources -- and spawn more commentary in a virtuous cycle. It is compliant with the Open Web Foundation agreement.

Specification: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html

• [AABS] Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Base Schema (Draft).”
• [AAE] Atkins, M., Recordon, D., Messina, C., Keller, M., Steinberg, A., and R. Dolin, “Atom Activity Extensions (Draft).”
• [Crosspost] Atkins, M., “Atom Cross-posting Extensions I-D.”
• [LRDD] Eran, E., “LRDD: Link-based Resource Descriptor Discovery.”
• [MagicSig] Panzer, J. and B. Laurie, “Magic Signatures.”
• [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
• [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
• [RFC4685] Snell, J., “Atom Threading Extensions,” RFC 4685, September 2006 (TXT).
• [Tombstones] Snell, J., “The Atom "deleted-entry" Element.”
• [WebLinking] Nottingham, M., “Web Linking I-D, draft 7.”
• [Webfinger] Fitzpatrick, B., Hammer-Lahav, E., Cook, B., Panzer, J., and J. Gregorio, “The Webfinger Protocol.”
• [XRD] Hammer-Lahav, E. and W. Norris, “Extensible Resource Descriptor (XRD) Version 1.0, Working Draft 13.”

Portable Contacts

The goal of [Portable Contacts http://portablecontacts.net/] is to make it easier for developers to give their users a secure way to access the address books and friends lists they have built up all over the web.

Specification: http://portablecontacts.net/draft-spec.html

• [OAuth Core 1.0] OAuth Core Workgroup, "OAuth Core 1.0."
• [OAuth Discovery] Eran Hammer-Lahav, E., "OAuth Discovery 1.0."
• [OpenSearch] Clinton, D., "OpenSearch 1.1."
• [OpenSocial] Panzer, J., "OpenSocial 0.8.1 RESTful Protocol Specification."
• [RFC2119] Bradner, B., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119.
• [RFC2425] Howes, T., "A MIME Content-Type for Directory Information," RFC 2425.
• [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names," RFC 2606.
• [RFC2616] Fielding, R., "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2616.
• [RFC2617] Franks, J., "HTTP Authentication: Basic and Digest Access Authentication," RFC 2617.
• [XRDS-Simple] Hammer-Lahav, E., "XRDS-Simple 1.0."
• [google-sgnodemapper] Fitzpatrick, B., "Social Graph Node Mapper."

Webfinger

WebFinger is about making email addresses more valuable, by letting people attach public metadata to them.

Specification: http://tools.ietf.org/html/draft-hammer-webfinger-00

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
• [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

Participation

To be successful, the Incubator Group is expected to have 10 or more active participants for its duration.

The group welcomes as Federated Social Web Group members those involved in an implementation that implements the SWAT test-cases.

The group will encourages questions and comments on its public mailing lists, as described in Communication.

Communication

Teleconferences will be held once a week (@@or as-needed or once a month?) to track the progress of SWAT. Most teleconferences will focus on discussion of particular user-stories of test-cases,

This group primarily conducts its work on the public mailing list public-federated-social-web@w3.org (archive) (@@or somewhere else?). The public is invited to post messages to this list.

Information about the group (deliverables, participants, teleconferences, etc.) is available from the Federated Social Web Group home page.

Decision Policy

As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Incubator Group provides an opportunity to share perspectives on the topic addressed by this charter. W3C reminds Incubator Group participants of their obligation to comply with patent disclosure obligations as set out in Section 6 of the W3C Patent Policy. While the Incubator Group does not produce Recommendation-track documents, when Incubator Group participants review Recommendation-track specifications from Working Groups, the patent disclosure obligations do apply.

Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.