Loop/Architecture
Design Goals
Underlying Technologies
Mozilla Technologies
The Loop project relies on a number of other technologies under development within Mozilla. These include the following:
- WebRTC
- Firefox Accounts
- Simple Push (bug 976789)
- Social API (bug 971987)
- Note: Waiting for feedback from Desktop team about modifications to current Social API approach; may be re-using Social components without being a literal Social provider. Feedback due no later than 25-Apr-2014.
- Marionette for automating client-side unit tests for build-system & tbpl (bug 976127)
Third-Party Technologies
- Node.js for Loop server, at least through production
- webl10n for Localization (bug 972884)
- Mocha and Chai for client-side and standalone-page unit-testing framework (bug 976133)
- Not using client CSS toolkit at the moment (this may be revisited) (bug 976854, bug 976857)
Open Issues
These technology choices will be moved into one of the preceding sections as decisions are made:
- Client MVC Library + associated libs (bug 975548) -- Probably Backbone
- Client-driven end-to-end framework (bug 976114)
- Standalone-page end-to-end system testing framework (bug 976134)
Network Architecture
Data Flows
The following diagrams represent the as-built behavior as of Firefox 41.
Browser Startup
Room Creation
Session Start: Owner Joins Room
Session Start: Guest Joins Room
Session End
Desktop Client Architecture
Address Book
the main means by which users are expected to initiate Loop calls on desktop is via the "Address Book" sidebar, which will contain a list of the user's contacts. For the initial versions of Loop, contacts will can be populated from several sources, via a one-way synchronization (that is, the data will be imported from a remote authority and updated from that remote authority, but cannot be changed by the Loop client). A necessary implication of this setup is that all contacts will need to track which data source they belong to, and be updated only from those sources.
See Loop/Architecture/Address Book for detail.
Mobile Client Architecture
MSISDN (Phone Number) Verification
An important aspect of the user stories for the mobile client is the ability to originate and receive Loop calls from and to a mobile phone number (generally called a "MSISDN") without the need to create or log in to a Firefox Account.
This verification requires two key components: a client implementation running on the mobile device to request a certificate that allows assertion of the MSISDN as an ID, and a server implementation that can verify ownership via SMS, and issue the certificates.
At a high level, the information flow looks like this:
- Server API documentation
- Proof-of-concept server implementation (work in progress)
- Client implementation bug 988469