Feature Proposal: Add Federation On/Off Toggle with 30-Day Cooldown and Follower Reset

[Jiwoon-Kim]

📑 Feature Proposal: Add Federation On/Off Toggle with 30-Day Cooldown and Follower Reset

Summary
Introduce a federation on/off toggle for the WordPress ActivityPub plugin.
When federation is disabled:

• Reactivation is blocked for 30 days.
• Followers and following lists are cleared.
• A clear warning message is shown before deactivation.

Also, when a blog/user handle is changed, federation will be disabled for 30 days with the same restrictions applied.

---

Why This Is Needed

• Inspired by Threads’ fediverse opt-out behavior:

• https://www.threads.com/settings/fediverse

  “You stopped sharing to the fediverse on May 26, 2025.
  You’ll be able to turn sharing back on after 30 days.”

• Solves these related issues:

  • [#566 How to remove the fediverse-account for my closed weblog?](How to remove the fediverse-account for my closed weblog? #566)
  • [#508 Feature Request: To completely delete ActivityPub profile when uninstalling plugin](Feature Request: To complete delete the ActivityPub when uninstall the plug-in #508)

• Prevents lingering account data on federated instances by providing a 30-day cache expiry period.

• Ensures handle changes don’t result in orphaned profiles or broken federation relationships.

---

How It Works

• New Federation On/Off toggle in plugin settings:

  • When turned Off:

    • Federation stops immediately.

    • Followers/Following lists are reset (locally).

    • A warning message appears:

      ⚠️ Disabling federation will remove all followers and following records.
      You won’t be able to turn it back on for 30 days.

    • Toggle becomes disabled (grayed out) for 30 days.

  • After 30 days:

    • User can manually re-enable federation.
    • New federation connections start fresh.

• On handle changes (site or user handle):

  • Federation automatically turns Off for 30 days.
  • Followers/Following lists cleared.
  • Resume federation automatically after cooldown.

• Cooldown timing is based on server-side timestamp (not client clock) to prevent circumvention.

---

Optional Enhancements

• Add a log of federation status changes per site or user.
• Option to export following/reblogs before disabling federation (for archival/restoration).

[obenland]

What's the significance of the 30 days?

[pfefferle]

I think the issue with the delete is the "delete" activity itself, not the trigger! I would avoid an automatism like that, because a delete is permanent (at least for mastodon), so we have to get sure that it will not be sent by accident!

[pfefferle]

Here is some context: #552

[Jiwoon-Kim]

Hi @obenland ,

📌 About the 30-day value

To be honest, the 30 days is a somewhat arbitrary but practical safety window. Since we don’t have complete visibility into Threads’ internal behavior for their cooldown period, I chose 30 days because:

• It aligns with typical cache durations in Mastodon
• It’s consistent with similar patterns in other federated platforms
• It provides a reasonable grace period for data propagation and cache expiration

But it’s not a strict requirement.
In fact, the most crucial thing is:

• When a handle is changed (or federation is disabled), the system should reliably clear any associated ActivityPub data (actor URLs, WebFinger records, followers/following lists).
• The user should be able to re-enable federation at any time — as long as the handle-to-actor mapping and cached state have been properly reset.

If those mechanics are in place, a cooldown period could be shorter, longer, or even optional.

📌 Why the initial 30 days proposal

I proposed 30 days as a conservative default to:

• Ensure ample time for external servers to clean up cached references
• Avoid potential conflicts if a user quickly disables and re-enables federation, especially when handle changes or re-activations occur
• Align with how other platforms (like Threads) seem to manage federation state transitions — though, again, without official documentation, this part is inferred.

It could absolutely be made configurable (e.g. 14, 30, 60 days) or even left entirely up to site admins based on their community needs.

✅ Summary

So while 30 days was a safe, practical starting point, the real priority is making sure:

• Federation state cleanly resets on opt-out or handle change
• Re-enabling federation works reliably, with any stale data cleared appropriately

---

📌 How Threads handles federation opt-outs

What I found especially interesting is how Threads manages their federation opt-out without actually deleting ActivityPub accounts. Here’s how it works:

• When federation is active, WebFinger records and actor profiles are accessible across the fediverse.

• If a user disables federation:

  • WebFinger no longer resolves for that account
  • Actor URLs return 404 or a “disabled” state
  • Profile JSON is no longer retrievable

So from the ActivityPub network’s perspective, the account effectively vanishes — but it’s not actually deleted inside Threads. The internal data, followers, and settings remain intact, and federation can be toggled back on later.

📌 Mastodon’s response to this

On the Mastodon side:

• When a remote actor or WebFinger lookup returns a 404, Mastodon will eventually drop the cached data.
• If WebFinger doesn't resolve, the account is considered non-existent.
• Cached relationships like followers are typically cleaned up over time.

So while it feels like a reset, it’s really an opt-out plus natural cache expiration.

📌 How this applies to the WordPress ActivityPub plugin

The 30-day cooldown concept I proposed isn't about issuing a Delete activity either. Instead:

• Remove the WebFinger record temporarily
• Respond with 404 (or equivalent) for the actor endpoint
• Clear local followers/following lists
• Let external caches naturally expire within 30 days
• Allow the user to opt back in afterward

This would emulate Threads’ behavior, preserving user experience and data safety without triggering protocol-level deletions.

📌 Why avoid Delete activities?

As you pointed out before — sending a Delete activity is risky because:

• Mastodon and others will permanently delete the account reference
• Rejoining the network with the same handle might not be possible (or clean)
• Threads themselves don’t send Delete for opt-outs either — they just hide the actor and WebFinger entries.

✅ Summary

So essentially, this isn’t about deleting accounts, but providing a soft reset or temporary invisibility within the fediverse.

I believe implementing this in the WordPress ActivityPub plugin — modeled on Threads’ UX — would strike a good balance between control, privacy, and federation integrity.

Would love to hear your thoughts on this, and whether you think making the cooldown period configurable would be a worthwhile addition too.

Thanks again for the great discussion!