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.
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?
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.
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.
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.
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.
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
ā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
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.
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:
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.
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.
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 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.
@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
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).
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.
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
