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.
• WebAPI/WebActivities - Web Activities is a counter-proposal to Google Web Intents. Web Activities limit the scope of the API to the use case of: APP A wants to delegate an activity to APP B. Web Activities isn't a discovery API nor a communication API. See: latest posts on Web Activities in mozilla.dev.webapi for updates.

The remainder of this document has some historical information about Web Activities.

Previous Implementation

This document provides a high level overview and status of Web Activities as of Feb 1 2012.

For recent efforts see: WebActions and WebAPI/WebActivities.

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.

The API documentation still lives in the OWA repository at https://github.com/mozilla/openwebapps/blob/develop/docs/ACTIVITIES.md but will move into the activities repository soon.

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.

https://wiki.mozilla.org/Privacy/Reviews/F1A

https://wiki.mozilla.org/File:MediatedActivities.png

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)
• WebAPI/WebActivities