Confirmed users
1,022
edits
CloudServices/Presence: Difference between revisions
→Meeting Notes
| (15 intermediate revisions by 3 users not shown) | |||
| Line 9: | Line 9: | ||
Presence is a proposed Cloud Service that tracks a Firefox OS device's Internet connectivity status as ''online'', ''offline'' or ''unavailable'' by the device's Firefox Account. A Firefox OS Web App may request permission on behalf of its publisher to read status. Once approved, the publisher may poll the Presence service and, once the device is back online, push messages to the Web App. | Presence is a proposed Cloud Service that tracks a Firefox OS device's Internet connectivity status as ''online'', ''offline'' or ''unavailable'' by the device's Firefox Account. A Firefox OS Web App may request permission on behalf of its publisher to read status. Once approved, the publisher may poll the Presence service and, once the device is back online, push messages to the Web App. | ||
See [[# | See [[#Architecture Overview]] for more details. | ||
==Project Contacts== | ==Project Contacts== | ||
''Principal Point of Contact'' - <i>Tarek Ziade</i> <i>tziade@mozilla.com</i> | ''Principal Point of Contact'' - <i>Tarek Ziade</i> <i>tziade@mozilla.com</i> | ||
''IRC'' - #<i>presence-wg</i> | |||
''Group Email'' - https://mail.mozilla.org/listinfo/wg-presence | * ''IRC'' - #<i>presence-wg</i> | ||
* ''Group Email'' - https://mail.mozilla.org/listinfo/wg-presence | |||
===Team=== | |||
==== Cloud Services ==== | |||
* <i>Tarek Ziade</i> <i>tziade@mozilla.com</i> | |||
* <i>Ben Bangert</i> <i>bbangert@mozilla.com</i> | |||
* <i>Robert Lord</i> <i>rlord@mozilla.com</i> | |||
* Firefox Account Engineer - TBD | |||
==== Firefox OS ==== | |||
* <i>Fabrice Desré</i> <i>fabrice@mozilla.com</i> | |||
==Presence on other Mobile Platforms== | ==Presence on other Mobile Platforms== | ||
| Line 111: | Line 123: | ||
[https://id.etherpad.mozilla.org/presence Identity Presence Etherpad] | [https://id.etherpad.mozilla.org/presence Identity Presence Etherpad] | ||
[https://etherpad.mozilla.org/presence-meeting Presence Meeting Wiki] | |||
== Meetings == | == Meetings == | ||
| Line 125: | Line 139: | ||
=== Meeting Notes === | === Meeting Notes === | ||
https://etherpad.mozilla.org/presence-meeting-20140311 | |||
[[Services/Roadmaps/Presence/Meetings/notes_20131014]] | [[Services/Roadmaps/Presence/Meetings/notes_20131014]] | ||
| Line 191: | Line 207: | ||
The Presence service has several functions: | The Presence service has several functions: | ||
# let a user update her online status and set a custom status message | # '''Device Channel to Mozilla Presence''' - let a '''user''' update her online status and set a custom status message | ||
# let a developer register an application | # '''Applications registration''' - let a '''developer''' register an application | ||
# let a user manage applications access to their presence | # '''Applications permissions''' - let a '''user''' manage applications access to their presence | ||
# let an application receive status updates | # '''Status updates''' - let an '''application''' receive status updates | ||
# let an application send a live notification and a user receive it. | # '''Live Notifications''' - let an '''application''' send a live notification and a user receive it. | ||
=== 1. Device Channel to Mozilla Presence === | === 1. Device Channel to Mozilla Presence === | ||
Mozilla Presence provides a web socket endpoint at ''' | Mozilla Presence provides a secured web socket endpoint at '''wss://presence.services.mozilla.com/presence''' for | ||
devices to connect to. | devices to connect to. | ||
The user may connect to the socket using a valid FxA (which will entail a BrowserID Assertion per FxaSSO), and send status updates. The data must be sent in JSON. | The user may connect to the socket using a valid FxA (which will entail a BrowserID Assertion per FxaSSO), and send status updates. | ||
The data must be sent in JSON and is based on a simple protocol where a first request must be made to create a new session. | |||
Each subsequent request is a status update. The server or the user can disconnect from the socket at any time and for | |||
any reason. In that case the session is lost and a new session must be initiated. | |||
==== Session Request ==== | |||
Example of a session request: | |||
{'type': 'connect', | |||
'application_ids': [421, 492, 9592, 391], | |||
'assertion': 'valid persona assertion'} | |||
where: | |||
* '''assertion''' is a valid persona assertion | |||
* '''type''' is the type of request. in that case "connect" | |||
* '''application_ids''' is the list of applications IDs presence updates should be sent to. | |||
The '''application_ids''' field is used because Mozilla Presence does not retain a list of applications | |||
authorized to see updates. This data is kept only on the phone. As a result, the device must | |||
indicate what application ID's presence data should be sent to when connecting. | |||
The server validates the assertion by sending it to a persona/fxaccount verifier, | |||
and if valid, creates a unique session id and sends it back to the cient. | |||
Example: | Example: | ||
{'result': true, 'session_id': '61539351-1f02-4b62-a136-205000ece41a'} | |||
In case there's an issue, like an invalid assertion, the server will send back a | |||
request with a result flag set to false, an '''errno''' field with | |||
an error code (to be documented) - and an error message in the '''reason''' field. | |||
Example: | |||
{'result': false, 'errno': 34, 'reason': 'Invalid assertion'} | |||
==== Status Update Request ==== | |||
Once the session is set, the client can send status updates. | |||
Example: | Example: | ||
{' | {'type': 'status', | ||
' | 'session_id': '61539351-1f02-4b62-a136-205000ece41a' | ||
'status': 'online'} | 'status': 'online'} | ||
The | where: | ||
* '''session_id''' the session ID | |||
* '''type''' is the type of request. in that case "status" | |||
* '''status''' the presence status. The value must be one of "online", "offline", "unavailable". | |||
For every status received, the server sends back an ACK message. | In case the device wants to send a status update to a specific subset | ||
of applications, it can use the 'application_ids' key on a status update | |||
request, it will override the value set on a visibility call, just for | |||
that call. | |||
Example: | |||
{'type': 'status', | |||
'session_id': '61539351-1f02-4b62-a136-205000ece41a' | |||
'application_ids': [421, 391], | |||
'status': 'offline'} | |||
For every status request received, the server sends back an ACK message. | |||
Example: | Example: | ||
{'result': | {'result': true} | ||
In case of an error, the server | In case of an error, the server will send back an extra 'errno' field with an | ||
and an optional ' | error code (codes to be documented) and an optional 'reason' message. | ||
Example: | Example: | ||
{'result': | {'result': false, 'errno': 34, 'reason': 'Assertion expired'} | ||
The user can send as many updates as it wants, but the server can ask it to slow down with a specific | The error codes have to be documented, but in case the errno value is | ||
error code (codes to be documented) | a negative value, the session is lost and the client has to recreate a new one. | ||
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 server or the user can disconnect from the socket at any time and for any reason. | ||
| Line 303: | Line 366: | ||
Example: | Example: | ||
{'key': ' | {'key': 'e3b0c44298fc1c149afbf4c8....996fb92427ae41e4649b934ca495991b7852b855'} | ||
Once connected, the application will receive status updated as they happen, | Once connected, the application will receive status updated as they happen, | ||
in the form of a list. Each element is composed of an | in the form of a list. Each element is composed of an uid and a status. | ||
Example: | Example: | ||
| Line 353: | Line 416: | ||
When Mozilla Presence gets a status update from someone, it looks up all the | 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. | registered applications and sends to the one that are activated to see 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 | 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 | ||
| Line 409: | Line 472: | ||
* '''on mobile''', it displays a notification with a link to run the app XXX | * '''on mobile''', it displays a notification with a link to run the app XXX | ||
The application has no feedback on whether a notification was seen by the user. | The application has no feedback on whether a notification was seen by the user. | ||
==FAQ== | ==FAQ== | ||
| Line 464: | Line 527: | ||
* Possibly a QUIC-derived UDP-based device-presence channel | * Possibly a QUIC-derived UDP-based device-presence channel | ||
* XMPP interface for AppServices <-> Presence | |||
* FxA Integration for device user (Requires https://wiki.mozilla.org/Identity/Firefox_Accounts/SSO) | * FxA Integration for device user (Requires https://wiki.mozilla.org/Identity/Firefox_Accounts/SSO) | ||
* Developer Registration page to acquire Presence Application ID, linked to from the Developer page in Marketplace | * Developer Registration page to acquire Presence Application ID, linked to from the Developer page in Marketplace | ||
=QA= | =QA= | ||