Warning:
This wiki has been archived and is now read-only.

OStatusCharter

From Social Web XG Wiki
Jump to: navigation, search

Open high-level questions:

  • Should it be a community group or a working group? Or Incubator Group? Working Group means full-scale W3C Royalty-Free patent policy, but it also means a strict schedule, and we could probably aim for a HTML5-style open membership, but this may require a month or two for approval at the W3C. Incubator Group has no patent policy and can have open members, but runs only for a year usually, but we could start in a few days. Community Groups run indefinitely and have open membership, but the model may not launch till after the next AC Meeting at the beginning of November.
  • Who would the main backing members be? Vodafone? Status.Net? Google? Facebook? Yahoo? Could we get browser vendors (Opera, Mozilla, Chrome, even IE) to be nodes in a federated social network?
  • the main task should be the expansion of SWAT tests obviously. But might be useful to get some of the specs hammered out in the process, as well as easy-to-use developer and even user guide.
  • What tech resources would the group want? Would the group be happy to stay on Google Groups, or move to a W3C list? Ditto with the wiki.
  • Privacy is off-the-table right now, but should we think about enabling privacy in the designred.

Federated Social Web Charter

The mission of the Federated Social Web @@Community/Incubator/Working Group, part of the W3C Technology and Society Domain, is to provide a set of community-driven specifications and a test-case suite for a federated (@@ and privacy-enhanced) social web.

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 social data has become widespread. @@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. The Federated Social Web @@ 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 as well as client-side environments such as desktop and mobile browsers.

Success Criteria

Each test-case is expected to 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.

@@Also, as much IP as can be collected (i.e. via agreement to W3C Royalty-Free Patent Policy if WG, otherwise we can stick to OWF re individuals)

Out of Scope

@@Privacy? Should we delete those sections?

Deliverables

The Federated Social Web @@ 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. Currently strawman

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.

@@Of course, any other spec that was part of the Federated Social Web would be invited to be a W3C specification, although it would have to go through the normal IP if we decide to be a Working Group rather than a Community Group/Incubator Group.

Other Deliverables

Other @@non-normative? documents may be created such as:

  • Best Practices documents to support developers when designing federated social web nodes and applications
  • Primer for users on federated social web use and benefits.
  • Primer or Best Practices for privacy and security. (@@maybe this is a better option than building privacy into the test-cases?)


Milestones

@@Again, do folks want a schedule? Or should we set a strict deadline and say "finish swat0 in a year, and then get the IP sorted on the specs, and then move to Swat1!"

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 social data through DAP APIs should be co-ordinated with the Federated Social Web @@ Group.

External Groups

OStatus dependencies:

  • [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.

Pubsubhubbub

Pubsubhubbub (PUSH) is a simple, open, server-to-server web-hook-based pubsub (publish/subscribe) protocol as an extension to Atom and RSS. Parties (servers) speaking the PubSubHubbub protocol can get near-instant notifications (via webhook callbacks) when a topic (feed URL) they're interested in is updated.

Specification: http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html] (@@Seems to be going to IETF)

  • [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:

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.

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. @@Check on status of VCard 4.0 to see discrepancies...

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 @@Seems to be aimed at IETF but expired..

  • [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.

@@Very incomplete - it's very much dependent on XRD, which is supports XRIs, which are patent-policy bad news!

Participation

To be successful, the @@ Group is expected to have 10 or more active participants for its duration. The Chairs and specification Editors are expected to contribute one day per week towards the Working Group. There is no minimum requirement for other Participants.

The @@ Group members will be expected to be involved in an implementation that implements the SWAT test-cases.

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

@@REMOVE? The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.

Communication

Teleconferences will be held once a week (@@or as-needed?) 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). 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.

@@REMOVE: The group will use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Information about the group (for example, details about deliverables, issues, actions, status, participants) will be available from the Web Performance Working 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

@@Again, this depends on Incubator Group/Community Group or Working Group.

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

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

This charter for the Federated Social Web @@Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Retrieved from "https://www.w3.org/2005/Incubator/socialweb/wiki/index.php?title=OStatusCharter&oldid=983"