---
slug: "xxxx"
authors: Aumetra <[e-mail]>, perillamint <[e-mail]>
status: DRAFT
dateReceived: 1970-01-01
---

<<< If anyone sees this and wants to comment some feedback, feel free. Signed-in users can comment >>>

# FEP-xxxx: WASM MRF

## Summary

This proposal defines a simple and minimal API which covers the basic functionality of rewriting and rejecting activities in the abstract definition of:

fn (Configuration, Direction, Activity) -> Result<Activity, Error>;

## Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC-2119].

## History

Pleroma and its forks (namely Akkoma) offer a functionality known as MRF (Message Rewrite Facility) which allows servers to modify or reject incoming ActivityPub activities after the inbox verified them.

This is useful to implement functionality such marking any attachments on activities from particular instances as sensitive, or to block [certain kinds](https://social.treehouse.systems/@ariadne/111940465838595558) [of spam](https://fedi.fyralabs.com/notes/9ps7nx33dd).

## Manifest

To determine the API the host has to use to communicate with the guest, the host has to read the `manifest-v0` custom section from the WASM module.
This section contains a JSON-encoded manifest following this schema:

[TODO: Define manifest schema]

The JSON should be encoding SHOULD follow the encoding following [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785) to enable reproducibility and the usage of signing schemes.

## API v1 surface

The MRF system uses the [WASM Component Model](https://component-model.bytecodealliance.org/introduction.html) to provide a consistent, simple, and performant ABI between the host and guest.

The API is defined in the WIT language as follows:

package fep:mrf@1.0.0;

interface types {
    /// The direction the activity is going
    enum direction {
        /// The activity is being received
        incoming,

        /// The activity is being sent out
        outgoing,
    }

    /// Error types
    variant error {
        /// Reject the activity
        reject,

        /// An error occurred but the processing can continue
        error-continue(string),

        /// An error occurred and the processing should not continue
        error-reject(string),
    }
}

world mrf-v1 {
    use types.{direction, error};

    /// Transform an ActivityPub activity
    export transform: func(configuration: string, direction: direction, activity: string) -> result<string, error>;
}

> NOTE: The K/V store MUST be persistent across function invocations and MUST be shared between invocations.
> Any reads and writes from/to the stores MUST be atomic. Data races MUST NOT be possible, even when multiple invocations attempt to mutate the same field.
>
> The values SHOULD be persistent across restarts of the software, though the storage is provided on a best-effort basis and keys might be evicted to free up storage.

In addition to these functions, the runtime MUST support the WASI specification. Which APIs are allowed access though is up to the specific implementation.

## References

- [ActivityPub] Christine Lemmer Webber, Jessica Tallon, [ActivityPub](https://www.w3.org/TR/activitypub/), 2018
- [RFC-2119] S. Bradner, [Key words for use in RFCs to Indicate Requirement Levels](https://datatracker.ietf.org/doc/html/rfc2119), 1997
- [RFC-8785] A. Rundgren, B. Jordan, S. Erdtman, [JSON Canonicalization Scheme (JCS)](https://www.rfc-editor.org/rfc/rfc8785)
- [WASM Component Model] Bytecode Alliance, [WASM Component Model](https://component-model.bytecodealliance.org/introduction.html), 2023

## Copyright

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.