Issue 1: Improved Unified User Handle Management in Multisite Environments

[Jiwoon-Kim]

Issue 1: Improved Unified User Handle Management in Multisite Environments

[Feature Request] Multisite: Unified User Handle Management

Is your feature request related to a problem? Please describe.
In a WordPress multisite environment using the ActivityPub plugin, individual user handles are generated separately for each subsite. This leads to fragmented handle management and a disjointed user experience. When integrating services like Jetpack, the increased number of possible handle variations makes centralized management difficult.

Describe the solution you’d like

1. Introduce a feature that designates the main domain (or a defined central hub) as the ActivityPub instance for all users across a multisite network.
2. Subsite-specific ActivityPub user accounts should be either unified under or redirected to handles on this central instance (e.g., @username@subsite.main.com redirected to @username@main.com or profiles.wordpress.org/@username).
3. Simplify handle categories into three primary types when integrating with Jetpack accounts: wp.org, wp.com, and custom domains.
4. Leverage existing infrastructure such as WordPress.com Reader’s users/@user pages to provide a unified ActivityPub profile management UI, streamline notifications, and enable smooth switching between Fediverse handles when interacting (e.g., commenting) across services.

Describe alternatives you’ve considered
Maintaining the current system where each subsite has its own independent ActivityPub handle. However, this is less scalable and deteriorates the overall user experience in the long term.

Additional context
This would be especially valuable for large multisite networks or platforms aiming to provide a cohesive, integrated user experience (e.g., educational institutions or community platforms). It could also enable multi-account switching UX similar to Instagram’s multi-profile feature, potentially via the Jetpack mobile app.

#1734

[obenland]

That's an interesting proposal.

Some random thoughts:
We'd have to find a way to aggregate content from across subsite into a single outbox.
Is it even possible to aggregate content from disparate domains in one Outbox?
I guess we could determine behavior based on whether the plugin is network activated or not?

[Jiwoon-Kim]

@obenland
The key idea is to unify the domain for user handles, while allowing blog profiles to use subdomains.

For example, this would make it possible to run localized news publications for a global Rosetta site structure, like:

ko.example.com

jp.example.com

fr.example.com

Each subdomain would act as a separate blog profile (actor) for federation purposes, while all user handles remain under a unified main domain (e.g. example.com/@username).

This would help maintain clean federation boundaries, avoid overwhelming remote servers with aggregated content, and respect each platform’s timeline UX expectations.

As for subdirectories — I’m not entirely sure how feasible or reliable that would be in this context, but subdomains are a clear, workable solution for this kind of federated multi-blog structure.

[Jiwoon-Kim]

@obenland
I do think it makes sense to turn subdirectories or forum boards into group handles. That way, users can choose to follow specific topic-based streams without being overwhelmed by instance-wide activity. It feels like a cleaner, more predictable way to use ActivityPub within WordPress.
#1743 (comment)

Actually — if we standardize user handles under the main domain, and use subdomains for blog handles, then subdirectories don’t necessarily need to become group handles. They could just be regular user handles under each subdomain instance. That way, there’s no conflict with ActivityPub groups, and it keeps timeline behavior predictable and clean.

[Jiwoon-Kim]

---

📌 WordPress Fediverse Handle System Proposal (Draft)

📖 Blog Profile (Main Site)

@wordpress.org@wordpress.org
→ The primary instance handle representing the main WordPress.org site.

📖 Subdirectory Blog Profile

@news@wordpress.org
→ Represents the /news/ blog under the main WordPress.org domain.

📖 Subdomain-Subdirectory Blog Profile

@meta@make.wordpress.org

@support@make.wordpress.org
→ For blogs hosted on subdomains of WordPress.org (e.g., make.wordpress.org/meta).

📖 Forum (Blog-Style) Profile

@support-forum@wordpress.org
→ Represents the entire Support Forum.

📖 Group Profile (Subsection / Topic Category)

@forum-multisite@wordpress.org
→ Represents a specific forum group, e.g., Multisite discussions under the Support Forum.

📖 User Profile

@kimjiwoon@profiles.wordpress.org
or

@kimjiwoon@wordpress.org
→ Represents individual contributor profiles.
Prefer profiles.wordpress.org for namespace isolation and to avoid potential handle conflicts with blogs or groups.

📖 WordPress.com User Profile

https://wordpress.com/reader/users/kimjiwoon96

@kimjiwoon96@wordpress.com
or

https://gravatar.com/kimjiwoon96

@kimjiwoon96@gravatar.com

---

📌 Strengths of This Structure

Subdomain / Subdirectory distinction is cleanly organized

Forum profiles are clearly separated as either blog-style or group profiles

No conflicts between WordPress.com, Gravatar, and WordPress.org profiles

📌 Potential Improvements / Risks

Using @kimjiwoon@wordpress.org might cause conflicts if blog or group handles overlap within the same instance namespace.
Suggestion: Prioritize @kimjiwoon@profiles.wordpress.org for user profiles.

Group handles (@forum-multisite@wordpress.org) might require clear ActivityPub implementation notes, since cross-instance federation handling of groups can differ.
But recent Mastodon (v4.2+) introduced official Group support, which makes this more feasible now.

Having @wordpress.org@wordpress.org as the primary handle may feel redundant.
Alternative Option: Consider @main@wordpress.org or @official@wordpress.org for clarity.

---

📌 Conclusion

This structure is scalable, namespace-safe, and aligns well with ActivityPub and Fediverse UX expectations.
It respects both technical constraints and community-driven UX patterns.

[Jiwoon-Kim]

Proposal: Prefer blog profile handles for post federation and OpenGraph metadata

Context: In a multisite WordPress + ActivityPub environment, handling author identity and federation consistency can be problematic when user profile handles are disabled on sub-sites but blog profile handles remain active.

Suggestion:

Instead of relying on a unified user profile handle (@user@profiles.wordpress.org) for post authorship across all sub-sites, each blog should post using its own blog profile handle (e.g., @news@wordpress.org, @forum@wordpress.org).

Additionally, when publishing a post, include the actual author’s user profile handle in the OpenGraph metadata (og:author or a custom meta tag) for attribution and reference purposes.
This way:

Federation remains clean and predictable.

Posts are federated by the blog instance (which acts like a microblogging group feed).

Author identity can still be discoverable via metadata or linked profile pages without requiring ActivityPub federation for the user handle on every sub-site.

Example Structure:

Blog post authored by @news@wordpress.org

OpenGraph meta:

This approach avoids conflicts, maintains ActivityPub spec compliance for instances, and keeps a consistent identity layer via meta references.

Benefits:

No need to enable user handles sitewide.

Predictable post origin per sub-site instance.

Author attribution preserved via OpenGraph / microformats / JSON-LD.

Cleaner Fediverse UX by avoiding cross-instance handle confusion.

[Jiwoon-Kim]

ActivityPub comment authorship via unified profile handle in WordPress multisite

Proposal:

In a WordPress multisite or BuddyPress environment, user profiles are managed centrally.

Instead of creating per-site ActivityPub accounts for commenting, store each user's Fediverse handle (e.g. @kimjiwoon@wordpress.org) in their unified profile metadata.

When a user posts a comment on a blog (ActivityPub-enabled sub-site), the system will:

1. Retrieve the user’s stored Fediverse handle.

2. Use that handle as the attributedTo field in the ActivityPub comment payload.

3. Deliver the comment through the blog’s inbox endpoint, but with authorship attributed to the main profile handle.

Effect:

To external Fediverse users, it appears as though the comment originated from the user's main profile instance.

No need to federate per-site user accounts.

Simplifies identity management while preserving correct authorship in Fediverse timelines.

Bonus:

This structure allows future-proofing for follow/unfollow, mentions, and likes with proper attribution, without requiring duplicated user accounts on each sub-site.
https://docs.joinmastodon.org/user/external/#interact

[Jiwoon-Kim]

Proposal:
To avoid namespace collisions and improve ActivityPub integration on WordPress.com, user handles should be isolated to a separate subdomain instance.

Example Structure:

Type Handle Format

Blog Profile @blog@blogname.wordpress.com
User Profile @username@social.wp.com

Reason:

Prevent WebFinger conflicts between blog and user profiles.

Maintain clear, predictable UX across the Fediverse.

Allow better scaling for future group or forum instances.

Align with ActivityPub’s decentralized, instance-based model.

[Jiwoon-Kim]

https://wordpress.slack.com/archives/C02RQBYUG/p1727291024757029

[obenland]

This would be especially valuable for large multisite networks or platforms aiming to provide a cohesive, integrated user experience

I think at this point I'd leave it up to the site to implement that, if desired.