Related to Emoji rendering and interaction

[Jiwoon-Kim]

@obenland
As you suggested, I’ve reorganized my proposal into several topic-focused issues.
However, I intentionally didn’t split them into too many separate GitHub issues. The reason is that some of these aren’t problems that can be solved purely by coding changes in the ActivityPub plugin itself. They’re more indirect, ecosystem-wide issues that would require broader policy decisions and changes to how different services interact within the Fediverse.

Because of that, it felt a bit awkward to break them down into completely separate issues for now — as their resolution wouldn’t be handled independently within the plugin’s scope anyway.

That said, if there are parts you think can be handled individually, please feel free to point them out. I’d be happy to get your feedback on which ones could be isolated, and I can then create fresh, more focused issues for those.

Thanks for your understanding!
#1129 (comment)

---

Issue 1: Unify Standard Emoji Rendering Across the WordPress Ecosystem

[Improvement] Emoji: Unify Standard Emoji Rendering Logic

Is your feature request related to a problem? Please describe.
The WordPress ecosystem currently renders standard emojis inconsistently. Self-hosted sites use s.w.org SVGs as a fallback, WordPress.com uses s0.wp.com Twemoji SVGs, and the WordPress Reader often displays these as proxied PNGs. This fragmentation creates a poor user experience and will complicate the future implementation of custom emojis.

Describe the solution you'd like

1. Establish a single, unified rendering engine and CDN source for all standard emojis across the entire WordPress ecosystem (self-hosted, WordPress.com, Reader).
2. Provide a core option for site administrators to disable system font fallback and enforce consistent SVG/PNG rendering to ensure all users see the same emojis.
3. This unified renderer (e.g., using an updated version of Twemoji.parse()) should serve as the foundation for future custom emoji support.

Describe alternatives you've considered
Maintaining the current fragmented system, which will lead to increasing compatibility issues as new emoji sets are released and custom emoji functionality is added.

Additional context
A consistent foundation is necessary before a reliable custom emoji system can be built. This addresses a long-standing inconsistency in WordPress core.

---

Issue 2: Implement a Custom Emoji Registration and Management System

[Feature Request] Emoji: Implement a Custom Emoji Management System

Is your feature request related to a problem? Please describe.
WordPress currently has no native system for site administrators to register and manage custom emojis, a feature common on platforms like Mastodon and Misskey. This prevents communities from creating a unique visual identity and expressive vocabulary.

Describe the solution you'd like
Create a new system, likely via a core feature or canonical plugin, for managing custom emojis. This system should include:

1. An admin panel for uploading and registering new custom emojis.
2. Support for rich metadata for each emoji, inspired by Misskey's implementation:
   • Name / Shortcode (e.g., :my_emoji:)
   • Tags and Categories (for organization)
   • NSFW (Not Safe For Work) Flag
   • License Information
   • Local/Global Option (to control whether an emoji is included in Fediverse transmissions).
3. A dedicated CDN path for serving these custom emojis (e.g., custom-emoji.my-site.com/emoji/).

Describe alternatives you've considered
Relying on third-party plugins, which can lead to fragmentation and lack of a unified standard for ActivityPub federation.

Additional context
This feature is essential for WordPress to be a competitive, modern platform for building online communities, especially in a federated context.

---

Issue 3: Improve Custom Emoji Federation in the ActivityPub Protocol

[Improvement] ActivityPub: Improve Custom Emoji Federation and Reaction Aggregation

Is your feature request related to a problem? Please describe.
In the current Fediverse, custom emoji reactions are not aggregated across instances. If a user on instance-a.com reacts to a post with :my_emoji:, and a user on instance-b.com uses their own :my_emoji:, the two reactions are treated as different because their source URLs are different. This fragments user interaction and undermines the purpose of a federated network.

Describe the solution you'd like

1. Instead of identifying custom emojis solely by their name and URL, implement a system based on a unique identifier. This could be a hash of the image file or a Globally Unique Identifier (GUID).
2. When transmitting emoji data via the ActivityPub protocol, include this unique identifier alongside the standard name and URL.
3. Receiving instances should use this unique ID to recognize that two emojis from different instances are functionally identical, allowing them to aggregate reactions correctly.

Describe alternatives you've considered
Maintaining the current system, where user interactions remain fragmented across the Fediverse.

Additional context
Solving this problem would be a significant improvement for the entire Fediverse, not just WordPress. WordPress could lead the way in proposing a standard for more robust emoji federation.

---

Issue 4: Propose a Custom Emoji Federation Registry to Standardize Emojis

[Proposal] Emoji: Propose a Custom Emoji Federation Registry API

Is your feature request related to a problem? Please describe.
The root cause of many custom emoji issues in the Fediverse (reaction aggregation, inconsistent display, etc.) is the lack of a central, or at least a standardized, way to identify and resolve emojis. Each instance manages its own set, leading to federation conflicts.

Describe the solution you'd like
WordPress could take a leading role by proposing and developing a Custom Emoji Federation Registry API.

1. Concept: An open, federated registry (e.g., fediemoji.org) where creators can submit custom emojis. Each emoji would be assigned a unique ID or hash.
2. API Functionality:
   • Provide metadata for each emoji: name, source_url, hash, license, category.
   • Allow instances to sync this public list to their local database.
3. ActivityPub Integration: When transmitting activities, instances would include the original registry ID for any custom emoji used. This would allow any other instance to recognize the emoji and aggregate interactions correctly, regardless of its cached CDN path.

Describe alternatives you've considered
Allowing the current chaotic system to persist, which hinders deep interoperability.

Additional context
This is a forward-thinking proposal that could solve a major pain point for the entire Fediverse. By pioneering this solution, WordPress would solidify its position as a leader in the open, federated web.

[Jiwoon-Kim]

@jeherve
Proposed Approach: Integrating Fediverse Reactions with WordPress.com Likes

Here's the direction I recommend for handling reactions, specifically with an eye towards WordPress.com and the Fediverse:

1. Aggregate Fediverse Reactions via Jetpack Like: Modify the Jetpack "Like" system to be capable of collecting and representing reactions from the Fediverse. Essentially, treat Fediverse reactions as a source of "likes" that Jetpack can track.

2. Assign Fediverse Handles to WordPress.com Accounts:

3. Jetpack Like Operates Primarily for Fediverse: Focus Jetpack Like's functionality to be primarily geared towards handling Fediverse interactions. While it shouldn't break existing WordPress.com like functionality, the core development effort should be on making it a robust Fediverse reaction aggregator.

4. Store Emoji Reactions as Variations of Likes: Instead of treating emoji reactions as a completely separate system, store them as variations of the "Like." For example, a "heart" reaction would be recorded as a "Like" with a specific type/modifier.

Rationale & Key Considerations

The core reason for this approach isn't necessarily the intrinsic importance of emoji reactions themselves. Emoji reactions are, in fact, a non-standard feature. However, this is specifically about the challenges presented by WordPress.com and the WordPress Reader in a federated environment.

With self-hosted WordPress sites, users can easily manage custom emoji storage on their own instances. This isn't a problem. However, WordPress.com is different. If each WordPress.com blog were to store every possible emoji reaction locally, it would lead to significant data duplication and bloat across the platform. We'd end up with redundant copies of the same emoji assets on countless servers.

If we're already building a system to handle Fediverse interactions in this way (using Jetpack Like as the foundation), it becomes efficient to also incorporate emoji reactions as a natural extension. It allows us to avoid the data duplication problem inherent in a decentralized emoji storage approach on WordPress.com.

In short: Building for Fediverse integration solves the emoji reaction storage problem for WordPress.com as a beneficial side effect.

[obenland]

Unify Standard Emoji Rendering Across the WordPress Ecosystem

I doubt "this fragmentation creates a poor user experience" and it's out of scope for this plugin.

Implement a Custom Emoji Registration and Management System

I'm sure there are plenty of other plugins that do that already. I'd also consider this out of scope for an Activtiypub plugin.

Improve Custom Emoji Federation in the ActivityPub Protocol
Propose a Custom Emoji Federation Registry to Standardize Emojis

That is indeed a challenge, but not one that this plugin should solve. Maybe something for the Social Web Foundation to consider, akin their web components effort.

[Jiwoon-Kim]

Subject: Re: Your Feedback - Emoji & Federation

Hi @obenland ,

You're absolutely right to point out that many of these issues fall outside the scope of this plugin, and I appreciate you keeping me grounded. I'm aware that a lot of this stems from considerations specific to WordPress.com.

To be honest, I'm also unsure where the best place to propose solutions to these broader ecosystem problems is. While self-hosting doesn't face these issues, when you consider the scale of the entire WordPress ecosystem – and particularly the needs of wp.com – the scope naturally expands.

I think my thinking was perhaps too ambitious, trying to address potential future challenges alongside the core ActivityPub integration. Your suggestion about the Social Web Foundation and their components effort is a good one, and I'll definitely look into that as a potential avenue for some of these ideas.

Thanks again for the feedback – it's very helpful in clarifying the focus for this plugin.