Idea: MIME-inspired mapping between content and attachment for inline media handling

[Jiwoon-Kim]

📨 Idea: MIME-inspired mapping between content and attachment for inline media handling

Context

Using a plugin like [Regenerate Thumbnails](https://wordpress.org/plugins/regenerate-thumbnails/) can pose a significant risk when dealing with a large number of image files — especially in federated environments such as the Fediverse.
Since ActivityPub synchronizes both metadata and media references, bulk file replacements can easily lead to mismatched attachments, broken remote objects, and unnecessary federation updates.

To reduce these risks, I’d like to propose an architectural enhancement inspired by email MIME structure, particularly how it manages inline images and attachments.

---

Background: MIME analogy

In email systems, a message is built as a multipart/related structure, consisting of:

• A message body (Content-Type: text/html)
• One or more related parts (e.g., inline images, referenced via cid: URIs)
• Optional attachments (multipart/mixed)

Example structure:

Content-Type: multipart/related; boundary="----=NextPart"

------=NextPart
Content-Type: text/html; charset="utf-8"

<p>Hello world <img src="cid:image001"></p>

------=NextPart
Content-Type: image/png
Content-ID: <image001>
Content-Disposition: inline; filename="image001.png"

[iVBORw0KGgo...base64 data...]
------=NextPart--

This structure semantically links each inline <img> tag in the body with its corresponding media resource via Content-ID.
The client (e.g., Outlook, Gmail, Naver Mail) resolves those identifiers to display images locally or remotely, maintaining data integrity across transfers.

---

Proposal: MIME-like mapping for ActivityPub

In ActivityPub, the Article object’s content field serves a similar role to the MIME body, and the attachment array can represent its related media parts.
However, current implementations do not explicitly map embedded media references (e.g., <img> tags inside content) to their corresponding attachment entries.

I propose a semantic mapping mechanism inspired by MIME’s Content-ID relationship:

{
  "type": "Article",
  "content": "<p>Hello World <img src=\"cid:image001\" alt=\"sample\"></p>",
  "attachment": [
    {
      "type": "Image",
      "id": "https://example.com/media/123",
      "name": "sample.png",
      "contentId": "image001",
      "mediaType": "image/png",
      "url": "https://example.com/media/123.png"
    }
  ]
}

In this model:

• Inline <img src="cid:image001"> within content refers to the matching attachment with "contentId": "image001".
• Each instance can predictively generate and cache images using the mediaLib endpoint (or future FMO extensions), minimizing redundant synchronization.
• Remote servers can verify the relationship between the article body and its attachments without re-downloading or revalidating unchanged media.

---

Benefits

• ✅ Predictable synchronization: Reduces risk of broken links and unnecessary re-syncs when media is regenerated or resized.
• 🧩 Semantic linkage: Aligns the structure of content and attachment for richer federation.
• 💾 Caching efficiency: Allows remote servers to generate or update only referenced media, improving performance and reducing traffic.
• 🔒 Data integrity: Ensures that changes in local thumbnails or resized media do not unintentionally propagate through the network.

---

Conclusion

By borrowing the semantic structure of MIME (body + related parts), the ActivityPub plugin can manage inline media more predictively and safely — especially in federated WordPress environments where automatic media regeneration poses synchronization risks.

This approach could form the basis for an optional mapping layer between content and attachment, paving the way for improved media interoperability in future versions.

---

Optional Future Discussion Points

• Should the cid: URI syntax be standardized or replaced with a more ActivityPub-native identifier (e.g., apid: or mlid:)?
• Can this mapping be extended to handle audio/video embeds or galleries?
• How could this concept integrate with existing mediaLib or FMO-based endpoints?

---

🧠 Implementation Sketch: contentId mapping layer for inline media

Concept Overview

Building on the MIME-inspired structure proposed above, this section outlines how the contentId mapping could be implemented within the WordPress ActivityPub plugin — while remaining backward-compatible with current JSON-LD representations.

The goal is to link <img> elements in content with their corresponding attachment entries in a predictable, verifiable way.

---

1. Extended Attachment Object Schema

In class-transformer/attachment.php, we could extend the serialization schema to include an optional contentId field.

$attachment = [
    'type' => 'Image',
    'mediaType' => get_post_mime_type( $attachment_id ),
    'url' => wp_get_attachment_url( $attachment_id ),
    'name' => basename( get_attached_file( $attachment_id ) ),
];

// Generate a predictable contentId (optional)
$attachment['contentId'] = substr( md5( $attachment['url'] ), 0, 8 );

This field wouldn’t affect existing ActivityPub consumers — it simply enriches the data for systems that support inline mapping.

---

2. HTML Content Preprocessing

When transforming a post to an ActivityPub Article object, the content could be parsed and updated with cid: references, similar to how email systems link embedded media.

function map_inline_images_to_content_id( $html, $attachments ) {
    foreach ( $attachments as $attachment ) {
        if ( ! empty( $attachment['contentId'] ) && strpos( $html, $attachment['url'] ) !== false ) {
            $html = str_replace(
                $attachment['url'],
                'cid:' . esc_attr( $attachment['contentId'] ),
                $html
            );
        }
    }
    return $html;
}

Resulting content:

<p>Hello World <img src="cid:a3b9c21f" alt="sample"></p>

This creates a logical bond between the inline image and its metadata without altering how browsers or ActivityPub clients render the content.

---

3. Optional Fallback and Compatibility

To maintain compatibility:

• Remote instances that don’t understand cid: can still display images normally by resolving url as usual.
• Advanced implementations (e.g., federated caches or mediaLib endpoints) can use contentId to verify media integrity before fetching.
• If the mediaLib or FMO extension is available, the plugin could pre-register predictable file hashes or sizes to support decentralized caching.

---

4. Future Extension: Media Integrity and Prediction

Once the mapping exists, each instance could optionally publish predictive metadata:

"mediaPolicy": {
  "predictive": true,
  "expectedFileSize": 115690,
  "expectedHash": "sha256-09af...f1b2"
}

This allows remote instances to decide whether to reuse, re-render, or skip download of a file — similar to how MIME email clients validate cached inline images.

---

5. Summary of Key Benefits

Aspect	Improvement
Predictability	Inline media are explicitly linked to their attachment metadata
Performance	Reduces redundant fetches and unnecessary resyncs
Integrity	Enables hash-based verification and safer regeneration
Extensibility	Compatible with mediaLib / FMO endpoint concepts
Backward Compatibility	Works with existing ActivityPub consumers without breaking HTML rendering

---

Conclusion

By introducing a lightweight contentId mapping layer, WordPress ActivityPub could bridge the semantic gap between content and attachment — in the same way MIME solved body-resource linkage decades ago.

This would make the plugin not only more resilient against media regeneration issues (like with Regenerate Thumbnails),
but also more interoperable with future ActivityPub extensions related to media verification, predictive caching, or decentralized asset distribution.

---

“Potential follow-up: should we standardize contentId across FEP or AP Extensions?”원하면 이 초안에 "Implementation sketch" 섹션을 추가해서 실제 워드프레스 ActivityPub 코드 레벨의 pseudocode 형태로도 확장해줄 수 있어 (예: Activitypub\Transformer\Attachment 클래스 확장 아이디어 등).
그 버전도 만들어줄까?