loading . . . **Proposal for Fediverse Remote Content Engagement** Updated April 14, 2026 **Tim Chambers,@[email protected]**
_Updated: April 2026_
## **Enhancing User Experience for Remote Social Interactions in ActivityPub Applications**
### **I. Introduction: The Challenge of Federated Interactions**
Decentralized social networking platforms, operating on a federated model where users reside on independent servers (instances) yet can interact across the network, offer resilience and community autonomy. However, this architecture has historically presented user experience (UX) challenges, particularly for interactions initiated from one instance but targeting a user or content on another. This report investigates a long-standing UX issue within the Fediverse: the cumbersome process of handling remote social interactions.
This analysis will describe the core user experience problem and then evaluate three distinct options for solving it, each with different technical assumptions and browser applicability.
We invite further collaboration and study, and if Option C is feasible and if our assertions in this proposal prove true, we strongly recommend it.
* * *
### **II. The Core User Experience Problem: The “Copy-Paste Dance”**
Before exploring solutions, it is critical to define the problem they aim to solve. The core appeal of the Fediverse is its federated nature, yet web interfaces have struggled to make these cross-instance interactions fluid.
When a user, logged into their home instance (e.g., my.home.social), browses to a profile page on a different instance (e.g., another.instance/@remote_user), the process to follow that remote user is convoluted and laborious:
1. **Discovery & Intent:** The user finds a profile on a remote server and clicks the “Follow” button.
2. **The Interrupting Dialog:** Instead of completing the action, a pop-up dialog appears.
3. **The “Copy-Paste Dance”:** This dialog prompts the user to copy the remote user’s full address (e.g., [email protected]).
4. **Manual Navigation:** The user must leave the page they are on and navigate back to their own home instance.
5. **Search & Rediscovery:** The user pastes the copied address into the search bar on their home instance and waits for the profile to resolve.
6. **Final Action:** Once the profile appears within the context of my.home.social, the user can then click “Follow” a second time to finally establish the connection.
This multi-step process is a common source of frustration, described by users as a “clunky copy-paste flow” that is “not very intuitive” and “really broken.” It creates friction that counteracts the core value proposition of seamless federation.
We propose a flow that could be implemented quickly. Options A and B would require no server-side coding inclusion.
Nothing here contradicts standardizing Native Protocol Handler solutions into browsers more fully, without the need for “custom protocol handling.”
This is a solution meant to be implemented near term and in a progressive fashion—to bring the best possible solution to users early and improve it over time.
* * *
### **III. Browser Support of “Custom Protocol Handlers”**
A more integrated solution to the remote interaction problem could involve native browser capabilities, specifically custom URI schemes and the `navigator.registerProtocolHandler` API.
#### **Understanding navigator.registerProtocolHandler and Custom URI Schemes**
The `navigator.registerProtocolHandler()` Web API allows websites to declare their ability to handle specific URL schemes (protocols). For example, a webmail application could register to handle `mailto:` links. In the context of Mastodon and ActivityPub, a custom URI scheme could direct interaction requests to the user’s home instance.
For security and standardization, custom schemes intended for web-based handlers must adhere to certain rules: they must begin with `web+`, be followed by at least one letter, and consist only of lowercase ASCII letters.
The `web+ap` URI scheme has been proposed specifically for ActivityPub objects, aiming to be syntactically similar to https URIs but signaling that the resource should be handled by an ActivityPub-aware application. Its primary purpose is “to explicitly enable the registration of a web-based protocol handler,” which would ideally be the user’s own Mastodon instance. Functionally, a `web+ap` URI is conceived as an https URI with added ActivityPub semantics.
Another proposal, FEP-07d7, suggests `web+activitypub:` with similar aims. While `web+activitypub:` is more descriptive, `web+ap` is more concise and has seen early adoption, such as its support in the Conversations XMPP client.
The core concept is that clicking a link like `web+ap:https://example.com/users/alice` would, after a one-time browser permission prompt, open this link in the context of the user’s home Mastodon instance, which would then manage the interaction (e.g., displaying the profile for a follow action).
Regardless of the final format of this `web+ap` scheme or if another is more appropriate, this is a promising long-term solution that will only become more seamless as standardization and adoption of custom handlers for the fediverse mature.
We recommend using it now—and while in this document we assume `web+ap` in particular, this proposal does assume the need for robust browser support of custom protocol handlers. And of late that has arrived on desktop—with notable gaps remaining on mobile.
* * *
### **IV. Custom Protocol Handler Market Share in April 2026**
_Sources: Browser compatibility data from MDN, CanIUse, and browser documentation. Market share statistics from StatCounter Global Stats (March 2026)_
The practical utility of a custom URI scheme hinges on browser support for `navigator.registerProtocolHandler()` for web-based custom schemes. This support remains inconsistent across the browser landscape.
It is crucial to differentiate this from general support for URI schemes. The key capability for `web+ap` is the registration of web-based handlers by arbitrary websites.
#### **Browser Support for navigator.registerProtocolHandler (for Web-Based Custom Schemes) as of April 2026**
Desktop Browser | Support | Details & Notes
---|---|---
Google Chrome (Windows/Mac/Linux) | ✅ Yes | Supported since Chrome 13. Requires HTTPS (secure context) and valid scheme. Custom protocols must use a `web+` prefix (only lowercase letters after `web+`).
Microsoft Edge (Chromium-based) | ✅ Yes | Supported since Edge 79. Edge Legacy (v12–18) did not support this API.
Mozilla Firefox (Desktop) | ✅ Yes | Supported since Firefox 3. No major limitations beyond spec requirements.
Opera (Desktop) | ✅ Yes | Chromium-based versions follow Chrome’s behavior.
Apple Safari (macOS) | ❌ No | **Still not supported in any Safari version (through Safari 26.x).** Safari actively opposed protocol handler support for extensions when discussed at WICG in 2023.
Mobile Browser / Platform | Support | Details & Notes
---|---|---
Chrome for Android | ❌ No | Not supported. Never implemented on Chrome for Android (tracked as Chromium bug #40964464).
Firefox for Android | ❌ No | Not supported. The rewritten “Fenix” Firefox for Android does not implement registerProtocolHandler.
Safari on iOS (iPhone/iPad) | ❌ No | Not supported. iOS Safari does not implement the API.
Opera (Android) | ❌ No | Not supported.
Samsung Internet (Android) | ❌ No | Not supported.
Android WebView | ❌ No | Not supported.
iOS WebView (WKWebView) | ❌ No | Not supported (same engine as Safari).
#### **Verdict on Browser Support**
**Desktop browsers:** Chrome, Edge, Firefox, and Opera support protocol handlers, representing approximately **89%+ of desktop browser market share**.
**Mobile browsers:** As confirmed by CanIUse (February 2026), **no mainstream mobile browser** currently implements `navigator.registerProtocolHandler()` for web-based custom schemes.
**Global usage supporting protocol handlers:** According to CanIUse (February 2026), approximately **34% of total global web traffic** can invoke web-based custom protocol handlers today across desktop and mobile browsers. This is down from the ~40% estimated in 2025 due to continued mobile traffic growth.
**Current browser market share (StatCounter, March 2026):**
* Chrome: 66.7%
* Safari: 17.9%
* Edge: 5.79%
* Firefox: 2.33%
* Samsung Internet: 2.06%
* Opera: 2%
This highlights that while the feature is well-supported on desktops, the vast mobile user base remains unaddressed by browser-based protocol handlers—necessitating alternative solutions.
* * *
### **V. New Development: Mobile App Adoption of web+ap (April 2026)**
While browser support on mobile remains absent, **mobile apps are adopting the web+ap URI scheme directly** , bypassing the browser entirely:
* **Fedilab****:** web+ap support shipped (confirmed complete April 11, 2026)
* **Holos Discover** (Fedilab’s search engine) is implementing `web+ap` support
* **Tusky** has an open issue (#5027) to add support
* **Conversations** (XMPP client) supports `web+ap`
This is significant because it breaks the chicken-and-egg problem. Android apps registering as handlers for `web+ap:` links means users could tap such a link and have it open directly in their Fediverse app—bypassing the browser entirely.
This creates a viable path forward: even without mobile browser support, mobile users could benefit from protocol handlers if enough apps adopt the scheme.
* * *
### **VI. New Development: Chrome 146 Extension Protocol Handlers (March 2026)**
A significant development that could eventually solve the mobile browser gap: **Chrome 146 shipped experimental support for protocol handler registration via browser extensions** (March 2026).
#### **Background**
Igalia, funded by the Open Impact Foundation’s IPFS Implementations grants program, implemented support for declaring protocol handlers directly in browser extension manifests. This capability already existed in Firefox since 2017; now Chrome matches.
Full details: Protocol Handler Registration via Browser Extensions
#### **How It Works**
Instead of using the Web API (`navigator.registerProtocolHandler()`), extensions can declare handlers in their manifest:
json
“protocol_handlers”: [
{
“protocol”: “web+ap”,
“name”: “Fediverse Helper”,
“uriTemplate”: “https://my.home.social/authorize_interaction?uri=%s”
}
]
Key differences from the Web API:
Web API | Extension Manifest
---|---
Requires visiting the site | Declared at install time
Requires user activation (click) | Runtime approval on first use
Same-origin handler URL required | Can cross origins (with consent)
Per-site registration | One extension covers all sites
Manual management | Lifecycle tied to extension
#### **Why This Matters for the Fediverse**
A “Fediverse Helper” browser extension could:
1. Declare `web+ap` as a protocol it handles
2. Prompt the user once for their home instance URL
3. Redirect all `web+ap:` links to the user’s home instance
4. Work across all Fediverse sites without per-site setup
This is simpler than Option B (per-site JavaScript prompts) and doesn’t require server-side changes like Option C.
#### **Current Status**
* **Chrome 146:** Available behind experimental flag
chrome --enable-features=ExtensionProtocolHandlers
* **Firefox:** Supported since 2017
* **Safari:** Actively opposed this feature at WICG
#### **Mobile Implications**
This is currently desktop-only. However, Chrome for Android shares the Chromium codebase. If this feature:
1. Moves from experimental to stable in desktop Chrome
2. Ships to Chrome for Android
3. Extension support on mobile Chrome improves
…then mobile Chrome users could install a Fediverse extension that handles `web+ap:` links natively. This would be a significant step toward solving the mobile protocol handler gap.
**Timeline uncertainty:** There’s no guarantee Chrome will ship this to mobile, and Safari/iOS remains opposed. But this is the most promising development for mobile browsers we’ve seen.
**Vivaldi:** Curious if Fediverse-forward browser Vivaldi could include this in their Android mobile application.
* * *
### **VII. Option A: Native Protocol Handler Solution (For Supported Browsers)**
This option represents the ideal, most seamless user experience, but it relies on native browser capabilities that are not universally supported.
#### **A. The Envisioned “Seamless” Flow**
With this solution, the “Follow” button on a remote profile would be a link using a custom URI scheme, like `web+ap:https://another.instance/users/remote_user`. The interaction would unfold as follows:
**First-Time Interaction (One-Time Setup):**
1. The user clicks the `web+ap:` link.
2. The browser intervenes with a native prompt: “Allow my.home.social (your home instance) to open all web+ap: links? [Allow]”.
3. The user clicks “Allow,” and the browser stores this preference.
**Redirection and Action:**
1. The browser redirects the `web+ap:` URI to a specific endpoint on the user’s home instance (e.g., `https://my.home.social/authorize_interaction?uri=...`).
2. The home instance loads the page, displaying the remote profile within the user’s familiar interface. A clear “Follow” button is presented.
3. The user clicks “Follow” to complete the action. This achieves the “two clicks and zero text inputs” ideal.
**Subsequent Interactions:**
* When the user clicks another `web+ap:` link, the browser, having stored the permission, directly opens it on the home instance, achieving a “one-click” initiation.
#### **B. Technical Mechanism: navigator.registerProtocolHandler**
This flow is enabled by the `navigator.registerProtocolHandler()` Web API, which allows a website (the user’s home instance) to register itself as the handler for a specific URL scheme (like `web+ap:`).
#### **C. Critical Limitation: Browser Support**
The practical utility of Option A hinges entirely on browser support as outlined in Section IV.
* **~89% of desktop traffic:** Supported
* **~0% of mobile browser traffic:** Not supported
* **~34% of total global traffic:** Supported
We offer two fallback JavaScript solutions: One (Option B) assuming Client-Side-Only JavaScript, and another (Option C) that assumes server-side code can be added to the Fediverse server.
* * *
### **VIII. Fallback Option B: Client-Side-Only JavaScript Fallback (No Server Code)**
This option is a fallback for browsers that do not support Option A. It assumes no code changes on the user’s home server and functions entirely with client-side JavaScript that could run on any federated website.
#### **A. Concept and Mechanism**
This approach relies on explicitly asking the user for their home instance and storing it.
1. **User Prompt for Home Instance:** The first time a user attempts a remote interaction on a fediverse site, a script running on that page prompts them to enter their home instance URL (e.g., “To enable seamless interactions, please enter your home server”).
2. **Local Storage:** The provided URL is then stored in the browser’s `localStorage` under a key like `activitypub.homeInstance`. Because localStorage is scoped to the domain, the user would need to perform this action once for each different remote domain they visit.
3. **Link Rewriting:** On subsequent visits to that same remote domain, the script will read the stored home instance URL and dynamically rewrite remote interaction links to point to the user’s home server’s `/authorize_interaction` endpoint.
4. **Final Confirmation on Home Server:** After the user clicks the rewritten link, they are redirected to their own server. Their server will then load an interface asking the logged-in user to give final approval for the action (e.g., “Do you want to follow this user?"). This ensures the user is in control and explicitly “blesses” the interaction before it is completed.
While not ideal, this Option has only two steps (versus the current four steps for Mastodon, and zero cutting and pasting) and it has the strong advantage over the status quo in that it is only done once, ever, for each server from then on.
#### **B. Sample Implementation (Prompt-Based)**
javascript
(function() {
const homeServerKey = ‘activitypub.homeInstance’;
let homeServer = localStorage.getItem(homeServerKey);
function promptForHomeServer() {
const instanceUrl \= prompt(
"To enable seamless social interactions, please enter your Mastodon home server (e.g., https://mastodon.social). You should only need to do this once on this site:"
);
if (instanceUrl) {
try {
const url \= new URL(instanceUrl);
homeServer \= url.origin;
localStorage.setItem(homeServerKey, homeServer);
// ... proceed to rewrite links ...
} catch (e) {
alert("Invalid URL format. Please try again.");
}
}
}
if (\!homeServer) {
// Trigger the prompt when needed, e.g., on a follow button click.
document.getElementById('remoteFollow')?.addEventListener('click', (e) \=\> {
e.preventDefault();
promptForHomeServer();
});
} else {
// ... rewrite links on page load ...
}
## })();
### **IX. Fallback Option C: Enhanced JavaScript Fallback (With Server-Side Cooperation)**
This fallback solution works for browsers that do not support the Custom Protocol Option A, but unlike Option B, this assumes that server-side code is available on the user’s home instance to assist the process.
#### **Important Technical Limitation: Cross-Origin Storage**
**Option C as originally conceived does NOT work across domains** due to the browser’s same-origin policy. `localStorage` is strictly same-origin:
* `my.home.social` writes to localStorage → only accessible on `my.home.social`
* `another.instance` cannot read localStorage from `my.home.social`
This means Option C only helps in the more limited scenario where users are browsing links to remote content **while staying on their own home instance’s domain** —which, while helpful, is not the primary use case that causes friction.
**The viable approaches therefore remain:**
* **Option A:** Custom protocol handlers (desktop-only, ~34% global reach)
* **Option B:** Prompting for home instance as a JavaScript fallback (universal)
* **Mobile apps:** Direct `web+ap:` scheme support (emerging)
#### **A. Limited Use Case for Option C**
If Mastodon itself includes this feature in its codebase, every Mastodon instance would install:
1. A **writer script** (sets the home instance key when user is logged in)
2. A **reader script** (checks that key, rewrites buttons)
Because both scripts run on the same domain (each user’s server), there’s no cross-origin issue **when the user is browsing their own instance**. The reader doesn’t need to touch localStorage from another site—it only reads the home instance from the local user’s own instance (where it’s already stored), and sends users back to it via rewritten interaction links.
However, this does not solve the primary friction point: users browsing remote instances directly.
#### **B. Sample Implementation**
**1. Patch for Home Server (Writer Script):**
javascript
// Placed in a component that loads for authenticated users
useEffect(() => {
try {
const isLoggedIn = window.__initial_state__?.meta?.me;
if (isLoggedIn) {
const origin = window.location.origin;
localStorage.setItem(‘activitypub.homeInstance’, origin);
console.log(`[ActivityPub UX] Home instance auto-set to: ${origin}`);
}
} catch (e) {
console.warn('[ActivityPub UX] Could not auto-set home instance', e);
}
}, []);
**2. Script on Remote Pages (Reader Script):**
## javascript
const homeInstance = localStorage.getItem(‘activitypub.homeInstance’);
if (homeInstance) {
const remoteLink = ‘https://kolektiva.social/@someuser';
const redirectUrl = `${homeInstance}/authorize_interaction?uri=${encodeURIComponent(remoteLink)}`;
// Rewrite the href of the link element to redirectUrl
} else {
// Fallback to Option B’s prompt, or do nothing.
}
### **X. Recommendations**
Given the current browser landscape and emerging mobile app adoption:
1. **Deploy Option A (protocol handlers) now** for the ~34% of users who can benefit from it. Desktop users on Chrome, Firefox, Edge, and Opera get a seamless experience.
2. **Implement Option B as a fallback** for all other users. The one-time prompt per domain is far better than the current copy-paste dance.
3. **Advocate for web+ap adoption in mobile apps.** The emerging adoption by Fedilab, Holos Discover, and potentially Tusky creates a path where mobile users can bypass browser limitations entirely. Newsmast, Surf, and other Fediverse apps should consider adding support.
4. **Build a “Fediverse Helper” browser extension.** With Chrome 146’s experimental extension protocol handler support, an extension could handle `web+ap:` links declaratively. This would work on Firefox today and Chrome (experimentally). If Chrome ships this to stable and eventually to Android, it could solve the mobile browser gap.
5. **Continue pushing for mobile browser support.** Chrome for Android bug #40964464 should be prioritized by the Fediverse community.
6. **Watch for Object Links (FEP-e232).** Mastodon’s CTO has proposed a simpler approach where servers tag ActivityPub URLs automatically, allowing apps to open content directly. If implemented, this could solve the problem at the protocol level.
The path forward is clear: progressive enhancement. Ship what works today for the users who can benefit, while building toward a future where seamless cross-instance interaction is universal.
* * *
### **XI. Conclusion**
The “copy-paste dance” remains one of the Fediverse’s most frustrating UX problems. But the pieces for a solution are falling into place:
* Desktop browser support is strong (~89%)
* Mobile apps are adopting `web+ap` directly
* Chrome 146 extension protocol handlers could eventually help mobile
* Protocol-level solutions like Object Links are being developed
* JavaScript fallbacks can bridge the gap
The Fediverse community should move from debating protocol strings to shipping implementations. The users are waiting.
* * *
_This proposal invites collaboration and feedback. Contact:@[email protected]_ https://www.timothychambers.net/2026/04/14/proposal-for-fediverse-remote-content.html
