Description
What
📌 Let’s Build a Fediverse Follower Feed into the WordPress Backend
I’ve been thinking a lot about how WordPress integrates with the Fediverse — and I realized we’ve been a little too obsessed with frontend-based interaction patterns, mostly influenced by how Mastodon or Misskey work.
But when you look closely, WordPress authors don’t really manage or consume content through a frontend UI. The primary workflow happens within the WordPress admin dashboard.
Because WordPress was, and still is, a backend-driven CMS at its core.
So, here’s my proposal:
Let’s bring a decentralized reader experience into the WordPress backend.
On the self-hosted WordPress dashboard page (/wp-admin/index.php), the “WordPress Events and News” widget provides updates on upcoming Meetups, WordCamps, and WordPress-related news.
Meanwhile, on WordPress.com’s backend, there’s a “Latest” tab that displays a feed of popular and recently trending blog posts from WordPress.com users + wp.com/blog.
📌 WordPress Backend-Based ActivityPub Follower Feed
✅ Why Backend?
It’s basically creating a decentralized version of WordPress Reader — inside wp-admin.
- WordPress users manage and check content primarily through the wp-admin dashboard.
- On Mastodon or Misskey, anonymous visitors only see public explore or local timelines. Full feeds and interactions require a registered identity.
- Since various interactions (follows, replies, boosts, mentions) require a logged-in user context, there’s no immediate reason to expose a follow/feed UI on the frontend.
→ Integrating ActivityPub feeds inside the WordPress Dashboard makes perfect sense and aligns with WordPress’s CMS-centric UX.
✅ Feature Ideas
Site owners should have full control over their blog handles and user handle interactions.
-
WordPress Dashboard → ActivityPub Follower Timeline Tab
- Read Federated WordPress / followed Mastodon, threads, misskey feeds
- Manage follows for personal and site accounts
- Like WordPress.com’s [Me Dashboard](https://wordpress.com/me)
- Check recent Fediverse posts, comments, mentions directly inside the site’s admin
-
User-to-User Follows
-
Site-to-Site Follows
wordpress.com/reader/blogs/@blog- https://wordpress.com/reader/feeds/169602085
- Extended to ActivityPub = turn your WordPress site into a federated server
-
Fediverse federation status pages like:
This would allow WordPress site-to-site follows, acting like a federated feed aggregator.
Since WordPress.com user accounts can work across multiple domains/hosts, this follow system needs to be fundamentally different from how Mastodon or Misskey handle it.
✅ Key Differentiators
- Most current ActivityPub clients are frontend-focused
- WordPress inherently supports multi-site / multi-user management
→ We can apply this same pattern to Fediverse interactions - WordPress.com’s Reader structure could be ported to self-hosted WordPress dashboards
📌 simulation
A backend page like:
https://travel-in-busan.com/wp-admin/admin.php?page=fediverse-followers
Would show:
- Follower list
- Following list
- Recent posts feed (posts / comments / reblogs / mentions)
- note/reply: block editor style, like jetpack comment
- Follow / block management
→ This could even be modularized as dashboard widgets or Gutenberg blocks, emulating the WordPress.com Reader experience.
Also, it should handle both personal account actors and site handle actors.
This turns a self-hosted WordPress site into a federated node reader, similar to WordPress.com’s Reader but integrated with a decentralized social network.
📌 WordPress ActivityPub Timeline Design Proposal
1️⃣ Backend-Centric Reader
-
/wp-admin ActivityPub Reader dashboard
→ Combines wp.com Discover + Home Timeline + Following users/tags feed -
Users see posts from followed blogs/users only when logged in
-
Not real-time, but cached and refreshed either:
- On dashboard access
- Via WordPress cron jobs
2️⃣ Optional Frontend Timelines
For optional public-facing feeds:
Essential Timelines
- Following feed: posts from the user’s or site’s followed accounts
- Local feed: public posts from this site (if it federates multiple accounts)
- Federation feed (optional, very heavy for small servers)
But by keeping these opt-in and mostly backend-facing, you protect small servers from overwhelming traffic loads, especially when dealing with heavy article type content over simple note types.
2️⃣ Separate Frontend Timeline Views
Essential Timelines
- Following Feed: Posts from blogs and users followed by my user account
- Local Feed: Posts from ActivityPub participants registered on my site
- Global Feed: A feed based on a list of connected WordPress instances
→ Example: Build a WordPress ActivityPub instance list API similar to https://misskey-hub.net/ko/servers/
Optional Timelines
- Popular Posts / Trending Tags (optional)
- Discover Feed (like WordPress.com Discover)
→ Use a federated trending algorithm or posts ranked by boost count
3️⃣ Differentiated Content Load Strategy by Post Type
To resolve traffic issues:
- Note type: Can be updated in real-time
- Article type: Limit refresh intervals, display summaries first
(Use WordPress Reader API on click to load full content)
4️⃣ Balance Between Centralized and Decentralized Models
-
Large Discover Server
A centralized Discover instance (e.g.discover-wordpress.social) that aggregates feeds from decentralized WordPress instances -
Per-Site Reader
Each WordPress site has its own Reader dashboard to view posts from followed blogs and users
📖 Nice-to-Have Features for Implementation
- A WordPress ActivityPub Directory Plugin (to manage a list of federated servers)
- A WordPress Reader ActivityPub Following Management Plugin
- A Popular Posts Caching Server / Trending Tags Feed API
📌 Federation Instance Directory for ActivityPub-Enabled WordPress Sites
Just like:
- [Misskey server lists](https://misskey-hub.net/ko/servers/)
- [Mastodon’s instance directory](https://instances.social/)
We should build an aggregated directory of ActivityPub-enabled WordPress instances
to help users discover federated WordPress sites and follow them from across the Fediverse.
📌 Final Thought
Balancing decentralization benefits and scalability limitations is crucial here.
Frontend-based timelines flood traffic, especially for small servers.
A backend reader experience makes the most sense for WordPress — it preserves its CMS nature while seamlessly joining the federated web.
Why
.
How
No response