User Services/Meta

Context

Given that Firefox Account is a multi-service account system, and the set of services will grow and change over time, we need a small service to manage the set of service descriptors and allow clients to make and describe their choices.

This is one of two privileged services — privileged meaning "directly known to the account system" — the other being device management itself (very likely simply a role of the account system).

Outline

The service description system is envisioned to be a standalone service with the same availability and durability requirements as the account service. It exposes a simple API for managing three domain entities:

• Device descriptions.
• Service descriptions.
• Device-service elections.

That is, by talking to the service description system, armed with canonical knowledge of connected devices (via device management, which is the source of truth for active/inactive etc.), it's possible to discover:

• The protocol (and feature) capabilities of those connected devices.
• The services known to implement those protocols.
• Which services are in use by which connected devices.

Note that this service is 'not' responsible for storing service-specific data: no last-sync timestamps, no preferences for days of history, etc. The general rule of thumb is that if it changes infrequently and is useful for selecting an endpoint it lives here; if it describes the operation of a particular service it lives near that service.

This data is used to select, present, and sometimes seamlessly transition between services.

Flow

 [Auth with FxA] => (devices)
 [Query SD server] => (services and elections)
   [Decide on service and user elections]
 [Update SD server]
 [Connect to individual services]

Categories, protocols, services, and features

One can imagine a taxonomy like this:

 "Data synchronization"
   Firefox Sync 1.1
     Mozilla's Firefox Sync 1.1 service
     JoeCorp's Firefox Sync 1.1 service
   Firefox Sync 3.0
     Mozilla's Firefox Sync 3.0 service
       — supersedes Mozilla's Firefox Sync 1.1 service
 "Reading list"
   Pocket Share 1.0
     Pocket's hosted sharing service

That is: a category of related protocols that achieve a stated goal; a set of defined protocols that services (and clients) implement; and then concrete endpoints that expose that protocol.

The assumption is that services which implement a particular protocol are — to a point — interchangeable; more accurately, that any decision to use one provider over another is a personal or policy decision, not technical.

Clients are the other half of this. Shipping clients support a certain set of protocols — a set which might be extended by add-ons or future releases. They use those protocols to synchronize certain data types; for example, Sync 1.1 ships with engines for bookmarks, forms, history, etc.

Protocol selection

In short: choose the best protocol and service within the desired category, where "best" means:

• The most features you need
• The best overlap with your other devices
• Not superseded by another protocol/service.

Typically this will be a trivial decision: there will be one or two services, one or two protocols, and a limited feature set. Beyond that most services are likely to be disjoint sets, so I'm not concerned about intractible set cover problems and awkward heuristics.

Protocol transition

• Supersedes
• Cost to transition
  • Transition itself has a cost: no flip-flopping (though directional "upgrade arrows" should prevent this anyway)
  • Distinction between one-shot and persistent, and between cleartext and encrypted
    • Easy to switch to a new Pocket API; less so for encrypted profile data.
  • Unsupported devices
  • Unsupported features
  • Reupload
  • Re-encryption

Service descriptions

Straight to the JSON:

 {"id": "daecb5b2-8235-479f-91ca-09447d4bb339",      — Or a URL?
  "v": 1,                                            — Descriptors can 'mutate' by bumping versions.
  "name": "Mozilla Sync 1.1",
  "provides": "org.mozilla.sync.1.1",
  "url": "https://auth.services.mozilla.com/",       — Protocol-specific.
  "pp": "https://services.mozilla.com/privacy-policy/",   — We'd like these included in the digest, so not metadata.
  "tos": "https://services.mozilla.com/tos/",
  "supersedes": [],
  "digest": "...", "owner": "...",                   — Some mechanism for verifying and protecting service descriptions.
  "metadata": "http://services.mozilla.com/sync-1.1/meta", — Support URL, icon bundles, descriptive text; clients can cache.
 }

Device descriptions and elections

Note that this augments the basic device info from the account service.

 {"id": ...,                — Stable identifier.
  "protocols": {
    "org.mozilla.sync.1.1": ["bookmarks", "adblockplus"],
    "org.mozilla.sync.3.0": ["bookmarks", "readinglist"],
  },
  "elections": {
    "org.mozilla.sync.1.1": {
      "service": "daecb5b2-8235-479f-91ca-09447d4bb339",      — Foreign key!
      "features": ["bookmarks"],                              — Protocol-specific; can be ignored/omitted.
    }
    "org.mozilla.sync.3.0": ...
  }
 }

Note also that this assumes that each device can elect its own datatypes — that is, each can sync a different set of data to a different service. Different user experiences can be layered on this; each device knows the other devices' elections, and can mirror them accordingly.