Building Axismundi — a block theme exploring ActivityPub integration

[Jiwoon-Kim]

Project update — June 2026

Axismundi has moved from service-scope planning into an implementation and
distribution phase.

The standalone block theme and its companion plugins have now been submitted
for WordPress.org review. The current work is focused on refining the theme's
templates and core-block presentation.

The next ActivityPub-specific phase will:

• Add theme styling for blocks and front-end output provided by the official
  ActivityPub plugin.
• Test a small ax-note custom post type as an experimental short-form
  publishing surface.
• Keep protocol and federation behavior in the ActivityPub plugin while
  Axismundi owns presentation and optional domain-specific authoring tools.

The broader Mastodon-style feature list below should now be read as early
architectural exploration, not as the committed first-release scope.

Repository: https://github.com/Jiwoon-Kim/axismundi

Theme release:
https://github.com/Jiwoon-Kim/axismundi/releases/tag/theme-v0.1.1
https://themes.trac.wordpress.org/ticket/277726

---

TL;DR

I'm building Axismundi, a custom WordPress block theme that aims to provide a Mastodon-style microblog UX on top of the official activitypub plugin. Looking for guidance on how far the theme can reasonably go without duplicating or fighting the plugin's architecture.

The design system is already built (Material Design 3, 33-component spec, dark-first, Korean-first). What I want to validate is the service scope — which features fit cleanly as theme extensions vs. which would require fork-level modifications.

---

What Axismundi is

• Custom WordPress block theme + companion plugins (m3-blocks generic, axismundi-blocks domain-specific)
• Hero surface: microblog feed (ActivityPub-style timeline)
• Secondary surfaces: profile, article, attachment page (repurposed as ActivityPub mediaObject URL)
• Design system: Material Design 3 baseline, dark-first, Korean as first-class language
• Stance: treats activitypub plugin as the protocol layer — Axismundi handles UI / theme / domain integration only. No intent to replace or fork the plugin.

Project status: design system v0.2.0 complete (14 components built, ~1,750 LOC components.css, full M3 token system). Now planning Phase 1.5 — service scope and DB integration design.

---

Why I'm asking before going further

Before committing to specific UI prototypes and DB schema extensions, I want to validate which features are realistic theme/companion-plugin extensions vs. which are fork-level changes that would put Axismundi outside what the official plugin can support.

I assume the plugin maintains conservative core compatibility (and wp.com infrastructure compatibility). That naturally constrains what I can build. I'd rather know the boundaries up front than discover them through breakage.

---

Service scope — what I want to know

I have three candidate scopes:

A. Mastodon/Lemmy-level full SNS

Custom emoji, polls, quote posts, sensitive flag with blur, Lemmy-style forum/community follow, multi-actor per user, full federation UX.

B. Blog + microblog hybrid (preferred starting point)

• Note + Article post types
• Follow / Unfollow / Like / Boost (Announce)
• Reply (using existing WP comments system + ActivityPub inReplyTo mapping that the plugin already provides)
• Single-actor per user (multi-actor abandoned given plugin constraints)
• Profile pages, feed, basic moderation
• Not in v1: custom emoji, polls, quote, Lemmy forum, sensitive blur

C. Blog + ActivityPub publishing only

One-way publishing. External clients can follow, but minimal internal SNS UX.

My current default is B. I'd like to confirm this is realistic before building further.

---

Specific questions

Q1 — Where is the actual line between "theme extension" and "fork-level change"?

For each of the following, is there a clean theme/companion-plugin path, or does it require modifying the activitypub plugin itself?

• Multi-actor per user (multi-profile) — I've already abandoned this based on the plugin's wp_users-tied actor model. Confirming: is this a hard architectural decision, or is there a known extension point?
• Comments → inReplyTo deeper integration — the plugin already maps WP comments to ActivityPub Note replies. I read this as "good enough" for v1. Is there a reason to go deeper (e.g. Mastodon-style threaded view with deleted-user placeholders)?
• Custom emoji — does the plugin handle inbound Emoji objects on remote posts? If yes, theme just needs to render them correctly. If no, this is fork territory.
• Polls (Question object) — same question. Inbound rendering vs. authoring vs. response collection — which layers does the plugin cover?
• Quote posts (quoteUrl / _misskey_quote etc.) — fediverse-fragmented feature. Does the plugin track any of the proposed FEPs here?
• Sensitive flag + blur — content warning is in the spec. Is sensitive: true and summary already supported? Theme just renders the blur overlay?

Q2 — Attachment page repurposing for mediaObject URLs

I want to use WordPress's native attachment pages (post_type=attachment) as ActivityPub mediaObject permalinks. WP 6.4 disables them by default; I'd re-enable via theme activation hook.

Goals:

• Each uploaded media has a stable ActivityPub id (the attachment permalink)
• Comments on the attachment page = ActivityPub Note replies on the media
• Multiple post-usage tracking via post meta

Is this approach compatible with how the plugin currently handles attachments? Or does the plugin already publish attachments differently?

Q3 — Custom UI surfaces and conflict avoidance

The theme provides custom templates for:

• Front page = microblog feed (Query Loop + custom block)
• Single post (note vs article — different layouts)
• Profile (custom CPT axismundi_profile? or extending author archive?)
• Remote actor profile pages — definitely needs custom routing (existing author archive can't represent remote actors)

For the remote actor profile specifically: does the plugin provide any URL/template hook for "render a remote actor's profile served from our site"? Or do I need to build that from scratch?

Q4 — Block theme integration patterns

Has anyone successfully built a block theme that:

• Uses theme.json for the design tokens
• Registers custom blocks that interact with the plugin's stored data (e.g. a "Federated Post Card" block that reads ActivityPub object fields)
• Provides patterns for Note/Article composition

Any reference implementation, even partial, would be huge.

Q5 — FEP adoption — which to prioritize

I've been reading FEPs but the list is long and adoption-fragmented. From the plugin's perspective, which FEPs are:

• Already supported / partially implemented
• On the roadmap
• Out of scope

That would help me prioritize which features in scope B are buildable now vs. blocked.

---

What I bring

• Design system is done. M3-based, ~1,750 LOC components.css, full token system, 33-component spec catalogued (14 built, 19 planned). Repo coming after Phase 1B.
• Clear separation: theme (axismundi) + generic blocks plugin (m3-blocks, m3/* namespace) + domain blocks plugin (axismundi-blocks, axismundi/* namespace). Generic blocks are reusable for any M3-style WP theme — could be a starting point for someone else.
• Documentation discipline: every spec decision has a recorded rationale, every caveat has a workaround, every deferred feature has a target milestone.

I'm not asking the maintainers to build anything for me. I want to know where the official plugin's architectural boundary is so I can build on top of it cleanly rather than against it.

---

Context links (for anyone curious)

• Design system stack: Material Design 3 (Expressive baseline), color-mix()-based state layers, M3 spring physics motion, dark-first with auto/manual mode override
• Korean-first typography handling (word-break: keep-all + overflow-wrap: anywhere)
• WP block bucket strategy: A (core block + style) / C (custom block plugin) / D (template-part) / E (form-plugin styling target) / F (theme JS only)

Happy to share more detail on any specific piece. Looking forward to the maintainers' and community's input on what's reasonable scope.