XEP-: Social Relationships

Abstract:This specification defines an XMPP protocol extension for establishing, sharing, confirming and verifying social relationships between users. The protocol enables a user to establish social relationships (e.g. friend, colleague, member) with an other user, to expose (share) his established relationships with other users, to confirm that a relationship declared by another user is true, and to verify that a relationship declared by a user towards another user is indeed true. Each relationship can be assigned a fine grained privacy control: users can assign access control rules on a relationship per relationship basis. This protocol aims at providing a flexible platform for social relationships management in a decentralized social network, thus enabling all social network use cases related to relationships. This extension is part of the OneSocialWeb suite of XMPP extensions. The data format is inspired by the work of the XFN standard.
Author:Laurent Eschenauer
Copyright:© 2010 Vodafone Group R&D.
Status:
Type:
Version:0.2
Last Updated:2010-02-02


Table of Contents


1. Introduction
    1.1. Overview
2. Requirements
3. Glossary
4. Publisher Use Cases
    4.1. Setup a new relationship
    4.2. Confirm or decline a relationship
    4.3. Ignore a relationship
    4.4. Modify private element of a relationship
    4.5. Modify status of a relationship
    4.6. Delete a relationship
5. Reader Use Cases
    5.1. Query Relationships
    5.2. Verify a relationship
6. Application Use Cases
7. Data Model
    7.1. Schema
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 Social Relationships extension defined in this document addresses the requirement for establishing, sharing, confirming and verifying social relationships between entities. A relationship has a nature (e.g. friend, colleague, sibling, parent) which can imply properties of symmetry and transitivity. It can be unilateral or bilateral (= confirmed as true by the other party). The data model used in this extension is inspired by the XHTML Friends Networks standard.

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 establish, confirm, modify or delete a relationship with another user.

4.1 Setup a new relationship

An entity can setup a new relationship with another user by sending an IQ-set to the user bare JID, containing a <setup/> element with a <relationship/> child. The relationship syntax should conform to the relationship data model.

It should be however noted that:

In the following example, <romeo@montague.lit> wants to setup an "engaged" relationship with <juliet@capulet.lit>. Using his prefered social networking client, he visits Juliet's profile and requests a new relationship to be setup. He chooses the type, selects the visibility (he select 'Everyone' because he wants to whole world to see this) and when he clicks the Save button, his client sends the following:

Example 1. Entity setup a new relationship

<iq type='set'
    from='romeo@montague.lit/orchard'
    to='juliet@capulet.lit'
    id='osw1'>
  <setup xmlns="http://onesocialweb.org/spec/1.0/relations#setup">
    <relations xmlns="http://onesocialweb.org/spec/1.0/">
      <to>juliet@capulet.lit</to>
      <nature>http://onesocialweb.org/spec/1.0/relations/nature/engaged</nature>
      <comment>I love this girl so much !</comment>
      <message>Dear Juliet, let's say to the world that we are engaged !</message>
      <acl-rule>
          <acl-action permission="http://onesocialweb.org/spec/1.0/acl/permission/grant">
            http://onesocialweb.org/spec/1.0/acl/action/view</osw:acl-action>
          <acl-subject type="http://onesocialweb.org/spec/1.0/acl/subject/everyone"/>
      </acl-rule>
    </relations>
  </setup>
</iq>

    

Romeo's server intercept the request, validates it, store this new relationship locally as pending, adds some required fields to the payload, removes the fields that are private to Romeo and sends a notification to Juliet to inform her of this request.

Example 2. Server notifies remote user of new relation

<message from="romeo@montague.lit" type="headline" to="juliet@capulet.lit" >
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node='http://onesocialweb.org/spec/1.0/relations'>
      <item id='id="urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296'>
        <relation xmlns="http://onesocialweb.org/spec/1.0/">
	  <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
          <published>2010-01-13T12:40:51.292Z</published>
          <from>romeo@montague.lit</from>
          <to>juliet@capulet.lit</to>
          <nature>http://onesocialweb.org/spec/1.0/relations/nature/engaged</nature>
          <status>http://onesocialweb.org/spec/1.0/relations/status/requested</status>
          <message>Dear Juliet, let's say to the world that we are engaged !</message>
        </relation>
       </item>
     </items>
    </payload>
  </event>
</message>

    

Juliet's server processes the request. It can either auto accept it or mark it as pending, waiting for Juliet to actually confirm the notification. When the status of the relationship changes, it sends a notification to Romeo with a <relationship/> child. The relationship item MUST contain an <id/> element with the same id as the one used in the request.

Example 3. Server notifies remote user of relation status change

<message from="juliet@capulet.lit" type="headline" to="romeo@montague.lit" >
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node='http://onesocialweb.org/spec/1.0/relations'>
      <item id='id="urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296'>
        <relation xmlns="http://onesocialweb.org/spec/1.0/">
          <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
          <status>http://onesocialweb.org/spec/1.0/relations/status/pending</status>
        </relation>
      </item>
    </items>
  </event>
</message>

    

Upon receiving the update notification, Romeo's server updates the relationship status in the local data store and forwards the notification to Romeo's client.

4.2 Confirm or decline a relationship

Once a relationship request has been sent to Juliet, the relationship is in fact added in Juliet's collection of relationships. Therefore, confirming or declining a relationship is simply equivalent to modifying the status of a relationship, and maybe changing the visibility settings.

Following the previous use case, let's assume that Juliet wants to confirm the engaged relationship with Romeo but to make it visible only to her friends. Her client would send the following request to her server:

Example 4. User confirms a relationship

<iq type='set'
    from='juliet@capulet.lit/rose'
    to='romeo@montague.lit'
    id='osw-2'>
  <update xmlns="http://onesocialweb.org/protocol/0.1/relations#update">
    <relation xmlns="http://onesocialweb.org/spec/1.0/">
      <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
      <status>http://onesocialweb.org/spec/1.0/relations/status/confirmed</status>
      <acl-rule>
          <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/group">
            Friends
          </acl-subject>
      </acl-rule>
    </relation>
  </update>
</iq>

    

Juliet's server notifies Romeo's server of the change, making sure to first filter any private fields like the ACL ones.

Example 5. Local server notifies remote server of update

<message from="romeo@montague.lit" type="headline" to="juliet@capulet.lit" >
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node='http://onesocialweb.org/spec/1.0/relations'>
      <item id='id="urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296'>
        <relation xmlns="http://onesocialweb.org/spec/1.0/">
          <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
          <status>http://onesocialweb.org/spec/1.0/relations/status/confirmed</status>
        </relation>
      </item>
    </items>
  </event>
</message>

    

4.3 Ignore a relationship

In order to ignore a relationship, a user should simply ignore the request. The status of the relationship will stay marked as pending on both ends.

4.4 Modify private element of a relationship

A user can always update the private elements of a relationship (<comment/> and <acl-rule/>) by sending an IQ-set to his server containing an <update/> element with a <relationship/> child. The relationship item MUST contain the <id/> of the relationship that has to be edited.

In the following example, Juliet decides to change the visibility of her relationship with Romeo:

Example 6. User update a relationship

<iq type='set'
    from='juliet@capulet.lit/rose'
    to='capulet.lit'
    id='osw-3'>
  <update xmlns="http://onesocialweb.org/protocol/0.1/relations#update">
    <relation xmlns="http://onesocialweb.org/spec/1.0/">
      <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
      <status>http://onesocialweb.org/spec/1.0/relations/status/confirmed</status>
      <acl-rule>
          <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/group">
            Friends
          </acl-subject>
      </acl-rule>
    </relation>
  </update>
</iq>

    

4.5 Modify status of a relationship

Updating the status of a relationship is equivalent to (re)confirming the relationship with a different status.

4.6 Delete a relationship

Not yet implemented

5. Reader Use Cases

This section defines the use cases for and protocols to be used by any entity that wishes to query the relationships of another entity.

In all of the following use cases, the server MUST comply with the privacy settings attached to any relationship of the target entity before exposing it to another user.

5.1 Query Relationships

An entity can query the relationships of another entity by sending an IQ-get to the bare JID of the target entity containing a <query/> element. The server replies to this request with a list of relationships that the requesting entity is allowed to see.

It should be noted that:

In the following example, <romeo@montague.lit> wants to check the relationships of <juliet@capulet.lit>, just because he can be quite a jealous guy :-) He opens his preferred social networking client and type in Juliet's identifier in the navigation box. The client query for the relationships with the following request:

Example 7. User Query for Relationships

<iq type='get'
    from='romeo@montague.lit/orchard'
    to='juliet@capulet.lit'
    id='osw2'>
  <query xmlns="http://onesocialweb.org/protocol/0.1/relations#query">
  </query>
</iq>

To which Juliet's server replies with a list of existing relationships that Romeo is allowed to see:

Example 8. Server Reply to Relationships Query

<iq type='result'
    from='juliet@capulet.lit' 
    to='romeo@montague.lit/orchard'>
  <query xmlns="http://onesocialweb.org/protocol/0.1/relations#query">
    <relation xmlns="http://onesocialweb.org/spec/1.0/">
      <id>urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296</id>
      <published>2010-01-13T12:40:51.292Z</published>
      <from>romeo@montague.lit</from>
      <to>juliet@capulet.lit</to>
      <nature>http://onesocialweb.org/spec/1.0/relations/nature/engaged</nature>
      <status>http://onesocialweb.org/spec/1.0/relations/status/confirmed</status>
    </relations>
    <relations xmlns="http://onesocialweb.org/spec/1.0/relations">
      <id>urn:uuid:042D7D22-0760-11DF-97DC-8BA455D89593</id>
      <published>2010-01-16T15:23:10.252Z</published>
      <from>juliet@capulet.lit</from>
      <to>camilia@italy.lit</to>
      <nature>http://onesocialweb.org/spec/1.0/relations/nature/friend</nature>
      <status>http://onesocialweb.org/spec/1.0/relations/status/confirmed</status>
    </relation>
  </query>
</iq>

5.2 Verify a relationship

Because of the decentralized nature of the social web, a user could always claim that he has a confirmed relationship of a kind with another user. This use case enables any third party to verify if this claim is true, while not being able to abuse this protocol to extract information from a user

Not yet implemented

6. Application Use Cases

This section defines the use cases for and protocols to be used by any third party application that wishes to add/modify/delete relationships on behalf of a user. For example, a user could authorize the <robot@gmail.com/> entity to automaticaly add a relationship when a new email contact is added by the user.

//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 not found any data model for relationships that would fit our requirements, and have therefore opted to define our own, based on the thinking behind the XHTML Friends Network. We would be happy to review any proposal and align with existing standards meeting our requirements.

7.1 Schema

A relationship is defined as a link between two users (identified by their bare JID). It is identified by a Globaly Unique Identified. It is characterized by a nature. It can be mutually verified, meaning that the other end of the relationship confirms this relationship as being true.

8. Business Rules

OPTIONAL.

9. Implementation Notes

OPTIONAL.

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-02-02
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0030, XEP-0059
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
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


Appendix H: Revision History

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

Version 0.2 (2010-02-02)

Minor changes in namespace. This draft has not evolved at all yet.

(le)

Version 0.1 (2010-02-02)

First draft.

(le)

END