MozillaWiki

CloudServices/Presence: Difference between revisions

Page Discussion

CloudServices/Presence (view source)

Revision as of 18:50, 11 March 2014

2,338 bytes added ,  11 March 2014
→‎Meeting Notes
 
(14 intermediate revisions by 3 users not shown)
Line 14: Line 14:


''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>
''Point of Contact'' - <i>Ben Bangert</i> <i>bbangert@mozilla.com</i>
''Project Manager'' - <i>Robert Lord</i> <i>rlord@mozilla.com</i>
''FireFoxOS'' - <i>Fabrice Desré</i> <i>fabrice@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 '''ws://presence.services.mozilla.com/presence''' for
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.


Mozilla Presence does not retain a list of applications authorized to see updates, this
The server validates the assertion by sending it to a persona/fxaccount verifier,
data is kept only on the phone. As a result, the device must indicate what application ID's
and if valid, creates a unique session id and sends it back to the cient.
presence data should be sent to when connecting. This is done in a application stanza, and can
be sent during a connection if a user is changing what applications can see the status as well.


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 ====


    {'type': 'appvisibility',
Once the session is set, the client can send status updates.
    'application_ids': [421, 492, 9592, 391]}


Status updates
Example:
Example:


     {'email': 'tarek@mozilla.com',
     {'type': 'status',
     'assertion': 'valid persona assertion',
     'session_id': '61539351-1f02-4b62-a136-205000ece41a'
     'status': 'online'}
     'status': 'online'}


The status value must be one of "online", "offline" or "unavailable"
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': 'OK'}
   {'result': true}


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


Example:
Example:


   {'result': 'KO', 'errno': 34, 'error': 'Invalid assertion'}
   {'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': 'XXX'}
   {'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 e-mail and a status.
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=
Jrconlin
Confirmed users
1,022

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/798127...949051"