FEP-07d7: A Custom URL Scheme and Web-Based Protocol Handlers for Linking to ActivityPub Resources

Hello!

This is a discussion thread for the proposed FEP-07d7: A Custom URL Scheme and Web-Based Protocol Handlers for Linking to ActivityPub Resources.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

This specification addresses sometimes difficult interactions with ActivityPub resources hosted on remote servers. It defines a custom URL scheme which can be used by custom web-based protocol handlers to route hyperlinks to those resources to the user’s preferred server. It additionally advises when ActivityPub servers can include these links in HTML views they generate, and how clients and servers can implement those web-based protocol handlers.

2 Likes

A off content technical point: The reference section does not render correctly. The source is:

## References

- \[ActivityPub\] Christine Lemmer Webber, Jessica Tallon, [ActivityPub], 2018
- \[Web-based Protocol Handlers\] Mozilla Developer Network, [Web-based Protocol Handlers]
- \[HTML Living Standard\] WHATWG, [HTML], 2023
- \[Fedilinks\] Fedilinks Authors, [Fedilinks]

## Copyright

CC0 1.0 Universal (CC0 1.0) Public Domain Dedication

To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.


[RFC-2119]: https://www.rfc-editor.org/rfc/rfc2119
[ActivityPub]: https://www.w3.org/TR/activitypub/
[Web-based Protocol Handlers]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/Web-based_protocol_handlers
[HTML]: https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
[ActivityStreams]: https://www.w3.org/TR/activitystreams-core/
[ActivityVocabulary]: https://www.w3.org/TR/activitystreams-vocabulary
[MastodonRemove]: https://github.com/mastodon/mastodon/pull/8127
[Mastodon14187]: https://github.com/mastodon/mastodon/issues/14187
[Mastodon19679]: https://github.com/mastodon/mastodon/issues/19679
[Issue1]: https://codeberg.org/fediverse/fediverse-ideas/issues/1
[Fedilinks]: https://fedilinks.org/spec/en/6-The-web-ap-URI

Anybody an idea what exactly happens here and how to fix it?

1 Like

Markdown is cursed :woman_shrugging:t2:

I can edit it a little later to get it to codeberg’s liking

2 Likes

Great FEP! I hope it will be implemented and used :slight_smile:

Just a point: some ActivityPub softwares allows only some kind of contents.

For example Peertube can’t open Mastodon threads.
Pixelfed only opens image posts.
Etc…

How can a Peertube instance register itself only for Peertube links?
Should we also implement handlers as web+activitypub+peertube or web+activitypub+video?
And if so, how could we make a single href compatible with bot web+activitypub and web+activitypub+xxxx?
Have you any thoughts on this?

1 Like

As outlined in the FEP, Mastodon briefly registered a custom protocol handler for web+mastodon a long time ago, but this was quickly removed it due to bad UX in web browsers.

There are many UX shortcomings, but they mostly fall in these two categories:

  • providing fallback for web+activitypub: links (there is no clean way to see if a link is supported)
  • providing clean UX for registering a protocol handler: currently, on Firefox, registering a protocol handler brings up a banner with some text like “Add “mastodon.social” as an app for web+activitypub links?”, which is very confusing to users when not presented with some context first. This is made worse by the fact that as far as I know, you cannot know whether you have already registered a protocol handler, so you can’t really have an in-app prompt to register a protocol handler like we have for notifications.

That would be up to the application, but I think the best course of action is that an application shouldn’t register as a handler of it doesn’t have a reasonable expectation of being able to handle an arbitrary activity pub object. Apps will still have the option to just not do this if they can’t support it.

I can also imagine that the application could redirect the page to the origin server as a last resort fallback mechanism, which is essentially the same as the current experience with regular hyperlinks.

1 Like

I don’t really understand why that’s such an unacceptable user experience. If the app registers in response to a user clicking something that says what it’s going to do, then there should be no problem. People aren’t all that put off by the native browser chrome, except when it’s clearly preventing the page from doing something they didn’t want it to do in the first place.

I also think the world is different place than it was 5 or 6 years ago. There’s a much more robust ecosystem of mastodon-compatible apps, and of fediverse services. There’s more demand for this capability than there used to be, and I think that will encourage rapid uptake. I think it’s also important to establish a standard mechanism for apps to support, otherwise that demand will likely turn into a multitude of competing standards. And that would be a bad user experience.

2 Likes

I would register the Peertube instance. Then have the Peertube instance register a fallback handler. So the Peertube instance forwards requests for unparsable objects to say Mastodon.

1 Like

Not perfect, but could do the job.

I agree!

I agree, and that’s what we do for notifications. However, with notifications, we can query the state and only show the prompt when the permission has neither been explicitly denied or accepted already. With protocol handlers, we can’t know if we have already asked, if it was registered, or if it was refused. There is no method to query the registration state, just a method to register, which returns immediately without information.

Agreed, but on the browser side, the situation has not changed much.

1 Like

Apart from the UX shortcomings of current browsers regarding registering web protocol handlers, here are a few more remarks about the proposal itself:

  • having provisions to provide optional intent is a good thing, but I’m not comfortable with just appending that to an existing query string: the original query string describes the ActivityPub object, not an action to be performed on it, and it does not look like a good fit to add an intent, in addition to the (low) risk of naming collisions
  • I am not sure why intents such as flag or block should be forbidden, external moderation/safety tools could potentially make use of them (with appropriate confirmation flows in the client apps of course)
  • the first example has a typo, writing hfref instead of href
  • I personally think it would make sense to outright requiring absolute URLs, I do not think omitting the domain or the scheme is useful, and having this requirement could simplify the FEP a bit
  • “The server SHOULD also offer a similar option to de-register as a handler” there is no browser API to do that (Edit: I stand corrected, there is https://developer.mozilla.org/en-US/docs/Web/API/Navigator/unregisterProtocolHandler, although it is poorly supported)
  • “Servers MUST NOT attempt to automatically register as a handler again after a user has declined to allow it.” there is no browser API for the web application to know
1 Like

There is a deregister method for browsers. It’s not universally implemented, but that’s normal. But I understand apps are at the mercy of their respective platforms. That’s why the proposal is mostly SHOULDs.

As far as not automatically registering after the user declines, that’s trivially implemented by not automatically registering at all.

I am not sure why intents such as flag or block should be forbidden, external moderation/safety tools could potentially make use of them (with appropriate confirmation flows in the client apps of course)

My thinking with that requirement is that anything that makes it easier to enlist people into mass reporting efforts is undesirable.

having provisions to provide optional intent is a good thing, but I’m not comfortable with just appending that to an existing query string: the original query string describes the ActivityPub object, not an action to be performed on it, and it does not look like a good fit to add an intent, in addition to the (low) risk of naming collisions

That’s fair. I had mixed feelings about it, too. I think Mastodon used to prepend the intent onto the url, and that seems viable. It’s a little more work for the handlers, but I think that’s also ok. Would you prefer that?

I can bother some people on mozilla.social that we have needs regarding protocol handlers and the Fediverse. If mozilla takes the Fediverse seriously, they should have some Firefox manpower to fix our issues.

This is a vague idea of how to get what @Claire mentions in:

resolved. However, I think Firefox / mozilla input might be valuable.

4 Likes

Oh, good catch, I was not aware of this!

Yes, but it also means you’ll basically never prompt the user to register it, or always prompt for the user to register it. The best I can think of given the current API is a somewhat hidden button that once clicked will start the registration flow, and will appear to do nothing if the registration is already enabled. Same for unregistering, we could also have a button alongside the button to register, but they would both stand side-by-side and clicking on them would appear to do nothing. Since we don’t have an API to query the registration state, we must display both, and can’t provide any feedback once it’s clicked.

For comparison, the flow for notification permissions in Mastodon is to not automatically request it, but have a very visible prompt displayed in the notification area:
image

If you click it, it starts the flow, if you accept in the browser, Mastodon knows it, and won’t display this again until you revoke the authorization. If you reject it, Mastodon knows it, and won’t display this again unless you remove the permission block. Something like this is not currently possible with protocol handlers.

1 Like

This is a very rough mock up, but I imagine a flow like this. I’ll likely implement something similar in my app.

And of course, none of this is even a question for any other client. PWAs can register handlers during install by specifying them in the manifest, and native apps can use the OS-provided tools.

1 Like

I have some questions about Intents being part of this proposal. The proposal says “Also keep in mind that the handler MUST provide a mechanism for the user to confirm or decline to perform the intended action.” So that means that when other sections of the proposal say ‘one-click’ it would really be two-click. For software that implements this proposal, devs can’t rely on the existing user interface that people use to interact with the ActivityPub object, they need to instead implement a new UX for confirm/decline flows on each of these intents. This increases the burden of implementing the proposal by quite a bit, compared to just displaying the object with no intents.

Since a click is not saved regardless, I think the “Link with no intent” section of the proposal is most relevant. Once users open the ActivityPub object in their client, they can take any action they wish, without a confirmation flow, using the UX they are familiar with already. This relates to what @Claire mentioned regarding appending to the existing query string, since fedi software does not already support these queries (eg https://portend.place/smitten?intent=follow is not valid).

I agree with @jenniferplusplus

I think it’s also important to establish a standard mechanism for apps to support, otherwise that demand will likely turn into a multitude of competing standards. And that would be a bad user experience.

Various web-based protocol proposals have been floating around but nothing has become the standard. In my opinion aiming for a simple implementation with a low burden on fedi project devs is the most likely way to reach widespread support. See the FediLinks web+ap URI which has implementations in Feditext, and Tokodon. My Akkoma pull request is still open.

2 Likes

@Claire I believe the installation of PWAs can now come with automatic registration of protocol handlers, so we might be able to improve the UX of protocol handlers by prompting the user to install the PWA for Mastodon

1 Like

Hi!

You’re right that handling intents appropriately is a larger development effort. That’s part of why I made it entirely optional. Intent support can be added after the initial basic support, or even never. I personally don’t even want them. I actually wasn’t going to include intents at all, but when I was researching other proposals, it seemed a lot of those discussions got derailed by this topic. I was hoping to avoid that by including the mechanism from the start, in a way that won’t fracture application support (another common problem once this topic comes up).

1 Like

For sure, I see that a ton of comments on the fediverse-ideas thread are distracted by the intent/action possibilities. I didn’t see anyone there even mentioning confirmation and CSRF prevention so I think they are maybe just not seeing the full consequences yet. The mastodon github issue (#19679) is similarly preoccupied with the follow operation. It would be nice to create a follow flow with the fewest possible clicks but for me personally it’s a lower priority than just opening the given user profile on your home server, and avoiding the clunky copy-paste flow that currently exists.

I have nothing against optionality and I’m not trying to be overly critical, my worry is just that people will get distracted by this additional functionality and become less interested in implementing handling for the protocol. I have been surprised that something resembling this protocol is taking so long to gain traction and I’m wondering if it’s because devs aren’t understanding how simple it could be. Compare the implemention in Feditext which showcases how few lines are needed for a native app to implement handling.

1 Like

i have taken to manually typing elk.zone/ between https:// and the homeserver when I want to follow someone, such is my burning hatred of the clunky copy-paste flow

2 Likes