WebActivities

Current State of Web Activities

Mozilla's efforts in Web Activities are two-fold:

WebActions -- Web Actions are simple actions that people do from one site across to another site. Web Actions are being developed based on existing real world publishing examples, user interfaces, and service provider best practices.

Previous Implementation

Web Activities was originally implemented within the scope of the Open Web Apps project, and is currently used as the foundation for F1/Share. As the scope of the Open Web Apps project crystallized and product delivery was planned, Web Activities was temporarily sidelined with the intent to return to it later. The code is in working state, has been privacy and security reviewed, and released in Q3 as a part of the base code in F1, now known as Firefox Share, though Web Activities API is not provided to content.

The current repository lives at https://github.com/mozilla/activities This repository removes OpenWebApps dependency, and has a branch called features/simple-share with a stripped down version implementing a simple version of share using activities.

Issues

Web Activities defines a registerActivityHandler method that providers call to register a function to handle a specific method. In our use, this call is similar to addEventHandler. For a single functional activity provider, we register a number of handlers, thus roughly implementing a protocol via functions. The features/simple-share branch mentioned above removes this issue.

Our documented API has an Activity class, essentially the same as the Web Intents "Intent" class. The actual implementation does not provide this, rather taking a simple js object in its place. This is a result of an attempt to move Web Activities closer to Web Intents.

Architecture

Much of the architecture for Web Activities is covered by the F1 security and privacy reviews, though F1 is an overly complex implementation of an ActivityMediator.

Overall, the architecture of the activities addon module provides the fundamental parts used by any of the current proposals (Web Activities, Intents, Actions, RegisterProtocolHandler). There is a way to register the publisher, a way to initiate an action in a provider, and a mediator for user centric routing from a provider to a publisher. The content level APIs on top of that could be modified to support any or even multiple proposals.
F1 subclasses the meditor in the activities module to provide an enhanced protocol for that action.

Discovery

Web Activities does not implement or specify any discovery mechanism, rather, it relies on the Open Web Apps system for discovery. The goal of basing discovery on Web Apps is an assumption that requiring user installed applications is a user-centric mechanism which is more secure, privacy enhancing and understandable.

The discovery mechanism is likely to change in the short term to remove the dependency on Open Web Apps. The mechanism may include the ability to register action providers from multiple sources, including installed Web Apps.

Lessons from F1

There are a few top level lessons we can take away from the F1 project:

Providers want to control the experience

We might not have a convincing enough value proposition for Publishers

The custom UI approach requires more extensive effort that is not scalable if Mozilla must maintain the code

Users like the user-centric UI-in-browser approach

Related

WebActions - Web Actions can hopefully evolve to eventually support more fully fledged Web Activities (including the lessons we learn by doing / shipping / iterating the simple stuff first)