Loop/Architecture: Difference between revisions
< Loop
Jump to navigation
Jump to search
(→Desktop Client Architecture: Add link to room context information, and also create a new one for the data channels) |
|||
| (34 intermediate revisions by 6 users not shown) | |||
| Line 2: | Line 2: | ||
= Underlying Technologies = | = Underlying Technologies = | ||
== Mozilla Technologies == | == Mozilla Technologies == | ||
| Line 10: | Line 9: | ||
* [[Identity/Firefox Accounts|Firefox Accounts]] | * [[Identity/Firefox Accounts|Firefox Accounts]] | ||
* [[WebAPI/SimplePush|Simple Push]] ({{bug|976789}}) | * [[WebAPI/SimplePush|Simple Push]] ({{bug|976789}}) | ||
* [ | * [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette Marionette] for functional testing (may include selenium later), and for running unit-test framework. | ||
== Third-Party Technologies == | == Third-Party Technologies == | ||
* Node.js for Loop server | * [http://facebook.github.io/react/ React] | ||
* [http://backbonejs.org/ Backbone] (being phased out) | |||
* Node.js for Loop server | |||
* webl10n for Localization, extracted from gaia ({{bug|972884}}) | |||
* Localization ({{bug|972884}}) | * [http://eslint.org/ eslint] for linting javascript | ||
* | * 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}}) | ||
* | |||
= Network Architecture = | = Network Architecture = | ||
[[File:loop-network.png|center|Network Diagram]] | |||
== Data Flows == | == Data Flows == | ||
The following diagrams represent the as-built behavior as of Firefox 41. | |||
=== Browser Startup === | |||
[[File:loop-startup.png|center|Browser Startup]] | |||
=== Room Creation === | |||
[[File:loop-create-room.png|center|Room Creation]] | |||
=== Session Start: Owner Joins Room === | |||
[[File:loop-owner-join.png|center|Owner Joins Room]] | |||
=== Session Start: Guest Joins Room === | |||
[[File:loop-guest-join.png|center|Guest Joins Room]] | |||
=== Session End === | |||
[[File:loop-session-end.png|center|Session Ends]] | |||
<!-- | |||
''Note that these are currently described in terms of a REST (or, at least, REST-like) interface on the Loop server. There is a significant possibility that this interface will evolve to be JSON objects exchanged on a WebSockets connection, similar to the network API exposed by the Simple Push Server.'' | |||
[http://docs.services.mozilla.com/loop/index.html Current as-built documentation] of the API is available from the Mozilla Services Documentation web page. | |||
=== User Connects === | === User Connects === | ||
{{warning|This diagram is out-of-date with respect to FxA. See the [https://raw.githubusercontent.com/vladikoff/fxa-docs-browser-loop/master/charts/fxaoauthflow.png newer version]. }} | |||
[[File:loop-registration.png|center|Endpoint Registration]] | |||
=== User Generates "Call-Me" URL === | === User Generates "Call-Me" URL === | ||
[[File:loop-create-call-me.png|center|"Call-Me" URL Generation]] | |||
=== Non-User Clicks "Call-Me" URL === | === Non-User Clicks "Call-Me" URL === | ||
[[File:loop-use-call-me.png|center|"Call-Me" URL Activation]] | |||
=== User Rejects Call === | === User Rejects Call === | ||
[[File:loop-reject-call.png|center|Call Rejected]] | |||
'''Note that the exact means by which Bob receives pending call status is still an open issue -- periodic polling is easy, but might not scale as well as we'd like. Long polling is a potential improvement, but also has scaling implications. Ultimately, websockets may be the preferred approach here.''' | |||
=== User Blocks "Call-Me" URL === | === User Blocks "Call-Me" URL === | ||
[[File:loop-block-url.png|center|"Call-Me" URL Blocked]] | |||
=== User Abandons Ringing Call === | |||
[[File:loop-abandon-call.png|center|Calling User Abandons Ringing Call]] | |||
=== User Calls Other User === | === User Calls Other User === | ||
[[File:loop-call-user.png|center|Loop user calls other Loop user]] | |||
--> | |||
= Client Architecture = | = Desktop Client Architecture = | ||
== Address Book == | == 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. | |||
== Room Contexts == | |||
Rooms may have context attached by the user. The context is stored as an encrypted data block on the server. | |||
See [[Loop/Architecture/Context]] for detail. | |||
== WebRTC Data Channels == | |||
The conversations set up between users may transmit data (e.g. text chat) via WebRTC data channels. There is a specified structure for this data. See [[Loop/Architecture/Data Channels]] 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 "[https://en.wikipedia.org/wiki/MSISDN 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: | |||
[[File:msisdn-verification.png|center|MSISDN Verification]] | |||
* [https://github.com/mozilla/fxa-auth-server/wiki/API-extensions-for-supporting-MSISDN-verification-in-FxA-auth-server Server API documentation] | |||
** [https://github.com/mozilla-services/msisdn-gateway/ Proof-of-concept server implementation] (work in progress) | |||
* Client implementation {{Bug|988469}} | |||
= Server Architecture = | = Server Architecture = | ||
== Database Schema == | == Database Schema == | ||
= ID Architecture = | |||
[https://wiki.mozilla.org/Loop/Architecture/ID ID architecture proposal] | |||
[[Category:Firefox Hello]] | |||
[[Category:Loop]] | |||
Latest revision as of 13:50, 24 August 2015
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)
- Marionette for functional testing (may include selenium later), and for running unit-test framework.
Third-Party Technologies
- React
- Backbone (being phased out)
- Node.js for Loop server
- webl10n for Localization, extracted from gaia (bug 972884)
- eslint for linting javascript
- 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)
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.
Room Contexts
Rooms may have context attached by the user. The context is stored as an encrypted data block on the server.
See Loop/Architecture/Context for detail.
WebRTC Data Channels
The conversations set up between users may transmit data (e.g. text chat) via WebRTC data channels. There is a specified structure for this data. See Loop/Architecture/Data Channels 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