CloudServices/Presence
|
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
Overview
The goal of Mozilla Presence is to provide a way for applications to know when their users are online, even if they don't have the application running.
XXX find a better sentence here
Project Contacts
Principal Point of Contact - Tarek Ziadé tarek@mozilla.com
IRC - #presence-wg
Group Email - wg-presence@mozilla.org
Goals
How will you know things are working? What problems does this solve?
Use Cases
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).
Talkilla
XXX
SUMO
XXX See with Lloyd about the user story there (sumo experts summoned etc)
Requirements
- List of requirements
Get Involved
Documents so far
Meeting Notes
Services/Roadmaps/Presence/Meetings/notes_20131014
Services/Roadmaps/Presence/Meetings/notes_20131031
Design
Points of Contact
Engineer - Name contact@info
General Overview
This service is hooked onto SimplePush, such that when a client ping comes in that includes presence info (either O, A, or U to indicate Online/Away/Unavailable based on the devices Presence policy dictated by the devices user and its idel time), then SimplePush will broadcast that to Presence somehow, that client id XXYYY is now O/A/U or whatever. Presence then updates its record and relays the status update to the services the user has authorized.
The service stores records for every user that has Presence 'activated'. The device is tied to the users FxA such that if the device is lost, when they get a new one they will still identify the same. If/When a client needs to re-register for SimplePush, the SimplePush client-id is sent to Presence to tie it to the existing FxA record.
Presence stores a set of data (rough schema):
Client-Mappings:
Client-ID | Corresponds to the client-id that is used for SimplePush
FxA-ID | The FxA of the presence user
Presence-Authentications
FxA | The FxA of the presence user
Service-ID | Service ID that the app developer registered for this service
UUID | A unique ID for this user on this service, to avoid leaking the FxA ID
Status | Boolean flag on whether the user currently wants presence broadcast to this service
When the user changes the toggle on their device to turn on/off Presence, their device must be able to contact our server so that we can update their Presence choice in the Presence-Authentications table. This is because Presence is broadcast in the background by the SimplePush UA, and we don't want to have to include a list of all the 'apps' that should get the presence update in every ping request.
When Presence gets a status update from simplepush, it looks up the client-id in the Client-Mappings, then uses that to lookup all the services in Presence-Authentications that the user wants notified of this change. It filters out services that the user has currently chosen not to recieve presence. The remaining services have their webhook URL's called with the UUID and presence change so that the services can decide what they want to do.
To avoid a call for every single status change, the Presence service may batch updates to the various services so that the webhook URL for each service is only called every 30+ seconds with all the updates intended for it (in the list POST format explained above).
Architecture Overview
- appmaker asks for a token
- appmaker register to the presence server to ask for presence info - basically a POST with the web hook + the token as an auth
- Bob decides to give appmaker Presence access.
- Bob is redirected with appmaker token to Presence service.
- Bob hits 'Yes' to grant appmaker access to his Presence
- Bob is redirected back to appmaker with token that includes Presence UID (the one you'll get with the update in step 5)
- bob updates his status with the presence
- sarah updates her status with the presence
- the presence service calls the webhook to notify status updates
Proposed Modifications to SimplePush
SimplePush protocol is defined here.
Principle changes to the protocol involve introducing a change to the "hello" and "ping" packets.
The "hello" packet needs to be modified to include a GUID as the user's Presence ID (PrID). This is required because SimplePush UserAgentIDs (UIAD) can change at any time, where the PrID is more "stable", but only active when the user opts into Presence.
In an effort to save bandwidth, keys are reduced to x + "p" + sub identifier.
old format:
{messageType": "hello", "uaid":"...", "channelIDs":[...]}
new format:
{"messageType": "hello", "uaid":"...", "channelIDs":[...], "xpi":"..."}
It is important to note that future simplepush reregistrations use the same "xpi" value (if defined). This will allow the SimplePush socket plugin monitor to associate the correct to the correct Presence server.
"ping" packets would use the optional long form and contain the Presence Status (xps).
{"messageType": "ping", "xps":"(UAO)?"}
A simplepush "ping" packet is exchanged between the client and server when the user's status changes. User's status is indicated by
- "A"way (user is idle or temporarily unavailable)
- "U"navailable (user has gone offline)
- "O"nline
This information would be picked up by the Presence Plug-in to SimplePush which would send the status change to the Presence monitoring system using TBD REST calls.
For App Developers
An app developer wishes to get presence information, the following can be addd to the app manifest:
{
"permissions": {
"push": {"description": "To receive notifications about the newest phone releases"},
"presence": {"description": "To broadcast presence"}
},
"messages": [
{"push": "/view_to_launch.html"},
{"push-register": "/view_to_launch.html"}
]
}
Note that the existing bits for SimplePush are retained, as Presence merely add's broadcast of the user's Presence to the app.
The application developer must register their application separately with Mozilla Presence and set a "Webhook URL" that will be called with presence updates for users that look like the following:
POST /some/webhook/callback
{[
["UID2949293", "away"],
["UID4823888", "online"],
["UID482838", "offline"],
["UID4828382", "online"]
]}
When the user grants access, your application will get a unique ID that you should associate with the user record your application stores.
A doorhanger will be needed in applications to prompt the user to grant an application Presence notification data should the user not grant it initially when installing the app (and for websites that don't necessarilly install as 'apps').
Setup of a doorhanger will require the app developer to register their application with Mozilla Services and get an application token. This application token can be used with Mozilla TokenServer to register access with the Mozilla Presence server. The app developer may then enter the "Webhook URL" in their Settings page for Mozilla Presence.
When a user signs-in to your application/website and you wish to ask for Presence notifications, you may redirect the user to Mozilla Services asking for "Presence" access. The user will be prompted to grant access or deny and redirected back to your application. If the user granted access, the redirect will include an encoded UID that you should store and associate with the user as this UID will be the one sent in the Webhook calls.
App developers should account for the possibility that 'updates' may get lost, and automatically mark a user as offline if no status is sent in an hour.
For Device Users
A separate Settings page is available, that looks similar to the iOS Notifications page, showing a list of apps and websites that have been granted Presence access. The page also lets one set a "Presence Policy" that determines what liveliness is communicated, for example:
Presence Policy Show me online when I've used this device in the past: 5 - 10 - 15 - 20 (minutes) Show me away when I haven't used this device in at least: 5 - 10 - 15 - 20 (minutes) Show me offline when I haven't used this device in at least: 10 - 25 - 35 (minutes)
Perhaps these will be sliders, UX is not determined this is only a possible example of how the user determines
what type of 'livliness' data is sent based on whether they're using the device or not, and how recently.
A list of toggles for each app the user has granted access to will be here, so that a user may turn off Presence for individual apps temporailly without fully revoking possible future Presence broadcasts to the app/website.
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 # -