XEP-: Activity Stream over XMPP

Abstract:This specification defines an XMPP protocol extension for sharing, archiving and retrieving generic social networking activities. It supports simple activities like blogging, microblogging, bookmarking, sharing pictures, etc. and also supports custom activities. The activity publishing supports fine grained privacy control: users can assign access control rules on a per activity basis. This protocol aims at providing a flexible platform for social activities management in a decentralized social network, thus enabling all social network use cases related to sharing of activities. This extension is part of the OneSocialWeb suite of XMPP extensions. The data format for Activities closely follows the Activitystrea.ms standard with a few additions/clarifications. The protocol flow is based on XEP-0277 (microblogging over XMPP) and is therefore using XEP-0163 (PEP).
Author:Laurent Eschenauer
Copyright:© 2010 Vodafone Group R&D.
Status:
Type:
Version:0.2
Last Updated:2010-04-09


Table of Contents


1. Introduction
    1.1. Overview
2. Requirements
3. Glossary
4. Publisher Use Cases
    4.1. Publish New Activity
    4.2. Update Activity
    4.3. Delete Activity
5. Subscriber Use Cases
    5.1. Query Latest Activities
    5.2. Paginate Through Activities
    5.3. Filter Activities
    5.4. Search Activities
    5.5. Combination of Search, Filter and Paginate
6. Application Use Cases
7. Data Model
    7.1. Implementation details
    7.2. Extensions
       7.2.1. Access control
8. Business Rules
9. Implementation Notes
10. Accessibility Considerations
11. Internationalization Considerations
12. Security Considerations
13. IANA Considerations
14. XMPP Registrar Considerations
15. XML Schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

1.1 Overview

The XMPP Extension defined in this document is part of a collection of XMPP extensions that forms the OneSocialWeb (OSW) protocol. The purpose of the OneSocialWeb protocol is to enable free, open, and decentralized social applications on the web. In particular, this protocol can be used to turn any XMPP server into a full fledged social network, participating in the OneSocialWeb federation. The suite of extension covers all the usual social networking use cases such as user profiles, relationships, activity streams and third party applications. In addition, it provides support for fine grained access control, realtime notification and collaboration.

The Activity Stream extension defined in this document addresses the requirement for sharing, archiving and retrieving generic activities performed by a user in social applications. It leverages the Activitystrea.ms standard as a data model for activities, and provides some extensions to address specific needs such as fine grained privacy. The protocol flow is based on XEP-0277 (microblogging over XMPP) and is therefore using XEP-0163 (PEP).

2. Requirements

STRONGLY RECOMMENDED.

3. Glossary

OPTIONAL.

4. Publisher Use Cases

This section defines the use cases for and protocols to be used by any entity that wishes to manipulate its own activities, stored at its server. In particular to publish, update or delete activities.

These use cases are the same as the PubSub publisher use cases [1] in a PEP context, towards the user urn:xmpp:microblog:0 PEP node. We reproduce a simplified version in the next sections as an introduction but in case of doubts, better to refer to the Publish-Subscribe [2] and Personal Eventing Protocol [3] specifications.

4.1 Publish New Activity

An entity can publish an activity to its server by sending a pubsub <publish/> request to the user bare JID and the PEP node "urn:xmpp:microblog:0" with an <entry/> child. The entry syntax should conform to the activity data model.

It should be however noted that:

In the following example, <hamlet@denmark.lit> wants to share with his community his latest thoughts on life via a standard social networking "status update" (e.g. tweet). He uses his favorite social web client and publishes the following:

Example 1. User Publishes a New Status Updated Activity

<iq type='set'
    from='hamlet@denmark.lit/snsclient'
    to='hamlet@denmark.lit'
    id='osw1'>
 <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:microblog:0'>
      <item>
        <entry xmlns="http://www.w3.org/2005/Atom" 
               xmlns:activity="http://activitystrea.ms/spec/1.0/" 
               xmlns:osw="http://onesocialweb.org/spec/1.0/">
          <title>to be or not to be ?</title>
          <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
          <activity:object>
            <activity:object-type>http://onesocialweb.org/spec/1.0/object/status</activity:object-type>
            <content type="text/plain">to be or not to be ?</content>
          </activity:object>
          <osw:acl-rule>
            <osw:acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
              http://onesocialweb.org/spec/1.0/acl/action/view
            </osw:acl-action>
            <osw:acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/everyone"/>
          </osw:acl-rule>
        </entry>
      </item>
    </publish>
  </pubsub>
</iq>
    

In this other example, <hamlet@denmark.lit> shares a picture with users in his roster group 'Family'.

Example 2. User shares a picture with members of his family roster group

<iq type='set'
    from='hamlet@denmark.lit/snsclient'
    to='hamlet@denmark.lit'
    id='osw2'>
 <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:microblog:0'>
      <item>
        <entry xmlns="http://www.w3.org/2005/Atom" 
               xmlns:activity="http://activitystrea.ms/spec/1.0/" 
               xmlns:osw="http://onesocialweb.org/spec/1.0/">
          <title>sunrise in Denmark</title>
          <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
          <activity:object>
            <activity:object-type>http://onesocialweb.org/spec/1.0/object/picture</activity:object-type>
            <content type="text/plain">OMG! Just saw the ghost of my father. Check out this picture</content>
    	[... MORE CONTENT OF AN ACTIVITY ENTRY FOR A PICTURE ...]
          </activity:object>
          <osw:acl-rule>
            <osw:acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
              http://onesocialweb.org/spec/1.0/acl/action/view
            </osw:acl-action>
            <osw:acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/group">
		Family
            </osw:acl-subject>
          </osw:acl-rule>
      </entry>
    </item>
   </publish>
 </pubsub>
</iq>
    

4.2 Update Activity

To update an item, an entity should simply publish it again, but this time also include the item id as an attribute of the <item /> element.

Example 3. User updates an activity

<iq type='set'
    from='hamlet@denmark.lit/snsclient'
    to='hamlet@denmark.lit'
    id='osw4'>
 <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:microblog:0'>
      <item id='urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296'>
        <entry xmlns="http://www.w3.org/2005/Atom" 
               xmlns:activity="http://activitystrea.ms/spec/1.0/" 
               xmlns:osw="http://onesocialweb.org/spec/1.0/">
          <title>to be or not to be ? That is the question !</title>
          <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
          <activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
          <activity:object>
            <activity:object-type>http://onesocialweb.org/spec/1.0/object/status</activity:object-type>
            <content type="text/plain">to be or not to be ? That is the question !</content>
          </activity:object>
          <osw:acl-rule>
            <osw:acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
              http://onesocialweb.org/spec/1.0/acl/action/view
            </osw:acl-action>
            <osw:acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/everyone"/>
          </osw:acl-rule>
        </entry>
      </item>
    </publish>
  </pubsub>
</iq>
    

4.3 Delete Activity

An entity can delete an activity from its server by sending a pubsub <retract /> request containing an <item /> child with the item id to retract as an attribute.

Example 4. User delete an activity

<iq type='set'
    from='hamlet@denmark.lit/snsclient'
    to='hamlet@denmark.lit'
    id='osw3'>
 <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <retract node='urn:xmpp:microblog:0'>
      <item id='urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296' />
    </retract>
 </pubsub>
</iq>
    

5. Subscriber Use Cases

This section defines the use cases for and protocols to be used by any entity that wishes to query the activities published by another entity. In particular, an entity can paginate through the archived activities, filter them, or search them.

These use cases are the same as the PubSub subscriber use cases [4] in a PEP context, towards the user urn:xmpp:microblog:0 PEP node. We reproduce a simplified version in the next sections as an introduction but in case of doubts, better to refer to the Publish-Subscribe [5] and Personal Eventing Protocol [6] specifications.

In all of the following use cases, the server MUST comply with the privacy settings attached to the activity.

5.1 Query Latest Activities

An entity can query the for the latest activities of another entity by sending an <item /> pubsub request to the microblogging PEP node of the target user. The server replies to this request with the latest activities. If a large number of activities is available, the answer SHOULD comply with Result Set Management [7].

As an example, we have the entity, <othello@venice.lit> wondering what <hamlet@denmark.lit> latest thoughts are and deciding to look at Hamlet's activities using his favorite social networking client. The client will therefore send the following request:

Example 5. User Request Latest Activities of Another User

<iq type='get'
    from='othello@venice.lit/snsclient'
    to='hamlet@denmark.lit'
    id='osw2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:microblog:0'/>
  </pubsub>
</iq>
    

To which Hamlet's server replies with all the activities published by Hamlet and which can be seen by Othello. Since Hamlet has published only two activities that can be seen by Othello, there is no need to use Result Management.

Example 6. Service Reply With Latest Activities

<iq type="result" 
    from='hamlet@denmark.lit'
    to='othello@venice.lit/snsclient'
    id='osw2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='urn:xmpp:microblog:0'>
      <item id='urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296'>
        <entry xmlns="http://www.w3.org/2005/Atom"> 
          <published>2010-01-13T12:40:51.292Z</published>
          <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
          <title>to be or not to be ?</title>
          [ ... ENTRY DETAILS ... ]
        </entry>
      </item>
      <item id='urn:uuid:c9b8df4a-440a-40ef-86ac-0f6dcf68525e'>   
        <entry xmlns="http://www.w3.org/2005/Atom">
          <id>urn:uuid:c9b8df4a-440a-40ef-86ac-0f6dcf68525e</id>
          <published>2009-12-16T12:06:13.000Z</published>
          <title>What is the question ?</title>
          [... ENTRY DETAILS ...]
        </entry>
      </item>
  </query>
</iq>
    

5.2 Paginate Through Activities

[TODO: Simple example using result set management]

5.3 Filter Activities

[TODO: How far do we want to go ? Basic filtering by activity verb and object type ? Allow for more specific rules supporting comparators etc... almost replicating a full blown SQL ? We need to strike a balance between filtering on server and in the client.]

5.4 Search Activities

[TODO: Similar and linked to previous item: how far to go ?]

5.5 Combination of Search, Filter and Paginate

[TODO: Depends on decision for previous points

6. Application Use Cases

This section defines the use cases for and protocols to be used by any third party application thar wishes to publish activities on behalf of a user. For example, a user could authorize the <app@bookmarker.com/> entity to post activities of type post with an object of type bookmark, on his behalf.

[TODO: I wonder if this should be here, or managed at a more higher level (a broad delegation framework ?). Well.. we are far from tackling these problems anyway].

7. Data Model

We have chosen to use the activitystrea.ms standard as data model for activities. In this section, we precise some implementation details and extensions.

7.1 Implementation details

7.2 Extensions

7.2.1 Access control

This section describes a generic schema for describing access control rules in XML. It is simplistic and should be evolved to a broader access control language to be used across various XMPP specifications. This could be the base of a new kind of PubSub node, where access control is managed at an item level instead than at the node level.

Access control is defined through a set of rules, each rule containing a list of actions and permissions associated with a list of subjects. Any user matching at least one subject element of rule is authorized (or denied) the corresponding actions (depending if the permission assigned is Grant or Deny).

TODO: This all section will soon be moved in its own spec and will be detailed and rewritten.

Example 7. Read access to everyone

<acl-rule xmlns="http://onesocialweb.org/spec/1.0/">
 <acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
   http://onesocialweb.org/spec/1.0/acl/action/view
 </acl-action>
 <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/everyone"/>
</acl-rule>
    

Example 8. Read access to everyone and update access to hamlet@denmark.lit and othelo@venice.lit

<acl-rule xmlns="http://onesocialweb.org/spec/1.0/">
 <acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
   http://onesocialweb.org/spec/1.0/acl/action/view
 </acl-action>
 <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/everyone"/>
</acl-rule>
<acl-rule xmlns="http://onesocialweb.org/spec/1.0/">
  <acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
    http://onesocialweb.org/spec/1.0/acl/action/update
  </acl-action>
  <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/user">
    hamlet@denmark.lit
  </acl-subject>
  <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/user">
    othelo@venice.lit
  </acl-subject>
</acl-rule>
    

8. Business Rules

OPTIONAL.

9. Implementation Notes

A onesocialweb client should support operating towards a non-onesocialweb server that supports generic PEP. Such a server won't support extensions like access control, or specific queries (e.g. filtering on activity types), but would still be able to support most of the flow. The client will have to discover server capibilities through disco (//TODO this is yet to be properly defined and documented) and adapt the user experience accordingly.

10. Accessibility Considerations

OPTIONAL.

11. Internationalization Considerations

OPTIONAL.

12. Security Considerations

REQUIRED.

13. IANA Considerations

REQUIRED.

14. XMPP Registrar Considerations

REQUIRED.

15. XML Schema

REQUIRED for protocol specifications.


Appendices


Appendix A: Document Information

Series: XEP
Number:
Publisher: XMPP Standards Foundation
Status:
Type:
Version: 0.2
Last Updated: 2010-04-09
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0030, XEP-0059, XEP-0060, XEP-0163, XEP-0277
Supersedes: None
Superseded By: None
Short Name:
Source Control: HTML  RSS


Appendix B: Author Information

Laurent Eschenauer

Email: laurent.eschenauer@vodafone.com
JabberID:


Appendix C: Legal Notices


Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. Detailed in http://xmpp.org/extensions/xep-0060.html#publisher-publish.

2. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

3. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

4. Detailed in http://xmpp.org/extensions/xep-0060.html#subscriber-subscribe.

5. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

6. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

7. XEP-0059: Result Set Management <http://xmpp.org/extensions/xep-0059.html>.


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.2 (2010-04-09)

Evolved to a PubSub approach using XEP-0277.

(le)

Version 0.0.1 (2010-01-25)

First draft.

(le)

END