Proposal: Inline gzip compression for attachments in encrypted AP messages

When sending attachments inside MLS-encrypted ActivityPub messages, there is no separate attachment files, the bytes must travel inline in the encrypted payload. I'd like to propose a simple convention for compressing the file contents when appropriate.

Payload format

{
  "type": "Document",
  "name": "proposal.md",
  "mediaType": "text/markdown",
  "encoding": "gzip",
  "content": "<base64(gzip(raw bytes))>",
  "size": 204800
}

• encoding: "gzip" signals that content is gzip-compressed bytes, which are in turn base64-encoded (already defined in spec as the default, though we could also use encoding: "base64-gzip" or base64+gzip for clarity)
• size: uncompressed byte count (optional)

Rationale

• Gzip typically gives 50-80% size reduction for media not already compressed
• Base64 overhead (~35%) can be partially offset by compression

Note: Senders SHOULD skip compression for formats that are already internally compressed (JPEG, MP4, MP3, ZIP, etc.), while they MAY apply compression for uncompressed formats (WAV, BMP, text, etc.).

Receiver behaviour

On decryption, clients encountering encoding: "gzip" on an attachment SHOULD (or ideally MUST) base64-decode and decompress content before processing. Implementations that ignore encoding will receive garbled bytes, so this feels like a MUST, but I'd like input from the community on the approach.

Start by reviewing the payload format and receiver behaviour described in issue #69, including the gzip, base64, encoding, and size requirements. Compare the proposed sender and receiver conventions with the existing ActivityPub E2EE message specification, if available in the repository. Done means the community has agreed on the encoding convention and its sender and receiver requirements.