Support web+ap fallback handlers

[SoniEx2]

Pitch

The endpoint at https://instance.example/.well-known/protocol-handler?target=:uri should process and handle https://instance.example/.well-known/protocol-handler?target=web%2Bap%3A%2F%2Finstance.example%2F%40User and https://instance.example/.well-known/protocol-handler?target=web%2Bap%3A%2F%2Finstance.example%2F%40User%2Fpost.

Motivation

Some software will rewrite ActivityPub URIs from https to web+ap and open https://instance.example/.well-known/protocol-halder?target=:uri if there is no ActivityPub client (web+ap protocol handler) installed. It would be nice if you could support this endpoint so that users wouldn't be required to install an ActivityPub client.

This is vaguely related to #19679 but coming from a (somewhat?) different perspective.

[trwnh]

what is /.well-known/protocol-handler??? and where is web+ap defined?

[SoniEx2]

https://github.com/fedi-to/fedicraft/blob/default/src/main/java/net/fedi_to/fc/resolve/AccountResolveTask.java

[trwnh]

i meant, where are these "web+ap" and "well-known protocol handler" defined? and why isn't it enough to just fetch the https URI with the activitypub Accept header?

On Sun, Mar 5, 2023 at 05:13 Soni L. @.***> wrote:

https://github.com/fedi-to/fedicraft/blob/default/src/main/java/net/fedi_to/fc/resolve/AccountResolveTask.java

— Reply to this email directly, view it on GitHub https://github.com/mastodon/mastodon/issues/23952#issuecomment-1455060516, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ5OX7WS6MT52EVHCVDXDTW2RYNJANCNFSM6AAAAAAVPVFBRA . You are receiving this because you commented.Message ID: @.***>

[SoniEx2]

it's so it can open tokodon or w/e instead of a random third-party instance that the user can't actually interact with.

[SoniEx2]

help us push this protocol forwards? it's pretty obvious that users want something like this.

well, users don't really care about the underlying protocol. but they do want the surface feature. and this is our implementation of it. there are no competing implementations at this point. (there is a browser extension that attempts to detect mastodon instances and make buttons interactive, but that's a different thing and we don't consider it competing at all. after all, that browser extension wouldn't be able to interoperate with e.g. tokodon. it also has no way of working with other fediverse software like misskey or gotosocial, while this can. actually, the browser extension barely even functions with mastodon instances, and small changes to the theme easily break it.)

[trwnh]

i don't see anything mastodon can do in this case. i don't think it makes sense to say "users wouldn't be required to install an ActivityPub client". if you mean a Mastodon client, you can use the Mastodon API. for example, log in as a user and use the search function to resolve an HTTPS URI. but i can't say more without knowing what it is you intend to do with that data.

[SoniEx2]

mastodon can implement the endpoint above, then we can keep pushing this protocol ourselves. we have interest from users but so far no interest from implementers. we (collectively) need implementers to align themselves with users if we want better UX for federated networks.