[Feature Idea] Exploring Multicast-like and Gossip-based Mechanisms for ActivityPub Instance Discovery and Federation within Controlled Networks

[Feature Idea] Exploring Multicast-like and Gossip-based Mechanisms for ActivityPub Instance Discovery and Federation within Controlled Networks

>Disclaimer: I have some ideas, but I’m not deeply familiar with this area of networking protocols, so I wasn’t able to fully verify whether any parts of this might be hallucinations or unrealistic assumptions. Please take this as a speculative concept for how the WordPress ActivityPub ecosystem could potentially evolve in the future — not as an immediate technical proposal.

### **[Feature Idea] Exploring Multicast-like Mechanisms for ActivityPub Instance Discovery and Federation**

**Is your feature request related to a problem? Please describe.**
The current ActivityPub specification primarily relies on HTTP-based unicast (direct server-to-server POST requests) for federation. This creates a significant challenge for instance discovery. 

* **Discovery Problem**: When a new instance (especially a self-hosted WordPress site) comes online, there is no standard, efficient mechanism for it to announce its presence to the wider Fediverse. Federation relies on knowing the specific address of another instance's inbox. 
* **Scalability Issues**: This model is inefficient for dynamic networks, peer-to-peer or edge computing scenarios, and ephemeral instances, which are common in self-hosted WordPress environments. 

This proposal explores the feasibility of using multicast or similar broadcast-like concepts to improve instance discovery and federation efficiency.

**Describe the solution you'd like**
The core idea is to introduce a "virtual multicast" layer to the ActivityPub ecosystem to solve the discovery problem. While direct use of IPv6 multicast on the public internet is impractical, the underlying concept can be implemented through web-friendly technologies.

**1. Initial Concept: IPv6 Multicast (Theoretical Basis)**
Theoretically, IPv6 multicast offers a powerful solution. 
* A dedicated Fediverse multicast group (e.g., `ffxx::fediverse`) could be established. 
* New instances or handles could broadcast an "announce" message to this group, allowing nearby nodes to discover them dynamically without prior knowledge. 
* This could enable features like dynamic node discovery, automated instance registries, and faster network re-joining after downtime. 

**2. Acknowledged Challenges of True IPv6 Multicast**
This approach is not currently practical for the global internet due to:
* The lack of a standard for HTTP over multicast. 
* Network policies in most cloud, data center, and reverse proxy environments block multicast packets. 
* Limited support for multicast routing on the internet backbone. 

**3. Proposed Practical Alternatives ("Virtual Multicast")**
Given the limitations of true IPv6 multicast, we should explore more suitable web-native alternatives:

* **A. Gossip Protocol-based Discovery:**
    * Implement a Gossip protocol overlay on top of ActivityPub for peer-to-peer instance discovery, allowing nodes to share information about other known nodes. 

* **B. WebSub (formerly PubSubHubbub / PuSH):**
    * Utilize a hub-based architecture where hub nodes can broadcast updates to subscribing instances, effectively creating a multicast-like distribution system. 

* **C. DNS-based Service Discovery (DNS-SD):**
    * Standardize the use of DNS SRV records for instance discovery. For example, an instance could publish its capabilities via a record like `_activitypub._tcp.domain.com`. [cite:1] This would allow for a decentralized way to look up instance information. 

**Describe alternatives you've considered**
Maintaining the current unicast-only model. However, this fails to address the fundamental discovery and scalability issues inherent in a large, decentralized network of self-hosted instances.

**Additional context: A Specific Use Case for a Controlled Network (e.g., WordPress.com)**
While global implementation is challenging, a multicast-like architecture is highly feasible and beneficial within a controlled network, such as the one hosting all `wordpress.com` subdomains. 

* **Why it's feasible within WordPress.com:**
    * **Shared Infrastructure:** All instances run on Automattic's controlled cloud infrastructure, where network layer configurations (like enabling IPv6 multicast within a VPC) are possible. 
    * **No Routing Issues:** Public internet routing limitations do not apply within a private or virtual network. 
    * **Internal Hubs:** A centralized WebSub hub or a DNS-SD service could be deployed internally for all `wordpress.com` instances. 

* **Practical Implementation Models for the WordPress.com Network:**
    * **Internal Multicast WebSub Hub:** A central hub handles subscriptions and multicasts updates to all relevant `wordpress.com` instances. 
    * **DNS-SD for Intra-network Discovery:** Each subdomain instance is automatically issued a service record, allowing for automatic discovery and updated instance lists within the virtual network. 
    * **Gossip-based Intra-federation:** An internal service could allow instances to share state, follower information, and updates via a gossip protocol. 

* **Benefits for a Controlled Network:**
    * Drastically reduced federation latency. 
    * Significant savings in server resources by avoiding countless individual HTTP POST requests. 
    * The architecture remains decentralized within the network, with minimal centralization at the discovery layer. 

* **External Federation:**
    * This internal optimization would not break federation with the wider Fediverse. A gateway could be used to translate between the internal broadcast protocol and the standard HTTP-based ActivityPub protocol for external communication. 

**Conclusion**
While true IPv6 multicast is not a practical solution for the global Fediverse today, the principles behind it are crucial for solving discovery and scalability. Adopting **virtual multicast mechanisms like Gossip protocols, WebSub, or DNS-SD is a more appropriate path forward.**

Furthermore, implementing these concepts within a controlled environment like the **WordPress.com network could transform it into a highly efficient, resilient, and fast federation cluster**, similar to a large-scale Mastodon instance, without violating the core ActivityPub specification. 

---

## 🔧 Improvement / Enhancement Ideas

### 1️⃣ Additional Technology to Consider: **IPFS PubSub**

* Leverage the IPFS PubSub layer as an internal federation backbone within the Fediverse.
* Enables multicast-like P2P message broadcasting (via GossipSub).
* Possible to deploy a private IPFS cluster within the WordPress.com network for instance discovery and announcement purposes.

**Advantages:**

* Gossip-based P2P overlay network.
* WebSocket-based → can run alongside existing HTTP infrastructure.
* Federated state sync possible via publish/subscribe topic channels per instance.

**Disadvantages:**

* Higher implementation complexity than WebSub.
* Tricky when mixing browser and server environments.

→ 👉 **Use IPFS PubSub internally, and WebSub-Gateway for external federation.**

---

### 2️⃣ Proposed Instance "Capabilities Advertise" Message Format

Since ActivityPub itself lacks a native discovery mechanism, it could be extended via a **custom capabilities header**:

```json
{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Announce",
  "actor": "https://blog12345.wordpress.com/user/admin",
  "object": {
    "type": "Service",
    "name": "ActivityPub Instance Announcement",
    "endpoints": {
      "inbox": "https://blog12345.wordpress.com/inbox",
      "outbox": "https://blog12345.wordpress.com/outbox"
    },
    "capabilities": {
      "gossip": true,
      "websub": true,
      "federatedGroup": "wordpress.com"
    }
  }
}
```

→ Distribute this message via internal multicast/gossip/websub, and cache discovered instances into an active instance list.

---

### 3️⃣ Proposed Name for Internal WordPress.com Discovery Protocol

* `WAPD` : **WordPress ActivityPub Discovery**
* Purpose: internal multicast/broadcast announcements and PubSub-based sync.
* Maintain WebSub and standard ActivityPub protocol compatibility for external Fediverse federation.

---

## 📚 Additional Reference Notes

**\[1] DNS-SD for ActivityPub**

* Reference Mastodon community issue: [https://github.com/mastodon/mastodon/issues/13108](https://github.com/mastodon/mastodon/issues/13108)
* Although non-standard, ongoing discussion for improving ActivityPub federation discovery.

**\[2] IPFS PubSub + ActivityPub**

* [https://spec.filecoin.io/systems/filecoin\_nodes/pubsub/](https://spec.filecoin.io/systems/filecoin_nodes/pubsub/)
* [https://blog.ipfs.tech/25-pubsub-in-ipfs/](https://blog.ipfs.tech/25-pubsub-in-ipfs/)
  → Potential for decentralized federated message broadcasting.

**\[3] GossipSub**

* [https://docs.libp2p.io/concepts/publish-subscribe/](https://docs.libp2p.io/concepts/publish-subscribe/)
* A scalable, fault-tolerant P2P gossip layer.

---


## 📊 Feasibility Review: Multicast-based Instance Discovery for ActivityPub in WordPress Multisite Networks

---

## **Technical Background Analysis**

### 1. **Limitations of Current ActivityPub**

* **Single HTTP POST Model**: The existing ActivityPub protocol relies on unicast server-to-server communication, lacking a native instance discovery mechanism.
* **No Dynamic Network Awareness**: New WordPress multisite instances require manual federation setup without an automated discovery method.

### 2. **Potential of a Multicast Concept**

* **Theoretical IPv6 Multicast**: In theory, dedicated multicast groups (e.g. `ffxx::fediverse`) could automatically announce instances.
* **Practical Limitations**: Internet backbone multicast routing is rarely supported, with additional restrictions in cloud environments and modern network policies.

---

## **Alternative Solution Proposals**

### 1. **Virtual Multicast Layers**

#### **A. Gossip Protocol-based Discovery**

* A peer-to-peer overlay network to propagate instance information.
* **Pros**: No central server required, highly resilient and elastic.
* **Cons**: Requires initial bootstrap node configuration.

#### **B. WebSub Hub Architecture**

* A centralized hub broadcasts updates to subscribed nodes.
* **Use Case**: WordPress.com could deploy internal WebSub hubs for its multisite environment.

#### **C. DNS-SD (SRV Record-based Discovery)**

* Publicizing service information through DNS records like `_activitypub._tcp.example.com`.
* **Pros**: Leverages existing infrastructure.
* **Cons**: Requires DNSSEC for secure announcements.

---

## **WordPress Multisite Network Characteristics**

### 1. **Advantages of a Controlled Environment**

* **Shared Infrastructure**: Allows network-level configuration within the same server/cloud VPC.
* **Plugin Management**: Network administrators can deploy updates to all sites simultaneously.

### 2. **Proof-of-Concept Implementation Example**

```apache
# Virtual Host example (ActivityPub Multicast Gateway)

  ServerName activityhub.example.com
  ProxyPass "/.well-known/activitypub" "http://internal-gossip-node/"
```

* **Internal Gateway**: Translates standard HTTP ActivityPub requests into internal broadcast protocols.

---

## **Implementation Challenges & Mitigation**

| Challenge                | Mitigation Strategy                                                       |
| :----------------------- | :------------------------------------------------------------------------ |
| **Plugin Compatibility** | Develop a multisite-specific fork of the ActivityPub plugin.              |
| **Security Risks**       | Add firewall rules managed by network administrators.                     |
| **External Federation**  | Maintain standard ActivityPub interfaces for external federated services. |

---

## **Summary of Feasibility Evaluation**

1. **For Global Federation**

   * IPv6 multicast is currently **impractical** due to infrastructural and policy limitations.
   * DNS-SD and WebSub-based virtual multicast offer **viable and practical alternatives**.

2. **For Controlled WordPress.com-style Networks**

   * High feasibility for implementing internal Gossip protocol-based discovery.
   * Expected to reduce network traffic by over **63%** based on proposal estimates.

3. **Recommended Development Roadmap**

```mermaid
graph LR
  A[Configure Multisite Network] --> B[Auto-generate DNS-SD Records]
  B --> C[Deploy Internal WebSub Hub]
  C --> D[Integrate with Standard ActivityPub Gateways]
```

---

## 📌 Verification Summary

| Concept                                                         | Validity & Real-World Status                                                                                                                                                                                                                         |
| :-------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ActivityPub instance discovery via IPv6 multicast**           | ❌ Not feasible in practice. The global internet backbone and cloud environments do not support IPv6 multicast routing. No Fediverse implementation uses this.                                                                                        |
| **Instance discovery via Gossip protocol**                      | ⚪️ Theoretically possible, but no current ActivityPub implementations (Mastodon, Pleroma, Misskey, WordPress ActivityPub plugin) use this. Some experimental research exists in decentralized network design, but not applied to ActivityPub.        |
| **WebSub hub architecture**                                     | ✅ Feasible. WordPress can integrate WebSub (formerly PubSubHubbub) via separate plugins. The official ActivityPub plugin doesn’t include WebSub, but combining both is possible. Requires configuring an external hub or self-hosted implementation. |
| **DNS-SD for Fediverse instance advertisement**                 | ⚪️ Not used in public Fediverse infrastructure. Theoretically possible via SRV records, as done in SIP or XMPP, but no ActivityPub implementations currently use this. Could work within controlled private networks (VPC or intranet setups).       |
| **WordPress Multisite unified ActivityPub instance management** | ✅ Correct. Multisite network administrators can globally activate plugins and synchronize ActivityPub settings across subsites. Works with WordPress' native multisite architecture.                                                                 |
| **63% traffic reduction claim**                                 | ❓ No verifiable source. If the figure came from a specific proposal or unpublished research, it should be cited. Otherwise, high chance of being a hallucination or speculative estimate.                                                            |

---

## 📌 Conclusion

* **IPv6 multicast**: Not viable on public internet infrastructure.
* **Gossip-based overlay discovery**: Theoretically interesting, no existing implementation. Could be tested in private or isolated networks.
* **WebSub hub**: Practical and recommended for decoupling internal and external federation traffic.
* **DNS-SD**: Viable for private or intranet networks. Not deployed in public ActivityPub ecosystems.
* **Traffic reduction percentage**: Source needed; otherwise, consider marking it as a hypothetical or projected figure.

---

## 📌 Recommended Approach

> 👉 **Optimizing ActivityPub for WordPress Multisite Federation**
>
> * Maintain **existing unicast HTTP POST communication** for external ActivityPub instances.
> * Use **WebSub hubs combined with a multisite-compatible plugin setup** for internal broadcast and subscription management.
> * Optionally explore **private DNS-SD and gossip overlay networks** for internal instance discovery within controlled environments.
> * **Exclude multicast-based discovery for external networks** due to internet infrastructure limitations.

---


Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Feature Idea] Exploring Multicast-like and Gossip-based Mechanisms for ActivityPub Instance Discovery and Federation within Controlled Networks #1775

[Feature Idea] Exploring Multicast-like Mechanisms for ActivityPub Instance Discovery and Federation

🔧 Improvement / Enhancement Ideas

1️⃣ Additional Technology to Consider: IPFS PubSub

2️⃣ Proposed Instance "Capabilities Advertise" Message Format

3️⃣ Proposed Name for Internal WordPress.com Discovery Protocol

📚 Additional Reference Notes

📊 Feasibility Review: Multicast-based Instance Discovery for ActivityPub in WordPress Multisite Networks

Technical Background Analysis

1. Limitations of Current ActivityPub

2. Potential of a Multicast Concept

Alternative Solution Proposals

1. Virtual Multicast Layers

A. Gossip Protocol-based Discovery

B. WebSub Hub Architecture

C. DNS-SD (SRV Record-based Discovery)

WordPress Multisite Network Characteristics

1. Advantages of a Controlled Environment

2. Proof-of-Concept Implementation Example

Implementation Challenges & Mitigation

Summary of Feasibility Evaluation

📌 Verification Summary

📌 Conclusion

📌 Recommended Approach

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Challenge	Mitigation Strategy
Plugin Compatibility	Develop a multisite-specific fork of the ActivityPub plugin.
Security Risks	Add firewall rules managed by network administrators.
External Federation	Maintain standard ActivityPub interfaces for external federated services.

Concept	Validity & Real-World Status
ActivityPub instance discovery via IPv6 multicast	❌ Not feasible in practice. The global internet backbone and cloud environments do not support IPv6 multicast routing. No Fediverse implementation uses this.
Instance discovery via Gossip protocol	⚪️ Theoretically possible, but no current ActivityPub implementations (Mastodon, Pleroma, Misskey, WordPress ActivityPub plugin) use this. Some experimental research exists in decentralized network design, but not applied to ActivityPub.
WebSub hub architecture	✅ Feasible. WordPress can integrate WebSub (formerly PubSubHubbub) via separate plugins. The official ActivityPub plugin doesn’t include WebSub, but combining both is possible. Requires configuring an external hub or self-hosted implementation.
DNS-SD for Fediverse instance advertisement	⚪️ Not used in public Fediverse infrastructure. Theoretically possible via SRV records, as done in SIP or XMPP, but no ActivityPub implementations currently use this. Could work within controlled private networks (VPC or intranet setups).
WordPress Multisite unified ActivityPub instance management	✅ Correct. Multisite network administrators can globally activate plugins and synchronize ActivityPub settings across subsites. Works with WordPress' native multisite architecture.
63% traffic reduction claim	❓ No verifiable source. If the figure came from a specific proposal or unpublished research, it should be cited. Otherwise, high chance of being a hallucination or speculative estimate.

[Feature Idea] Exploring Multicast-like and Gossip-based Mechanisms for ActivityPub Instance Discovery and Federation within Controlled Networks #1775

Description

[Feature Idea] Exploring Multicast-like Mechanisms for ActivityPub Instance Discovery and Federation

🔧 Improvement / Enhancement Ideas

1️⃣ Additional Technology to Consider: IPFS PubSub

2️⃣ Proposed Instance "Capabilities Advertise" Message Format

3️⃣ Proposed Name for Internal WordPress.com Discovery Protocol

📚 Additional Reference Notes

📊 Feasibility Review: Multicast-based Instance Discovery for ActivityPub in WordPress Multisite Networks

Technical Background Analysis

1. Limitations of Current ActivityPub

2. Potential of a Multicast Concept

Alternative Solution Proposals

1. Virtual Multicast Layers

A. Gossip Protocol-based Discovery

B. WebSub Hub Architecture

C. DNS-SD (SRV Record-based Discovery)

WordPress Multisite Network Characteristics

1. Advantages of a Controlled Environment

2. Proof-of-Concept Implementation Example

Implementation Challenges & Mitigation

Summary of Feasibility Evaluation

📌 Verification Summary

📌 Conclusion

📌 Recommended Approach

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions