User:Mconnor/BIDSync(s): Difference between revisions
Jump to navigation
Jump to search
(→Risks) |
|||
Line 10: | Line 10: | ||
* AppSync will be in most ways, just another Sync engine, but the data will be stored in a durable form, as a HA (three nines?) cluster with backups, and a to-be-defined target for durability/geo-redundancy | * AppSync will be in most ways, just another Sync engine, but the data will be stored in a durable form, as a HA (three nines?) cluster with backups, and a to-be-defined target for durability/geo-redundancy | ||
== Client | == Desktop Client == | ||
=== | === BrowserID Support === | ||
==== People ==== | ==== People ==== | ||
{{ServicesProjectPeople | {{ServicesProjectPeople | ||
|devLead=Gregory Szorc (gps) | |devLead=Gregory Szorc (gps) | ||
|engineers= | |engineers= | ||
}} | }} | ||
Line 24: | Line 24: | ||
* Hook key storage into BrowserID key wrapping/unwrapping | * Hook key storage into BrowserID key wrapping/unwrapping | ||
* Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials. | * Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials. | ||
* Define and document app-neutral data format for Apps metadata (shared with Android | |||
==== Risks ==== | |||
* UX portions are blocked on Product/UX coherency | |||
* BrowserID key wrapping is not implemented | |||
=== App Sync integration === | |||
==== People ==== | |||
{{ServicesProjectPeople | |||
|devLead=Anant N (anant) | |||
|engineers= | |||
}} | |||
==== Requirements ==== | |||
* Define and document app-neutral data format for Apps metadata (shared with Android/HTML5 implementations) | |||
* Write a Sync engine for Apps using the shared data format | * Write a Sync engine for Apps using the shared data format | ||
==== Risks ==== | ==== Risks ==== | ||
== Android Client == | |||
=== BrowserID Support === | |||
==== People ==== | ==== People ==== | ||
Line 40: | Line 55: | ||
==== Requirements ==== | ==== Requirements ==== | ||
* Implement support for the v2.0 protocol based on BrowserID | * Implement support for the v2.0 protocol based on BrowserID | ||
* Hook key storage into BrowserID key wrapping/unwrapping | * Hook key storage into BrowserID key wrapping/unwrapping | ||
* Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials. | * Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials. | ||
==== Risks ==== | |||
* UX portions are blocked on Product/UX coherency | |||
* BrowserID key wrapping is not implemented | |||
=== App Sync integration === | |||
==== People ==== | |||
{{ServicesProjectPeople | |||
|devLead=Harald Kirschner (digitarald) | |||
|engineers= | |||
}} | |||
==== Requirements ==== | |||
* Define and document app-neutral data format for Apps metadata (shared with Desktop Client) | * Define and document app-neutral data format for Apps metadata (shared with Desktop Client) | ||
* Write a Sync | * Create an Android content provider for access to Apps local store | ||
* Write a Sync repository for Apps using the shared data format and the content provider | |||
==== Risks ==== | ==== Risks ==== | ||
=== HTML5 Client === | === HTML5 Client === |
Revision as of 23:54, 26 January 2012
Project Summary
Sync is moving to use BrowserID. The Apps product also needs Sync, and introduces a hard requirement for access to data from HTML5 web apps. This is a joint project to build out a shared platform, based on the current Firefox Sync implementations and APIs.
High level concepts
- We will use BrowserID+OAuth for authentication to service endpoints.
- This includes a token/service discovery service that points clients to resources
- BrowserID will provide a key wrapping service that will allow the Sync Key to be stored, safely, alongside of the Sync data.
- AppSync will be in most ways, just another Sync engine, but the data will be stored in a durable form, as a HA (three nines?) cluster with backups, and a to-be-defined target for durability/geo-redundancy
Desktop Client
BrowserID Support
People
Developer Lead | Gregory Szorc (gps) |
Additional Engineers |
Requirements
- Implement support for the v2.0 protocol based on BrowserID
- Hook key storage into BrowserID key wrapping/unwrapping
- Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials.
Risks
- UX portions are blocked on Product/UX coherency
- BrowserID key wrapping is not implemented
App Sync integration
People
Developer Lead | Anant N (anant) |
Additional Engineers |
Requirements
- Define and document app-neutral data format for Apps metadata (shared with Android/HTML5 implementations)
- Write a Sync engine for Apps using the shared data format
Risks
Android Client
BrowserID Support
People
Developer Lead | Richard Newman (rnewman) |
Additional Engineers | Harald Kirschner (digitarald), Chenxia Liu (liuche) |
Requirements
- Implement support for the v2.0 protocol based on BrowserID
- Hook key storage into BrowserID key wrapping/unwrapping
- Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials.
Risks
- UX portions are blocked on Product/UX coherency
- BrowserID key wrapping is not implemented
App Sync integration
People
Developer Lead | Harald Kirschner (digitarald) |
Additional Engineers |
Requirements
- Define and document app-neutral data format for Apps metadata (shared with Desktop Client)
- Create an Android content provider for access to Apps local store
- Write a Sync repository for Apps using the shared data format and the content provider
Risks
HTML5 Client
People
Developer Lead | Ian Bicking (ianbicking |
Additional Engineers | TBD |
Requirements
<<not defined yet>>
Risks
- BrowserID key wrapping not implemented
Server Work
BrowserID key wrapping and master key storage
People
Developer Lead | Ben Adida (benadida) |
Additional Engineers | TBD |
Requirements
- Provide an API for BrowserID consumers to have a key bundle wrapped/unwrapped using a master key
- Store master key with BrowserID provider
Risks
- crypto is hard
- work not yet started
Discovery Service
People
Developer Lead | Tarek Ziade (tarek) |
Additional Engineers | Alexis Metaireau (alexis) |
Requirements
- Provide a file that represents an entry point into a Sagrada system. Can be static.
Risks
- File format needs defining. It's not going to be complex, though.
Token Server
People
Developer Lead | Tarek Ziade (tarek) |
Additional Engineers | Alexis Metaireau (alexis) |
Requirements
- Define flow for retrieving and converting tokens to be used in other Sagrada apps
- Implement HA, scalable server with entrypoint for each service
- Do node-assignment to large-scale installations to distribute users across the instance
Risks
- High-volume crypto at scale is tricky
Storage API v2.0
People
Developer Lead | Ryan Kelly (rfkelly) |
Additional Engineers | Tarek Ziade (tarek) (as consultant on current system) |
Requirements
- Support consumption of Sagrada tokens as primary method of authentication
- Use Sagrada metadata tokens to identify backend storage location
- Document and implement changes to 2.0 API (almost all unused feature removal)
- Take the clean-room opportunity to fix some long-standing database problems
Risks
- Because users will reupload all their stuff, FF launch day is likely to be a heavy, heavy data day.
Metrics (metlog)
People
Developer Lead | Rob Miller (RaFromBRC) |
Additional Engineers | Victor Ng (vng) |
Requirements
- Produce internal library for centralized logging
- Process incoming logging data along entire pipeline to final storage location(s)
- Some initial graph interpretations of incoming data
Risks
- While this is nice to have and probably achievable, it is not strictly a blocker to BID sync
Token Processing Library
People
Developer Lead | Ryan Kelly (rfkelly) |
Additional Engineers | Tarek Ziade (tarek) |
Requirements
- Abstract out the code that turns a Sagrada token into a userid and some additional metadata into a library that all Sagrada services can use.
Risks
Durable Node Cluster
People
Developer Lead | Richard Soderberg (atoll) |
Additional Engineers | Pete Fritchman (petef) |
Requirements
- Operational deployment of v2.0 webheads, talking to a Replicated MySQL cluster with backups
- Durability of data is a requirement. HA requirement is similar to sync.
Risks
Security Assessments
- Threat/security analysis (yvan)