Message delivery

ActivityPub provides a robust delivery mechanism for AS2 objects. To send an object to others on the network, a user POSTs a Create activity to their own outbox property with the addresses of the recipients in the to or cc properties. The sending actor's server adds an id property to the activity and the object and stores the object before forwarding it to the recipients across the federation protocol.

MLS data is structured in a binary format and includes detailed encryption and signature fields. For this reason, the MLS wire formats are preserved in AS2 objects with mediaType set to message/mls.

Each of the five MLS wire format structures has an equivalent data type defined as an AS2 extension in the MLS context: PublicMessage, PrivateMessage, Welcome, GroupInfo, and KeyPackage.

Because managing group membership is an essential part of the MLS protocol, delivery of MLS objects over the ActivityPub network requires addressing all recipients explicitly. Only actors can be recipients. Clients must not address MLS messages to collections, such as to the actor's followers collection or to the as:Public collection. See Privacy considerations for more details.

Reading incoming messages is done through the actor's inbox property. This is a collection of all activities received by the actor,including but not exclusive to activities related to MLS. ActivityPub does not support push notifications, so MLS-enabled ActivityPub clients have to periodically poll the inbox collection for new activities.

Other activities in the object lifecycle, such as reactions, updates, or deletions, should be handled as part of the application data within MLS private messages, and not as regular ActivityPub activities. So, for example, creating and updating an encrypted Note is modeled as two Create activities -- one for the creation, the second for the update.

Key storage

Each actor in the ActivityPub network has a public profile with important protocol properties defined, such as inbox, following, and preferredUsername.

The set of currently valid KeyPackage objects for an actor are an additional property of the actor object, keyPackages. Its value is an ActivityPub Collection of KeyPackage objects.

A KeyPackage object for an actor goes through 4 steps in its lifecycle:

1. Create to create the object
2. Add to add it to the collection of valid key packages
3. Remove to remove it from the collection
4. Delete to delete it and make it unavailable

Create and Add must occur in that sequence; it's not possible to add a KeyPackage before creating it. Removal and Deletion are less strictly ordered; a key package can be removed first and deleted later, or vice versa.

The generator property can be used to identify the client application associated with the KeyPackage.

As with all ActivityPub objects, the KeyPackage can be read in full using an HTTP GET request to the id URL.

Content objects

The Activity Vocabulary defines several document types for content. The following types are used in this specification.

• Note - for short text, about a paragraph or less, like a microblogging post or a comment
• Article - for longer texts, about the length of a magazine article or a blog post
• Image - two-dimensional images, like photos or diagrams
• Audio - any sound files, like music, a sound effect, or a podcast episode
• Video - moving images, like a movie, TV show, or short

• id. This should be a unique URI, but not an HTTPS URL. A UUID, for example, provides a reasonably unique value that can be indexed in the client's local storage.
• mediaType. For Note and Article, these should be unset, or use the default "text/html". For the other content types, this should include the Internet Media Type for the object, such as "image/png" or "video/ogg".
• encoding. A new property introduced in this document; the default value is "base64", for base64 encoding.
• content. For Note and Article, this should be the HTML content of the object, as usual. For the other types, this should be the base64-encoded content of the object itself. For an Image in Portable Network Graphics (PNG) format, the content property value will be the base64-encoded image data.
• summary. A summary or description of the content.
• url. This should be undefined; the object should not have a version available as a Web page.
• attachment. These values should not be Link objects; instead, they should be content objects of the above types. They should be included fully using base64-encoded values in the content property, with the mediaType property set.
• inReplyTo. Should be the id of a content object already delivered to the same group.
• replies, likes, and shares. In this application of MLS, reactions to content objects are not tracked by a server, but by each client individually. Consequently, these values should be unset.
• attributedTo. This can be derived from the properties of the ActivityPub envelope and are not required. If provided, it should be ignored.
• to, cc, and other addressing properties. These can be derived from the properties of the ActivityPub envelope and are not required.
• tag. Mention and Hashtag object ids can be used to identify topics or mentioned actors.

Activities

Activities are the top-level content in MLS messages.

The following Activity types from the Activity Vocabulary are defined in this document.

• Create Introduces a new object. The value of the object property should be a node object -- all properties represented as a JSON object. The id of the object must be unique.
• Update Updates the properties of an existing object.Only changed properties must be included in the object property. The id property must match an object that was received as the object of a Create property previously. Only the sender of the Create activity can send an Update for the same object.
• Delete Deletes an existing object. The object property can be a node object or a reference. The id property must match an object that was received as the object of a Create property previously. Only the sender of the Create activity can send an Delete for the same object.
• Like Indicates that the sender likes the object. The object property can be a node object or a reference. The id property must match an object that was received as the object of a Create property previously.
• Announce Shares the object with the group. The object property can be a node object or a reference. The id property can match an object that was received as the object of a Create property previously; alternately, it can be an ActivityPub object with an HTTPS URL id. The latter case allows sharing public content into a private chat for discussion, possibly with a comment.
• Undo Undoes the activity that is the object. The object property can be a node object or a reference. The id property must match an activity that was received previously. Only the sender of the previous activity can undo it. Undoing a Like activity shows that the sender does not like the object. The results of undoing other activity types are undefined.
• Read. Indicates that the sender has read a Note or Article, or the description of an Image or other binary file type. The object property should be a partial embedding or a reference. The id property must match an object that was received as the object of a Create property previously. (Read is an activity type from the Activity Vocabulary that is not described in detail in the ActivityPub specification.)
• Listen. Indicates that the sender has listened to an Audio object. The object property should be a partial embedding or a reference. The id property must match an object that was received as the object of a Create property previously. (Listen is an activity type from the Activity Vocabulary that is not described in detail in the ActivityPub specification.)
• View. Indicates that the sender has viewed an Image object or Video object. The object property should be a partial embedding or a reference. The id property must match an object that was received as the object of a Create property previously. (View is an activity type from the Activity Vocabulary that is not described in detail in the ActivityPub specification.)
• IntransitiveActivity. This is a base activity type defined in the Activity Vocabulary. For this specification, an IntransitiveActivity object can be sent as a null message, which can obscure messaging patterns (see Metadata leakage). Recipients should ignore and discard the activity. (IntransitiveActivity is an activity type from the Activity Vocabulary that is not described in detail in the ActivityPub specification.)

Extensions

Other activity or content types from the Activity Vocabulary, and from Activity Streams 2.0 extensions, may be used in this structure. The use of extended properties or types in the encrypted content of MLS over ActivityPub should be documented on the W3C wiki.

Version-stamped URLs

To ease the use of this context for implementers with strict versioning requirements, additional URL aliases are provided with versions included. A semantic versioning strategy is used to convey the guarantees of the version number.

Using the version-stamped context URLs is similar to the unstamped URL.

If backwards-incompatible changes to this context are made in the future, a new major version (2.x.x) would be added and the existing 1.x.x URLs would continue to be provided.

Types

There are five types defined in this context.

Properties

There are two properties defined in the namespace.

HTML Sanitization

Many of the content types included in the application data for this specification use HTML either for the summary or content properties. Attackers can use features of HTML5, like JavaScript and CSS, to cause problems in the users' browsers. One mitigation is to sanitize the HTML, removing elements and attributes that can be problematic for users.

In ActivityPub, many servers will sanitize HTML for content as it arrives at the server, so that clients can use the content without security concerns. Because the encrypted application data in this specification is not visible to the ActivityPub server, it is up to the client application to sanitize the HTML.

Key Substitution

The keyPackages collection used in this document for sharing and confirming cryptographic keys is easy to implement and use. However, because the collection is managed by the actor's server, the collection is subject to a key substitution attack. A malicious server can add one of its own keys to the collection, or replace one of the keys with its own. Sophisticated attackers would present different keyPackages collection contents to different clients.

One mitigation for this attack is key-fingerprint verification, in which participants in a group compare the fingerprints they see for keys for an identity.

Private key storage

The private keys created by clients and used for encryption and signatures in the MLS framework are crucial to the security of the system. Compromise of the key through physical or remote access to the device could expose encrypted data in the server-stored messages. To mitigate this risk, client applications should make use of platform services for secure key storage where available. If keys must be stored on disk, they should be encrypted with a password under the user's control.

Plaintext storage

Rebuilding group state and decrypted message content from server-stored MLS message data in the inbox can be time-consuming. Therefore, many clients will persist that state and decrypted content on the client side. But physical or remote access to the client device could expose that decrypted content to an attacker.

One mitigation for this risk is to store decrypted content locally in an encrypted file or drive volume, with the encryption key stored in the platform's secure storage, or with a password under the user's control.

Metadata leakage

The binary MLS objects used in this specification have strong encryption to protect the contents from servers. The ActivityPub envelopes used for their delivery, however, can be inspected by servers along the delivery path -- the sending actor's server and the receiving actors' servers.

There is metadata in the envelopes that can be used by an observer to draw conclusions about the conversations.

• Sender and recipients. These addressing properties are necessary for the delivery of ActivityPub objects.
• Timestamps. Timestamps are added by the sender's server and forwarded to other servers. They can be used to analyse patterns in the conversation. One mitigation is to add random dummy messages with the IntransitiveActivity activity type (see above), which can obscure the real patterns in conversations.
• Message size. The size of the PrivateMessage objects can give a signal for what the contents of the message are. For example, a Like activity which uses the object's ID URI as a property value would be smaller than a Create activity with an embedded node object as the object property value. MLS provides padding feature to mitigate this problem.