WordPress ActivityPub S2S Media Delivery System Redesign and Improvement Plan: Strategy for Secured Pull Model Adoption #2377
Replies: 4 comments 3 replies
-
|
Yes, here is a concrete example code modifying the The key change is adding the unique WordPress attachment ID ( File to Modify:
|
Beta Was this translation helpful? Give feedback.
-
|
The entire example code modified by adding the standard File to Modify:
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, as requested, I have modified the code so that the This modification complies with the ActivityStreams standard.
File to Modify:
|
Beta Was this translation helpful? Give feedback.
-
WordPress Zero-Sideload Federated Media Reference (ZFMR) Architecture ReportI. Introduction and Overview of the ZFMR Framework1.1. The Current Challenge: WordPress Media Handling in the Fediverse Environment In decentralized social networks, the general method of media exchange relies on copying the binary file itself to the consuming instance and aggressively caching it locally — a process known as sideloading. While this method is simple to implement, it weakens the authority of the original media owner and is inefficient in terms of resource utilization. The core objective of this framework is to evolve WordPress’s native attachment post from a simple local file reference into a globally addressable, fully functional ActivityStreams 2 (AS2) object. The current ActivityPub plugin implementations for WordPress mainly focus on integrating standard blog posts (AS2 Note objects) and related comments.¹ To enable independent and direct commenting functionality on media items — for example, images — the corresponding attachment posts must be formalized as independent AS2 entities. This architectural requirement arises from the fact that the core ActivityPub specification does not define media handling in detail, which has led to the emergence of Federation Enhancement Proposals (FEPs) such as FEP-1311, aiming to document and standardize currently used methods and best practices.² 1.2. Overview of the ZFMR Architecture The proposed Zero-Sideload Federated Media Reference (ZFMR) architecture consists of three interdependent core components designed to achieve maximum efficiency and protocol compliance:
1.3. Key Implications and High-Level Impact Adopting a zero-sideload approach represents a significant architectural policy decision. By not caching binary files locally, the instance establishes a trust model that depends entirely on the persistence and availability of the remote host for content delivery. While this optimizes local resource usage, it introduces the drawback of increased external dependency risks. For a media item to be commentable, it must be constituted as an independent Object owned by an Actor (the original author or blog instance) and possess its own inbox, separate from that of the parent Note object. This means that the lifecycle and interaction graph of the media object must be distinct from those of the parent post that includes it. II. Protocol Compliance and First-Class Media ObjectsThis section examines the fundamental requirements derived from AS2 and FEP specifications necessary to validate media objects as independent, commentable entities. 2.1. Mapping WordPress Attachment Posts to Commentable ActivityStreams Objects To facilitate direct commenting functionality on media, a WordPress attachment post must satisfy the basic AS2 criteria for an independent object. Specifically, all non-transient ActivityStreams Objects must possess an The architectural mapping designates the permalink of the WordPress attachment post (CPT entry) as its canonical AS2 ID. The internal WordPress Post ID functions as a persistent database key for tracking this external AS2 identifier. A media object is generally serialized as an AS2 Image type, but it must comply with all standard attributes required for a commentable object — including 2.2. Deep Analysis of FEP-1311: Addressability Requirements for Media Attachments FEP-1311 was specifically developed to address deficiencies and implementation gaps regarding media handling in the base ActivityPub specification.² Its core requirement is independent addressability of media attachment objects — meaning that an image possesses its own unique address and lifecycle, distinct from the post (Note) it’s attached to. This structure allows federated platforms like Mastodon or Pixelfed to display images and provide contextual menus that guide users to comment threads specialized for the image itself, separate from the Note thread containing it. The evolving AS2 specification demands continuous vigilance during implementation. Discussions such as the proposed erratum in Example 79 of AS2, which concerns the placement of attributes like 2.3. The Need for a Dedicated Media Collection Endpoint To allow remote instances to efficiently discover and query media objects published by a given WordPress instance (Objective 2), that instance must expose a dedicated collection endpoint. ActivityStreams defines the concepts of Collection and OrderedCollection to structure and traverse large object sets.⁴ A new REST endpoint (e.g., registered under A crucial design consideration arises from the distinction between internal and external identifiers. WordPress uses the same internal identifier (WP_Post ID) for both the metadata and file reference of a media object. During federation, this internal ID must serve either as (a) the AS2 ID for locally owned, commentable content, or (b) a local stub referencing remote content. The ZFMR system thus requires a sophisticated internal lookup mechanism capable of precisely tracking and distinguishing between locally authored media (which generate new AS2 IDs) and federated media objects (FMOs) that store and utilize remote AS2 IDs. III. Federated Media Object (FMO) ArchitectureThis section details the mechanisms by which the separation of metadata (object cache) and binary data (file cache) achieves the zero-sideload objective. 3.1. Definition of the Federated Media Object (FMO) Custom Post Type (CPT) An FMO serves as a local database record managing all metadata associated with remote media references. Its primary role is to persist essential metadata without downloading or storing the associated binary file (zero-sideload). To manage this complex data cleanly, it is recommended to define a dedicated Custom Post Type (e.g., Required FMO CPT Metadata Fields
FMO establishes a dual-layer persistence model that clearly distinguishes between metadata handling and binary data handling: FMO Dual-Layer Persistence Model
3.2. Implementation Strategy for Zero-Sideloading To create an FMO, the default WordPress media ingestion process — designed for file transfers — must be actively bypassed. Remote image ingestion normally uses functions such as Implementation involves registering a custom filter (executed before Because a standard WordPress attachment post expects a physical file path, potential points of failure arise. Since FMOs are processed in a zero-sideload manner, this file path will be absent or contain a placeholder value. When core WordPress functions attempt to access a file based on the local FMO ID, they will fail. Thus, the ZFMR framework requires extensive filtering (e.g., hooks for 3.3. Discovery and Indexing of Remote Media Libraries To allow local authors to select remote media, the WordPress instance must be capable of querying and indexing remote media collections. This discovery involves a federated lookup where the local Actor sends an authenticated request to the remote Actor’s defined During this indexing process, the local instance iterates through remote AS2 media objects, extracting their Although zero-sideloading is the primary objective, a robust system must account for failure scenarios. If a remote server becomes persistently unavailable, the content integrity for local readers could be jeopardized. The FMO CPT should ideally include a status flag ( IV. Local Post Federation and Remote URI Integrity Mechanism (Objective 3)Ensuring that outgoing Activity payloads correctly reference the original remote media object’s URI is the most critical step in achieving zero-sideload compliance. 4.1. Outgoing Activity Control: Attachments Filter When a local WordPress post is published as an AS2 Note object and federated, associated attachments (local files or FMO stubs) must be serialized into the Note’s The core goal is to enforce the user’s requirement that the URI in the federated payload should point to the original remote media object rather than a local cache or stub. 4.2. Utilizing the The The implementation performs the following essential transformations:
This systematic substitution ensures that the ActivityPub serializer treats the referenced item as an external, dereferenceable AS2 object URI, not a local resource. Consequently, the Standard AP implementations tend to optimize for faster lookups by internally using local database IDs (CPT IDs) instead of continually relying on remote URIs.⁸ Therefore, the ZFMR architecture must maintain a strict internal/external ID translation layer — that is, FMO ID (internal DB key) ↔ Remote AS2 ID (federated URI). The 4.3. Secure Dereferencing and Validation of Remote Media Objects Referencing external remote URIs inherently introduces reliability and security concerns. ActivityPub mandates that receiving servers dereference linked objects to verify their validity and existence, preventing spoofing.⁴ To manage these risks, the FMO architecture must validate remote objects during initial ingestion, potentially storing the signature or hash of the original AS2 object payload. If the remote AS2 object is transient or malformed, the entire federation process must fail for that attachment — making this validation essential. Additionally, the local instance should maintain a trust policy that allows zero-sideload referencing of media only from trusted domains/Actors, enforcing full local sideloading or rejection for untrusted sources. Finally, when a user chooses to include an FMO in a new post, the WordPress block editor interface must be able to browse indexed FMO CPT entries, allowing selection of federated media directly without local file storage. Perfect — I’ll now translate only this final section (V–VII) literally, keeping every markdown heading, numbering, punctuation, and line break exactly as in your Korean text. V. Enabling Direct Media Commenting and Interaction Routing (Goal 1)For a media object to actually be commentable, the local instance must be able to receive and correctly route inbound Activity streams that target the URI of the FMO. 5.1. Handling inbound Create (Note) activities targeting the media object URI When an inbound Create activity representing a remote comment arrives in the inbox of the local Actor, the system’s routing logic must inspect the If the inReplyTo value matches the canonical URI of the local FMO (the attached post ID URL), the activity is routed specifically to that FMO. The comment payload (the remote Note) is then persisted in the WordPress comments table, but the 5.2. Routing Fediverse interactions to the FMO All other forms of federated interactions that reference the authoritative URI of an FMO — such as Like and Announce activities — must follow the same mapping logic and be routed to the local WP Post ID of the FMO. This guarantees that engagement specifically targeting the media object, rather than the context in which it appears (as reflected by interaction metrics 9 displayed via tools like the Webmention plugin or Fediverse Reactions block), is accurately represented. An essential consequence of this architecture is the strict separation of comment threads. When a user comments directly on a media object (FMO), that interaction must remain isolated and must not automatically merge with the thread of the post containing the media. Siloing comments on the dedicated attachment page of the FMO satisfies the core premise of FEP-1311 — object-centric, independently commentable media entities. 5.3. Displaying federated interactions in the WordPress attachment page template To present these interactions to local users, the default WordPress attachment page template (e.g., VI. Architectural Optimization and Interoperability ConstraintsThis final section reviews implementation trade-offs, optimization strategies, and key aspects of interoperability. 6.1. Essential refinement proposal: Transient FMO vs. Persistent FMO Creating a full CPT entry for every remote reference may lead to database bloat when many transient external links are involved. The persistence policy for FMO creation must be improved. This refinement directly relates to ongoing discussions 10 about conditional persistence based on the stability of AS2 IDs. 6.2. Interoperability analysis: precedents in Fediverse media handling Efficient federation requires a balance between strict AS2 standard compliance and the nuanced differences of real-world implementations. The architectural design must explicitly account for the risk that platforms such as Mastodon may fail to parse strictly defined, up-to-date AS2 formats correctly. 2 6.3. Advanced security: content delivery policies and trust model The no-proxy policy shifts the burden of content delivery to remote servers, requiring careful consideration of Content Delivery Networks (CDN) and Cross-Origin Resource Sharing (CORS) policies. Furthermore, referencing large quantities of remote media may inadvertently expose source servers to Denial-of-Service (DoS) risks. VII. Conclusion and Step-by-Step Implementation Roadmap7.1. Summary of the optimized architecture The ZFMR framework provides a sophisticated and resource-efficient solution for integrating WordPress media into the Fediverse as first-class, commentable AS2 objects. 7.2. Detailed implementation roadmap Successful deployment requires a phased approach ensuring that the foundational data model is stable before implementing complex network interactions.
|
Beta Was this translation helpful? Give feedback.
-
|
Inspired by FileBird, I think that using an S2S Media Library endpoint could make it possible not only to query collections or individual image objects, but even to transfer them in bulk as a compressed archive. |
Beta Was this translation helpful? Give feedback.
-
|
This is a problem when building block themes, especially if you plan to include a custom attachment template. WordPress doesn’t currently have media blocks that let you dynamically attach data to them (like the current attachment’s ID). |
Beta Was this translation helpful? Give feedback.
-
Specification Report on the Federated Media Architecture for Integration of WordPress, Pinterest, and Misskey Models1. Introduction to the Integrated Media Architecture and Definition of Objectives1.1. Background of Integration: Functional Analysis of WP, Pinterest, and Misskey ModelsThis integration project aims to combine the flexibility of the WordPress core with the advantages of a decentralized media management system and the ActivityPub protocol, which is the standard for social interaction. WordPress’s basic Attachment Model performs the core function of storing metadata for media files uploaded to the local server. In contrast, the Pinterest and Misskey Drive Models focus on user ownership and collection organization. Finally, the ActivityPub Model enables decentralized Activities across all these objects. 1.2. System Architecture Overview: WP Core, Custom Layer, ActivityPub IntegrationThis integrated system utilizes the data management features of the WordPress core while securing scalability through three essential custom layers. The first, Local Media Segregation Layer, implements user-level isolation for the existing attachment post type. The second, Data Modeling & Relationship Layer, defines a remote_media CPT for managing external media objects and a media_board CPT/Taxonomy that groups these objects. The third, Federation & Persistence Layer, processes and stores ActivityPub activities. 1.3. Roadmap for Meeting Key RequirementsThe core requirements for system implementation and their technical strategies are as follows:
2. Data Modeling: Structural Definition of Local, Remote, and Collection Layers2.1. Redefining the Local Media Model (attachment Post Type)WordPress’s default attachment post type stores core metadata of media files, such as the uploader and file path. This taxonomy should be attached to the attachment object using the When users create folders and move files through an interface similar to FileBird or WP Media Folder, what’s actually happening behind the scenes is that the attachment post is being linked to a corresponding folder term. 2.2. Designing a Custom Post Type (CPT) for Remote Media ObjectsTo manage and track interactions (e.g., likes) for external media objects referenced from external URIs such as Pinterest Pins or ActivityPub remote objects, a CPT named The core structure of this CPT is as follows:
In addition, meta fields store the original ActivityPub ID ( The routing strategy for this CPT is critical. In a decentralized federated network environment, ensuring data persistence is essential. To mitigate this, whenever a user “likes” a 2.3. Defining the Collection/Board StructureTo allow users to group media in a Pinterest-style board, define a CPT called For flexibility, this Through this, users can combine their locally uploaded media and externally referenced remote objects into a single logical board, effectively integrating multiple sources into one cohesive collection. 3. User-Specific Local Media Management and Access ControlThe core requirement of this system is to ensure that users can only manage their own media files, while administrators retain global visibility over all media assets — maintaining both security and manageability. 3.1. User-Centric Media Library Visibility Control (WP Admin UI)When non-administrator users access the WordPress media library (in both grid and list views), they must be strictly limited to viewing only their own uploaded files. The key mechanism for implementing this restriction is the In practice, this can be achieved by injecting a conditional query that checks the current user ID. This conditional filtering ensures the principle that:
This rule applies strictly within the admin UI, ensuring data segregation within the management interface. 3.2. Virtual Folder Structure Implementation and Database MappingThe previously defined hierarchical taxonomy When a user creates a folder, this request is translated into the creation of a new taxonomy term under When a user moves a file into a folder, the operation is processed by linking the attachment post and the folder term through the function 3.3. Summary of Media Access Control LogicMedia visibility and access control must be clearly defined on a role-based level. User Media Visibility and Access Control Logic
4. Stable Permalink and Routing System DesignIntegrating user-based virtual folder structures into URLs and establishing SEO-friendly, shareable, and stable permalinks is essential for the system’s long-term reliability.22 4.1. Default Attachment URL Conflicts and ControlBy default, WordPress generates Attachment Pages for There are two main strategies to control this behavior:
The second approach is preferable when aiming to provide a rich media viewer, similar to Misskey Drive. 4.2. User-Based Virtual Media Folder URL StructureThe desired permalink structure should include both the user ID (or slug) and the taxonomy-based virtual folder path.
4.3. Implementation of Custom Rewrite RulesTo map these complex hierarchical URLs accurately to WordPress’s internal query system ( Rule 1: User Media Root and Folder Navigation
Rule 2: Individual Media Item Page
All custom media rewrite rules must be registered with the ‘top’ priority in the 4.4. Preventing URL Conflicts and Managing PrioritiesWhen introducing complex CPT and taxonomy-based URL structures, preventing conflicts is vital for maintaining system stability. The most effective approach is to:
This layered routing design guarantees predictable, non-conflicting, and SEO-friendly URL resolution for both local and remote media resources. 5. ActivityPub Integration: Handling Likes and Collection SynchronizationActivityPub-based federated interactions must ensure that users can perform “Like” actions on both local media (attachments) and external ActivityPub objects (remote_media), while maintaining these within unified collections. 5.1. Interpretation and Reception of ActivityPub 'Like' ObjectsIn ActivityPub, a “Like” activity is a structured message in the ActivityStreams format, transmitted between federated servers through the inbox.6 Within the Like activity message, the 5.2. Database Schema for Storing ActivityPub 'Like' DataFederated networks can generate a high volume of Like activities in a short period of time, and storing them in WordPress’s default Therefore, to ensure scalability and query efficiency for large-scale federated activities, a dedicated custom database table, wp_user_likes Custom DB Table Schema (Optimized for Federation Activities)
5.3. Building a Collection of User LikesUsers should be able to view a collection of all media they have liked within their profile feed. The query logic is composite: 5.4. Local Caching and Synchronization of Remote Media ObjectsWhen a user likes an external media object, its metadata must be preserved in the local system’s Upon receiving a Like activity, if no Additionally, because remote objects can change, when an ActivityPub “Update” activity is received, the 6. Implementation of a Misskey-style Profile Media Feed (Composite User Feed)The goal is to provide a unified, chronologically ordered feed combining a user’s local uploads and liked collections, similar to a Misskey profile’s media feed. 6.1. Template File Structure for Individual User FeedsBy default, WordPress handles user profile pages through This template utilizes query variables passed from the Rewrite Rule defined in Section 4 to fetch and render the relevant content based on username and folder path. 6.2. Optimizing the Unified Feed Query (Union Query Strategy)The unified feed must combine two primary data sources — local uploads (attachments) and liked collections (including remote_media) — ordered chronologically. The most efficient query strategy is as follows:
6.3. UX/UI Considerations: Gallery and Filtering IntegrationThe unified feed should display metadata for both attachment and remote_media objects in a consistent gallery layout. To improve navigation, frontend query-variable-based filtering should be supported. 7. Conclusion and Recommended Implementation Steps7.1. Development Priorities by Core ModuleTo ensure successful integration, development should proceed according to the following phases:
7.2. Performance and Scalability ConsiderationsWhen data volume increases, the following architectural considerations are essential to maintain system performance:
The architecture proposed in this report leverages WordPress’s flexible CPT/Taxonomy system to extend the existing local media management structure into a model inspired by Misskey Drive’s user-specific ownership concept and Pinterest’s collection features, while fully integrating distributed social capabilities through ActivityPub federation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
WordPress ActivityPub S2S Media Delivery System Redesign and Improvement Plan: Strategy for Secured Pull Model Adoption
I. Introduction: C2S/S2S Boundary Analysis and Definition of S2S Media Delivery Issues
I.1. Technical Diagnosis of Current ActivityPub Media Federation
The current WordPress ActivityPub plugin federates media based on the traditional server-to-server (S2S) inbox/outbox pattern of ActivityPub.1 When content is published, the logic that transforms WordPress internal attachment Post Types (Transformer) operates,3 including the media in the attachment property of the ActivityStreams object. This Activity is pushed to the inboxes of all subscribed remote servers.
The key issue with this classic Push model is inefficient bandwidth consumption. As soon as an Activity propagates, all subscriber servers that receive the media URL attempt to download the media file and store it in the local cache. This generates large simultaneous outbound traffic (bandwidth spikes) on the origin server immediately after post publication, regardless of whether the content will actually be exposed to users. Furthermore, the origin server fundamentally cannot precisely control the caching policies or content validity period on receiving servers.
I.2. Analysis of S2S Incompatibility of the C2S uploadMedia Endpoint
The uploadMedia endpoint defined by the W3C Social Web Community Group is designed for client-server (C2S) interactions, where clients POST requests to the server to upload media.4 The specification states that clients must submit media files as multipart/form-data messages, and the server must verify that the client is properly authenticated to accept the request.4
This authentication mechanism is generally based on OAuth 2.0 bearer tokens5 or equivalent user authorization.6 That is, uploadMedia assumes explicit authorization delegation for a user account. In contrast, server-to-server (S2S) communication primarily uses HTTP Signatures5 to verify the server's identity and the integrity of activities. Therefore, applying a C2S-only OAuth-based endpoint to an S2S environment without modification violates the ActivityPub protocol layer's role separation and causes a security model conflict. Since there is no user client authorized to upload media files in S2S communication, using C2S uploadMedia for S2S media delivery is technically inappropriate.
From the technical background of the wider Fediverse ecosystem, ActivityPub C2S specifications explicitly lack or insufficiently address essential features for modern social applications, such as media upload, search, and real-time updates.8 As a result, mainstream Fediverse platforms including Mastodon have historically used custom APIs instead of the standard C2S, causing API fragmentation that hinders client development interoperability.8 Considering this, rather than forcibly adopting standard C2S, WordPress proposing a secure and efficient S2S media resource read API as a new Pull model endpoint—addressing a common gap across the Fediverse—can lead standardization and improve Fediverse interoperability.
I.3. Core Proposal: Introduction of WordPress Attachment ID-Based Secured S2S Media Pull Model
The core proposal of this report is to complement the inefficient Push-based media delivery system by establishing a S2S-exclusive media library Pull endpoint (mediaLib) leveraging WordPress's architectural strengths.
This model includes not only the media file URL but also the WordPress internal attachment Post Type ID in the attachment property of the ActivityPub object. Remote servers, upon receiving an Activity, do not download the file immediately; instead, upon a user request, they send an authenticated S2S GET request with this ID to the mediaLib endpoint. This converts media delivery into a Pull-caching model, maximizing bandwidth efficiency and ensuring long-term data integrity using WordPress internal identifiers.
II. ActivityPub Protocol Boundaries and CMS Structure Utilization
II.1. S2S Value of WordPress Attachment Post Type
In WordPress, attachments are one of the core post types, acting as containers for information about the media file itself.10 These posts persistently store metadata such as file name, description, image dimensions, thumbnails, and location in the wp_postmeta table. The internal identifier (Post ID) serves as a unique reference key that remains unchanged throughout the media file’s lifecycle.
ActivityPub objects must use globally unique URIs as identifiers.5 WordPress generates unique permalink URIs based on internal attachment Post IDs (e.g., integer 17894), such as https://travel-in-busan.com/?attachment_id=17894, and uses this URI as the ActivityStreams object id. This complies with ActivityPub standards.
However, when a remote server calls the proposed S2S mediaLib endpoint (/wp-json/activitypub/v1/actor/{user_id}/mediaLib/{attachment_id}) or receives an Update activity to modify a local object,10 the origin WordPress server must determine which local attachment object is requested in the most efficient manner.
Thus, using a non-standard namespace to include local identifiers has strategic value10 for long-term data consistency management and high-performance Pull model lookup (Direct Lookup). It optimizes communication between WordPress environments and reduces processing overhead for metadata updates and media retrieval.
Additionally, WordPress provides a clear template hierarchy for attachment Post Types, allowing single media pages to be displayed in the order of image-jpeg.html, image.html, attachment.html, etc.11 This indicates that the url property of an ActivityPub object can point to a resource including detailed metadata or a web page, not just a binary file link.
II.2. ActivityStreams Standard Media Object Structure and Role of FEP-1311
ActivityPub is based on the ActivityStreams 2.0 data format, but lacks official specifications for media attachment mechanisms, leading to fragmentation within the Fediverse.12 To address this gap, community efforts like FEP-1311 (Fediverse Enhancement Proposal 1311) have been undertaken, documenting current practices and recommending including structural properties such as width and height in media objects.12
The proposed S2S mediaLib endpoint should return ActivityStreams Image, Video, or Document objects that comply with FEP recommendations. This ensures WordPress media objects maintain high interoperability with mainstream Fediverse platforms.
III. Media Delivery Models: Push vs. Pull Comparative Analysis
To fundamentally improve ActivityPub-based S2S media delivery, the limitations of the traditional Push model must be overcome and a Pull model adopted.
III.1. Model A: Limitations of the Traditional Outbox Push Model
The traditional ActivityPub model posts an Activity including media URLs to the inbox of all subscriber servers whenever a new Activity occurs.5 While this guarantees immediate delivery, it contains the following critical inefficiencies:
III.2. Model B: Necessity of the S2S Media Library Pull Model
The S2S Pull model converts media delivery into a web-standard caching architecture.
Similarity to CDN architecture: This approach resembles the operation of Pull CDNs (Origin Pull CDN). Rather than the content owner directly uploading (Push) files, the CDN retrieves files from the origin server upon user requests (Cache Miss).13 Pull is simple to configure and transmits content only when actual traffic occurs, increasing efficiency.14
ActivityPub standard compliance and efficiency: ActivityPub specifies respecting HTTP caching mechanisms.5 Push models have lax control over standard caching, but adopting the S2S Pull model allows the origin server to dictate media validity periods and revalidation logic directly via HTTP response headers (e.g., Cache-Control, ETag). This gives the origin server authoritative caching control and maximizes network efficiency. Transitioning to the Pull model is a key step in converting inefficient protocol pushes into a web-standard-based, efficient CDN-like architecture.
The following table summarizes the key functional differences between the two models, supporting the rationale for redesigning the media delivery system.
Functional Comparison of Push vs. Pull Media Delivery in Fediverse
IV. Proposed Specification: S2S mediaLib Endpoint Design
To implement the S2S Pull model effectively, the WordPress ActivityPub plugin must establish a dedicated S2S mediaLib endpoint prioritizing security and standard compliance.
IV.1. Endpoint Definition and ActivityStreams 2.0 Mapping
The proposed endpoint is
built atop the WordPress REST API layer, providing access to a specific user’s media library.
IV.2. Security Implementation Details: Mandatory S2S Authentication via HTTP Signature
The greatest threat in the S2S Pull model is a remote server repeatedly requesting large amounts of media to perform a denial-of-service (DoS) attack on the origin server. Therefore, all GET requests to the S2S mediaLib endpoint must undergo strict server-to-server authentication.
HTTP Signature requirements: ActivityPub specifies the possibility of using HTTP Signatures in S2S communication.5 By enforcing this signature mechanism on GET requests to the S2S mediaLib endpoint, ordinary file requests are transformed into Authorized Media Retrieval protocol interactions.
Authentication and access control process:
Applying HTTP Signatures to GET requests ensures media access occurs only within the legitimate Activity context at the protocol level, significantly mitigating DoS attack risks.
IV.3. Inclusion of WordPress-Specific Attributes and Caching Strategy
WordPress ID integration: Non-standard namespaces should be used in ActivityStreams objects to include the WordPress internal attachment ID (e.g., "wp:attachmentId": 1234). This metadata improves data integrity and media management efficiency between WordPress environments.
Use of standard HTTP caching headers: To maximize Pull model efficiency, mediaLib responses must include robust HTTP caching headers.
Active use of these caching headers satisfies W3C ActivityPub specification requirements while optimizing S2S media transmission.5
V. Implementation Roadmap and Future Scalability
Transitioning S2S media delivery to a Pull model requires a gradual approach and should contribute to Fediverse standardization in the long term.
V.1. Phase 1: Transformer Improvement and ID Integration (Immediate Goal)
The first task is establishing the foundation for data consistency. Modify the existing class-attachment.php Transformer logic3 to include the WordPress Post ID in all federated ActivityStreams media objects using a non-standard namespace. This step lays the groundwork for leveraging WordPress internal data as metadata in federated objects before the actual mediaLib endpoint is built.
V.2. Phase 2: Security Enhancement and Initial S2S mediaLib REST Endpoint Implementation (Mid-Term Goal)
The next step is to construct the Pull endpoint with security mechanisms.
This step enables testing Pull model functionality in a secure environment and validating bandwidth efficiency compared to the Push model.
V.3. Phase 3: Interoperability Enhancement and Advanced Media Feature Integration (Long-Term Goal)
The long-term goal is to maximize the efficiency of the S2S Pull model and drive standardization.
Media Deduplication (Content Addressing): As an advanced feature to improve efficiency in ActivityPub systems, consider adding file hashes to media objects (e.g., digestMultibase property). This allows receiving servers to check if identical content is already cached and avoid redundant downloads, fundamentally reducing network traffic.7
Fediverse Standard Proposal: If WordPress successfully implements and operates the Pull model, demonstrating its efficiency and security, this mediaLib model can be formally proposed as a FEP (Fediverse Enhancement Proposal), guiding the standardization of media Pull mechanisms. This positions WordPress not merely as a follower but as a protocol innovation leader in the Fediverse ecosystem.
VI. Conclusion and Recommendations
The WordPress ActivityPub plugin’s media delivery system must clarify the role separation of C2S and S2S protocols and transition to a Pull model optimized for S2S communication. The traditional Outbox Push model suffers from bandwidth inefficiency and lack of caching control, making it unsuitable for large-scale CMS environments.
Final Recommendations:
This redesign leverages WordPress’s architectural strengths and combines them with ActivityPub’s standardized security model, providing the most efficient, secure, and scalable media federation pathway.
References
Beta Was this translation helpful? Give feedback.
All reactions