CloudServices/Presence

Last updated: 2013/11/21

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Presence

Service Overview

Mozilla Presence is a proposed Cloud Service conceived by the Cloud Services team's Tarek Ziade for FirefoxOS.

Mozilla Presence tracks Internet connectivity status as online or offline for each Firefox Account user's Firefox OS devices. Firefox OS Web Apps may request permission to access this status information on behalf of their publisher, who may then in turn poll the Mozilla Presence service and thus push (using SimplePush) timely messages to the Web App.

User Stories As a FirefoxOS Web App user, I want my....

Publisher Stories As a FirefoxOS Web App publisher, I want...

FirefoxOS Team Contacts TBD

Architectural Overview

There are two levels of presence:

1/ app-level presence

• online: you are connected in the app, and using it
• offline: you are disconnected from the app

2/ device-level presence.

• online : you are using your FXOS phone or your desktop browser
• offline: you are not on your FXOS phone or your browser

Sometimes you might be online in 1/ or 2/ and not wishing other users to know about it. And you also might want to appear online for app B but not for app C.

1/ is solved by every application. they all have their ad-hoc system, their social graph, rosters, contacts, etc. Large social networks don't care as much about 2/ because they would prefer you to use *only* their application for talking to your friends. By solving 2/, we can enable non-dominant social/communication applications to get useful presence information they can act on.

Mozilla Presence acts as a trusted intermediary between the user's device (solving 2/) and the applications the user has allowed to see their presence, as well as a short-lived notification system for applications to engage available users.

Channel communication overview:

Project Contacts

Principal Point of Contact - Tarek Ziadé tarek@mozilla.com

IRC - #presence-wg

Mailing list - https://mail.mozilla.org/pipermail/wg-presence/ - wg-presence@mozilla.org

Goals

Desktop/phone UI for users to:

• see at a glance and manage what applications they granted presence access to.
• see lively notifications and act on them or ignore them.
• manage how much idling is considered to be 'online' vs. 'away' vs. 'offline'

Mozilla Cloud Services run system that:

• allows a user to authorize an AppService access to the users presence
• sends notifications to the users device that they can act on
• sends user presence updates to authorized AppServices

Note: Lively notifications are different than SimplePush style Notifications in that they can require immediate action else they'll become stale, like a missed phone call.

The project will be a success if an application registered with Mozilla Cloud Services is able to reach out to users that are "online" (active on their phone or desktop but with the app not running) via Mozilla Presence.

Terminology

AppDeveloper

A developer that creates applications which may or may not have server-backed resources.

AppService

An Internet-accessible server that an application talks to. For example, Facebook's locally installed application talks to Facebook's API server to get data. The Facebook API server in that case is the AppService as it acts as a service to the application.

Application

A website application that might run locally on a device with or without needing to talk to an AppService.

FxAID

A Firefox Accounts user ID.

Device Presence Channel

A channel of communications between a phone/browser device and Mozilla Presence that carries live notifications from Presence and presence data to Presence.

AppService Presence Channel

A channel of communication between Mozilla Presence and an AppService that carries presence updates for users sharing their presence with the AppService and live notifications from the AppService to be delivered to a PUID.

LiveNotification

A live notification is an alert requiring a response within a set period of time (5 seconds up to several minutes) before its considered 'missed' and stored on the device separately to indicate it can no longer be acknowledged. A response is considered acknowledgement and switches the user to the appropriate application to act on the LiveNotification.

Presence

For our purposes the definition of presence definined by XMPP also applies, but in our case 'contacts' happen to be AppServices that the presence is broadcast to. See http://xmpp.org/rfcs/rfc6121.html#presence-fundamentals

PUID

A Presence Unique Identifier. Every AppService authorized by a user to see presence updates will be assigned a PUID that it should store and associate with the user (who may or may not be logged into the application).

Use Cases

Chat Room (=IRC Channel)

A chat room app let people talk with each other on the same web page. You connect to the system using Persona and you avatar appears on the page to other users. You can add contacts in that app.

People see you messages in realtime. It's built using whatever chat technology (BOSH/XMPP, plain websockets)

Before Mozilla Presence:

• a user appears as present (or busy or idling etc..) in the chat room when she's connected to the app and uses it
• a user that is not currently using the app (perhaps because FFOS killed that app due to constrained device resouces) appears offline.
• if the application wants to reach an offline user, it does not really know if the user is offline at the device level or just the app level.

With Mozilla Presence

• a user runs the Presence service and let it know when he's offline/online at the device level (desktop browser: a social API sidebar, FXOS: some background service)
• the user set permissions: "yes the chat app can get my presence updates"
• the user then can use the chat app independantly from the presence thing - or not having it running at some point at all
• the chat app interacts with the presence server: it gets a stream of presence update from the presence server only if the user authorized it
• the chat app can notify a user that another user pinged him in the room

Resources:

• Demo (without the app permission dance yet): https://vimeo.com/79394330
• Prototype repo https://github.com/mozilla-services/presence-chatroom

Facebook

Jeff wants to appear online on Facebook (he's already determined on Facebook who can see him, etc).

He's already installed the Facebook app on his FFOS phone, he goes to the Settings and touch, "Authorize Presence", his screen loads a doorhanger (provided by Mozilla Presence) asking if he wants to authorize the app.

Jeff clicks "Yes" on the doorhanger page, and the Facebook app waits while Facebook recieves the redirect, stores his UID, and closes the doorhanger (and likely needs to do something else to register this with the device so that it will appear in the Presence Settings page).

The next day, Jeff wakes up, and goes to check his e-mail on his phone. Upon seeing his idle drop, the phone's simple-push client (which is always running) includes an 'O' in its next PING to simplepush to indicate the user is now online. Mozilla Presence gets notified of this and acts on it to batch the status change to Facebook. The batch of updates goes to Facebook including Jeff's, so Facebook knows that Jeff is now online, and updates its database indicating this.

Jeff's friend Marsha goes to Facebook to see if any of her friends are online. Marsha sees that Jeff is now online and sends a chat request. Facebook uses SimplePush to notify Jeff of the chat request. Jeff sees the chat request

AppMaker

Sue has signed up to be an appmaker tutor -- Bob is a new appmaker teacher, and is stuck in a workshop, Bob wants to know which of the tutors are available to help w/ a togetherJS session

Sue is an appmaker expert. She previously authorized AppMaker to see her Online Presence - as Jeff did in with Facebook in the previous story. She also configured her notifications so any message coming from AppMaker when she's online would display a message on her screen and let her start the app.

Bob is building a cool new application with his class in AppMaker and would like some input from someone. Appmaker maintains a mapping of which helpers are appropriate for which users (e.g. by language skills). He's currently working in AppMaker from his FFOS Phone and sees that Sue is online.

Bob clicks on Sue's name in his contact lists and hit "invite Sue for peer design session". AppMaker sends a notification to Sue using the Simple Push service.

Sues gets the notification instantly on her phone via her simple-push client and joins Bob on the design page.

AppMaker uses Together.js so Bob and Sue can interact live on the page.

Support

(This is about a tentative and unnamed Firefox OS support tool.)

Maria is a Mozillian who wants to helpful to other Firefox OS users. She signs up with a support application (an application that Mozilla creates). She indicates what she knows about, and what languages she speaks.

Javier wants to activate developer mode on his phone, but can't find the right setting. He goes into Help > Live Support. The phone sends a request to the support app: someone wants support with Settings in es-MX. The application looks in its database of contributors to see who has the appropriate expertise (and language) to help him, and who is online. Among the pool of possible people it selects Maria, and pings her to see if she can provide support. If she doesn't respond then another person is selected from the pool (or maybe many people are asked at once), and if someone else helps Javier then Maria is notified that her help is no longer needed.

Note that Maria would be participating under an alias specific to the support application (though not anonymous), and she will not be fielding support requests all the time (e.g., she may not provide support at work, only after hours).

Wikipedia

(This comes from conversations about TogetherJS and Wikipedia)

Some questions that might be nice to answer with a presence service:

• Is there someone actively working on this page (or its related Talk/etc pages) right now?
• Is there someone ready to offer X help at this moment? (X examples: editing help, template authoring, mediate disputes)
• Given a community of interest (people interested in baseball, admins, etc):
  • Who is around?
  • What are they doing? (E.g., editing pages, hanging out in a discussion, etc; each person would opt in to publicizing this information to other people.)

Talkilla

XXX

Chatspace

Jen is building https://github.com/mozilla/chatspaces - we should investigate how presence fits there

SUMO

XXX See with Lloyd about the user story there (sumo experts summoned etc)

FAQ

To help people get up to speed faster and prevent backtracking, commonly asked questions by those getting involved are listed here with an answer.

Is this going to use XMPP?

It quite possibly will! However, its useful to remember that Mozilla Presence is in very early stages at this moment. Worrying about the exact implementation is a detail that we're not addressing yet as we build some prototypes to test ideas out and prove the overall concept is worthwhile.

Shouldn't Mozilla have a way for me to see my contacts online?

Nowadays, peoples' personal connections are spread across multiple online services (Facebook, Google+, Skype, etc). These services usually already have done the work of ensuring both people want to see each other's presence and have ways to facilitate a conversation. All they need is a way to be aware of a users presence when their app might be closed or suspended (on a phone). By serving as the underlying plumbing notifying AppService's when users are online, Mozilla Presence avoids having to try and change users expectations about where their 'friends' are and can facilitate new social interaction applications that need presence data.

Requirements

• List of requirements

Documents so far

Services Presence Etherpad

Identity Presence Etherpad

Meetings

We try to meet every Thursday at 10:00 Pacific Time

For mozilla employees, we meet in the "Services" vidyo room, and use IRC channel #presence-wg (irc.mozilla.org)

For participants outside of mozilla, you can call into the meeting using the following numbers:

• Phone (US/Intl): 650 903 0800 x92 Conf: 98616#
• Phone (Toronto): 416 848 3114 x92 Conf: 98616#
• Phone (US): 800 707 2533 (pin 369) Conf: 98616#

Please mute yourself with '* 1' upon joining to prevent needless noise and feedback. You can unmute yourself with '* 1' again to speak.

Meeting Notes

Services/Roadmaps/Presence/Meetings/notes_20131014

Services/Roadmaps/Presence/Meetings/notes_20131031

Design

Points of Contact

Services Engineers:

• Ben Bangert bbangert@mozilla.com
• Tarek Ziadé tarek@mozilla.com

Repository: https://github.com/mozilla-services/presence

General Overview

The Presence service has several functions:

1. let a user update her online status
2. let a developer register an application
3. let a user manages applications permissions
4. let an application receive status updates
5. let an application send a live notification and a user receive it.

1. Online status updates

Mozilla Presence provides a web socket endpoint at ws://presence.services.mozilla.com/presence

The user may connect to the socket using a valid Persona assertion, and send status updates. The data must be sent in JSON.

Example:

   {'email': 'tarek@mozilla.com',
    'assertion': 'valid persona assertion',
    'status': 'online'}

The status value must be one of "online", "offline" or "unavailable"

For every status received, the server sends back an ACK message.

Example:

  {'result': 'OK'}

In case of an error, the server may send back an extra 'errno' field with an error code (codes to be documented) and an optional 'error' message.

Example:

  {'result': 'KO', 'errno': 34, 'error': 'Invalid assertion'}

The user can send as many updates as it wants, but the server can ask it to slow down with a specific error code (codes to be documented)

The server or the user can disconnect from the socket at any time and for any reason. The number of socket connections is limited to one connection per device and per email.

2. Applications registration

An App developer can register a new application into Mozilla Presence

An application is defined by:

• a domain
• an email
• a name
• a description

Registering a new application is done in 3 steps

1. validation of the domain ownership
2. attribution of a unique application ID
3. activation of presence notifications

Domain Ownership Validation

Mozilla Presence provides a web page at https://presence.mozilla.com/myapps where an application developer can connect by logging with her persona account.

Once logged in, the developer can fill a form with a domain, name and description of the application to register.

Mozilla Presence generates a unique key of 1024 characters, the developer needs to place in this URL: http://<domain>/__presence in a plain/text file that can be reached pubicly.

Once the key is placed, the developer can hit a Verify button. Mozilla Presence will then visit http://<domain>/__presence to verify that the domain is owned by the developer.

Application ID

Once the domain has been verified, Mozilla Presence generates a unique id for the application, and displays an entry point the developer will need to visit to get status updates.

The entry point is in the form of ws://<node>.presence.mozilla.com/<appid> and is a web socket the developer's application may connect to, in order to receive status updates.

Activation of presence notifications

To activate the status update stream, the app developer needs to visit https://presence.mozilla.com/myapps and click on the Activate button located besides the application name (a developer may have several apps.)

By clicking on Activate, an API key is generated for the application and displayed besides the application. An API key is a string of 1024 chars.

This API key has to be used by the application in order to get status updates.

Getting status updates is done by connecting to the websocket located at ws://<node>.presence.mozilla.com/<appid> with the API key.

Example:

 {'key': 'XXX'}

Once connected, the application will receive status updated as they happen, in the form of a list. Each element is composed of an e-mail and a status.

Example:

 [{'UID': 2123131, 'status': 'online'},
  {'UID': 12345, 'status': 'offline'}
 ]

Where UID is a user identifier as described in the next section.

3. Applications permissions

Granting presence access requires user interaction to indicate to Mozilla Presence that the user wants an AppService to see their presence information. In the event that the user might have multiple identities or profiles on a single AppService, a user-meaningful string should be included in the authorization request to Mozilla Presence.

Here's what a users interaction with an application to grant it presence might look like:

The following steps occur in this flow:

1. User clicks Authorize button
2. User acknowledges the AppService they're granting and allows it
3. User is redirected back to the AppService

Technical Details

The page URL the Authorize buttons posts to is:

https://<node>.presence.mozilla.com/<appid>/grant?redirect=<url>&id=<userstring>

Where <node> and <appid> are values known by the registered application, <url> is the url to redirect back to, and <userstring> is the user-meaningful string indicating that should usually be their login name (or something short and meaningful to distinguish multiple identities on a single AppService if applicable).

In the example above, the user Marge happens to be logged into BeerChat as 'Fred', so this identifier is attached during authorization so that when Marge manages her Presence she can see that she appears online as Fred to BeerChat.

The user is expected to already be signed into their Firefox Account in this example, otherwise they will need to first login to Prsence before seeing the authorization page.

Authorizing the AppService performs a POST on https://<node>.presence.mozilla.com/<appid> containing the redirect url and the answer.

If user has accepted, Mozilla Presence generates a unique ID (PUID) to identify the user in the context of the application.

The user then is redirected back to <url> with an encoded PUID in a <Presence-UID> header.

The application is responsible to store the PUID and associate it with the user.

The redirect flow looks like this:

4. Presence Sidebar

XXX the one risk we have prototyping with Social Sidebar is that we design something that works great for desktop use, but is not a good UX for a phone

Mozilla Presence provides a Social API sidebar with the following features:

• a Persona login/logout button
• three buttons to set her status. [online/offline/unavailable].
• a list of authorised applications with a [deactivate/revoke] button for each one of them.

This sidebar can be activated by the user to manage her presence - the side bar will open a web socket on ws://presence.services.mozilla.com/presence to send status updates.

5. Status updates

When Mozilla Presence gets a status update from someone, it looks up all the registered applications and sends to the one that are activated the updates.

Since statuses are fetched via a web socket at ws://<node>.presence.mozilla.com/<appid>, each application gets its own messaging queue that is dequeued when the application is connected via the web socket. A status message is dropped from the queue if not consumed within an hour.

6. Live notifications

XXX encryption ?

Live notifications are a way for applications to reach out online users that are not active in the application.

Like status updates, live notifications are done via ws://presence.services.mozilla.com/presence.

The application sends a notification to Mozilla Presence via a POST request containing :

  POST https://<node>.presence.mozilla.com/<appid>/notification
  
  {'UID': 'userid',
   'message': '<message>',
   'url': '<url>'}

Each user gets its own messaging queue and the message will be discarded after 5 minutes if not consumed by the user.

If the user is connected on ws://presence.services.mozilla.com/presence - the messages will be dequeued and pushed there.

XXX implementation of desktop UI, see https://developer.mozilla.org/en-US/docs/Social_API/Widgets#Notification_Panels

Platform Requirements

What are the things this needs (OS, language, databases, etc.)?

XXX explain here how simple push is running on the different platforms - Firefox OS : built-in, what about Desktop ? a separate service that wakes up Firefox ?

Libraries Required

List of external project dependencies. (Stuff that's not pulled in via the installation script)

Code Repository

Links to the published code bases

Release Schedule

Predicted code delivery dates

QA

Points of Contact

Engineer - Name contact@info

Test Framework

Security and Privacy

Fill out the security & privacy bug template: https://bugzilla.mozilla.org/form.moz-project-review (https://wiki.mozilla.org/Websites/Kick-Off_Form)

For security reviews, there's: https://wiki.mozilla.org/Security/ReviewProcess

Points of Contact

Questionnaire Answers

1.1 Goal of Feature

2. Potential Threat Vectors and Mitigation Points

Review Status

Bugzilla Tracking # - see https://wiki.mozilla.org/Security/Reviews

Issues and Resolutions

Operations

Points of Contact

Deployment Architecture

Bugzilla Tracking # -

Escalation Paths

Lifespan Support Plans

Logging and Metrics

Points of Contact

Tracking Element Definitions

Data Retention Plans

Dashboard URL

Customer Support

Points of Contact

Sumo Tags

Review Meeting