CloudServices/Loop: Difference between revisions

Jump to navigation Jump to search

CloudServices/Loop (view source)

Revision as of 15:52, 21 April 2014

701 bytes added ,  21 April 2014
no edit summary
No edit summary
Line 1: Line 1:
{{LastUpdated}}
<h1><i>Loop Project Checklist Page</i></h1>
==Overview==


{{Draft}}
==Important Dates==
* <s>{{mok}} 2014-04-14 :: Review MVP User Stories</s>
*{{mok}} 2014-04-25 :: Definition of user flows, architecture & API confirmed for how authentication will work
* Milestones <i>TBD</i>


=Overview=
==Project Contacts==
* Complete cross-functional [https://wiki.mozilla.org/Services/Loop/DRIs 'DRI List']
* IRC channel: #loop
* Loop Development Mailing List: [https://mail.mozilla.org/listinfo/loop-dev loop-dev]


The loop project aims to provide a WebRTC application firefox users can use from within Firefox.
==Goals==
The server part handles registration of the clients, generation of temporary links and communication with the WebRTC infrastructure provider.
<i>How will you know things are working?</i>
<i>What problems does this solve?</i>
==Use Cases==
[https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AlJmiyFngeSwdGJEVnItQ2NVbGx6NXdjbVBUYmIxSGc&usp=drive_web#gid=0 Loop MVP User Stories]


=Definitions=
===MVP Loop===
<onlyinclude>
<bugzilla>
{
    "blocks": "971986",
    "resolution": "---",
    "include_fields": "id, priority, summary, status, assigned_to",
    "order": "bug_id"
}
</bugzilla>


* Simple Push URL: an URL the server can ping in order to wake up the client.
==Requirements==
* FxA assertion: a Firefox Account assertion (read token) containing a way to identify the user on the server
* <i>List of requirements</i>
* Provider tokens: In order to initiate a call between two parties, the provider issues tokens, session ids and client need to have an API key.
==Get Involved==
<i>Call to action for folks who want to help.</i>
=Design=
==Points of Contact==
Engineer - <i>Name</i> <i>contact@info</i>


=APIs=
== UX/UI ==


A "*" means this URI requires authentication (Ideally you should pass a valid BrowserID assertion, current implementation does that with a session cookie).
==API Reference/Documentation==
=== Data Schema ===
<i>How will data be stored</i>
=== API ===
<i>How to call the data</i>
==== <i>method</i> <i>URI</i> ====
<i>description</i>


'''POST /registration'''
Arguments <i>argument descriptions</i>
* Content-Type: 'application/json'
Returns: <i>returned contents</i>
* Body: simple_push_url
* Notes: Associates a Simple Push Endpoint (URL) with the authenticated user.


'''POST /call-url'''
==Platform Requirements==
Create the call url a callee can click on. (Requires "remote_id" and "valid_duration" parameters).
<i>What are the things this needs (OS, language, databases, etc.)?


==Libraries Required==
<i>List of external project dependencies. (Stuff that's not pulled in via the installation script)</i>


'''GET  /calls/{token}'''
==Code Repository==
Get the app (that's the url in question, which displays an app) (No parameter required.)
<i>Links to the published code bases</i>
==Release Schedule==
<i>Predicted code delivery dates</i>
=QA=
==Points of Contact==
Engineer - <i>Name</i> <i>contact@info</i>
==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


'''POST /calls/{token}'''
==Points of Contact==
Add an incoming call (does a simple push notif and gets room tokens), return participant tokens. (No parameter required.)
==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==


=Legal=
<!-- Please note. Do not add sensitive elements to this public page. Any project that involves Personal Identifying Information MUST contact legal. Be smart, don't get us sued. -->
==Points of Contact==


'''GET  /calls/'''
=Operations=
<!-- Get Operations involved as soon as it is feasible. They'll need to set up staging and production machines and can help suggest methods for project deployment, monitoring and tracking that will keep you from being woken up at 3AM. -->


List incoming calls for the authenticated user. (No parameter required.)
==Points of Contact==
==Deployment Architecture==
''Bugzilla Tracking # '' -
==Escalation Paths==
==Lifespan Support Plans==


=User Flow=
=Logging and Metrics=
 
==Points of Contact==
Let's say Bob wants to be called by Alice.
==Tracking Element Definitions==
The workflow is as follows:
==Data Retention Plans==
 
==Dashboard URL==
  1. Bob's client registers with SimplePush, he gets a simple push url back and listens to the WebSocket connection;
=Customer Support=
  2. Bob's client registers with the loop server
==Points of Contact==
  3. Bob asks the server to generate a call url for him;
==Sumo Tags==
  4. Bob gives this URL to Alice;
==Review Meeting==
  5. Alice clicks on the link, server validates the URL and displays a WebApp with a message "do you want to call Bob"?
==Documentation Internationalization==
  6. Alice decides to call Bob, server validates the URL
  7. Server gets provider tokens; Server stores the callee token and session id in database;
  8. Server pings the Simple Push Server to wake up Bob's client;
  9. Server returns caller token, session id and API Key to Alice's client
  10. Bob client wakes up, go on the server to look at the list of incoming calls;
  11. Server returns the list of calls (containing provider information) to Bob's client.
  12. Connection can be done between Alice and Bob!
 
[[File:Loop-server-flow.png]]
Tarek.ziade
Confirmed users
927

edits

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

Navigation menu