Change interaction modal in web UI

[ClearlyClaire]

This builds upon #24842 by:

• fixing the CSP issues using a dedicated invisible iframe helper
• adding proper support for ActivityPub URIs and acct URIs, thus providing compatibility with existing versions of Mastodon even when WEB_DOMAIN ≠ LOCAL_DOMAIN, as well as third-party fediverse software
• tweaking the auto-completion slightly to feel snappier and avoid suggesting a bare domain when the user is typing an URL with a path, or a full handle
• allowing autocompletion without ElasticSearch (prefix only, and no weighing by number of accounts)
• tweaking the wording slightly to hint at the ability to enter full usernames

Everything except the domain name autocompletion is done client-side.

The description of the original PR is still relevant:

This is a rework of the remote interaction modal. Instead of suggesting people to copy-paste the permalink into their favourite Mastodon app or interface, we let them enter their home server's domain (the input also accepts full username/domain handles and URLs), we save this in local storage for future visits, and redirect them to their home server's view of said profile or post.

(the video has an older version of the wording, but the flow remains the same)

demo.mp4

---

Fixes MAS-115

[ClearlyClaire]

I fixed an issue with webfinger requests being blocked by the Content-Security-Policy by doing them from a special iframe with its own CSP (more restrictive on some parts, but allowing connect-src to https:), and communicating with the main app with postMessage.

I also added support for webfinger queries on URIs and acct: URIs. Most existing fediverse implementations support that to some extent. This is all done client-side. However, I have not changed the wording yet, which still instructs to use the bare domain.

Finally, I also changed the input to not be saved to local storage if it could not be used to get an interaction URL (the fallback for bare domains is not considered a failure).

I still have a few things I want to do:

• adding support for domain auto-completion without requiring Elasticsearch
• increasing compatibility by preferring the use of ActivityPub ids rather than shortened URLs
• improve the wording of the modal

[ClearlyClaire]

cc @trwnh

[trwnh]

I'm not entirely sure which parts of the original proposal got addressed and which ones didn't. Could you answer this checklist? (Some items are added for completeness, and may be better suited as followup PRs)

Form input:

• mastodon.social (bare domain)
• https://mastodon.social (full domain)
• trwnh@mastodon.social (user@domain)
• @trwnh@mastodon.social (full handle)
• mastodon.social/@trwnh (uri with assumed https scheme)
• https://mastodon.social/@trwnh (uri with explicit https scheme)

Form handling:

• Get href from Webfinger link of rel: https://www.w3.org/ns/activitystreams#proxyUrl
• If the previous is unavailable: Get template of rel: http://ostatus.org/schema/1.0/subscribe and substitute
• If the previous is unavailable: Try hardcoded /authorize_interaction on extracted domain

Webfinger:

• Respond to ?resource=https://LOCAL_DOMAIN and return instance JRD
• Respond to ?resource=https://WEB_DOMAIN and return instance JRD
• Respond to ?resource=https://ALTERNATE_DOMAINS and return instance JRD
• Respond to ?resource=https://mastodon.social/@trwnh as alias for acct:trwnh@mastodon.social
• Respond to ?resource=https://mastodon.social/users/trwnh as alias for acct:trwnh@mastodon.social
• Include an item in links with rel: https://www.w3.org/ns/activitystreams#proxyUrl and use href instead of the nonstandard template (for both user JRD and instance JRD)
• For the instance JRD: include an item in links pointing to the instance actor

/authorize_interactions:

• Accept id parameter in addition to uri (behaves exactly the same way)
• Accept POST in addition to GET (because POST is technically required for as:proxyUrl as defined by ActivityPub, and GET is technically extension behavior)

Actor endpoints:

• Add proxyUrl and point it at /authorize_interactions

---

Essentially, the original proposal, slightly modified and reproduced here for convenience, new parts italicized:

• take the user's input
  • if it's an https uri (starts with https):
    • try webfinger against the domain component
    • get the rel: https://www.w3.org/ns/activitystreams#proxyUrl link.
      • else, get rel: http://ostatus.org/schema/1.0/subscribe and substitute for template
      • else, show the old copy-paste hint dialog
  • if it's a user@domain (contains @ ignoring first character):
    • try webfinger for that acct:user@domain
    • get the rel: https://www.w3.org/ns/activitystreams#proxyUrl link.
      • else, get rel: http://ostatus.org/schema/1.0/subscribe and substitute for template
        • else, try /authorize_interaction
          • else, show the old copy-paste hint dialog
  • if it's a bare domain (else?):
    • try webfinger for that https://domain
    • get the rel: https://www.w3.org/ns/activitystreams#proxyUrl link.
      • else, get rel: http://ostatus.org/schema/1.0/subscribe and substitute for template
        • else, try /authorize_interaction
          • else, show the old copy-paste hint dialog

[ClearlyClaire]

For now, I have added no support for proxyUrl, although I see how this could be useful. One complication is that doing a POST request navigation from the Web UI will require some thinking to do securely without widening the CSP.

[ClearlyClaire]

@trwnh I implemented support for as:proxyUrl as you requested, but I am not sure how much of a good idea that is. My understanding is that it is for proxying the JSON objects when doing C2S ActivityPub, not to provide interactive paths. In practice, what I implemented does not allow that, and supporting this flow does require a few hacks, as well as dropping the CSRF protections for that endpoint (not a big deal, but still)

[erincandescent]

My understanding is that it is for proxying the JSON objects when doing C2S ActivityPub, not to provide interactive paths

Correct; it is for proxying JSON objects and more importantly media when doing C2S ActivityPub (as in the intended S2S/C2S model, the client receives the raw unmodified JSON-LD). It's a workaround for the fact that nobody figured out a delegated authentication model (user@example.com's client gets a token which authenticates them as themselves to example.net) during the spec development process

[erincandescent]

(Today there's lots of prior art on delegated authentication, but it's all in the OAuth/OpenID Connect camps)

[ClearlyClaire]

I reverted the commits adding support for the https://www.w3.org/ns/activitystreams#proxyUrl the way @trwnh was advocating for, as this is not the actual purpose of those endpoints and I feel using them like this would only muddle things further.

Instead, I went back to http://ostatus.org/schema/1.0/subscribe which is already the current muddy de-facto standard for the fediverse.

Having a less muddy endpoint would make sense but this should be carefully designed (e.g. not use as:proxyUrl for an unrelated purpose), and I think this should not be blocking this PR, which in its current state provides full backward compatibility and the wider range of compatibility we ever had on this feature.

I have also rewritten the frame's script as Typescript, with dynamic checking on responses from remote servers.

[ClearlyClaire]

• Respond to ?resource=https://LOCAL_DOMAIN and return instance JRD
• Respond to ?resource=https://WEB_DOMAIN and return instance JRD
• Respond to ?resource=https://ALTERNATE_DOMAINS and return instance JRD

What is returned in those cases is the JRD for the instance actor, which does include a rel: http://ostatus.org/schema/1.0/subscribe link template.

[trwnh]

i'm fine with deferring the proxyUrl discussion until later, but i don't actually think it's different than this usage. you would be using it for your client (the instance) to resolve the remote object by its id. is that not what we're doing here? the bit about authentication is a red herring, as you can proxy public objects this way, and in fact this proxying is necessary because of how the "instance" model works as your user-agent and client.

[ClearlyClaire]

i'm fine with deferring the proxyUrl discussion until later, but i don't actually think it's different than this usage. you would be using it for your client (the instance) to resolve the remote object by its id. is that not what we're doing here? the bit about authentication is a red herring, as you can proxy public objects this way, and in fact this proxying is necessary because of how the "instance" model works as your user-agent and client.

But what you're suggesting is not proxying the object as is, it's wrapping it in a totally different interface layer.

[trwnh]

i think you could make the endpoint return JSON-LD with the appropriate Accept header, but the reason i proposed using proxyUrl is basically because of the specified functionality. currently it expects:

• POST
• id param
• check Authorization
• return JSON-LD as per Accept

which pretty much needs only the following extension

• handle GET
• do not require Authorization
• do not require Accept

in both cases, the main action is unchanged: the instance as your client will resolve the id, implicitly using your credentials due to the way the resulting interface will be rendered. public users will see public statuses. private statuses can be loaded via this mechanism for logged-in users. it doesn't matter if you fetch from the network or fetch from the cache or database. if we wanted Mastodon to have partial C2S support then we could make the endpoint return LD when LD is requested. if we wanted it to work for unresolved private objects, we could discuss cross-domain authorization schemes. but as you say, these are not blockers.

still, what we have now is that the "proxy url" is being used to proxy the object through your client (instance). this is very close in semantics to proxyUrl. the authentication and other logic is being handled for you by the instance, which is acting as both Client and Server.

[ClearlyClaire]

Updated the wording and the general design of the modal:

[github-actions]

This pull request has resolved merge conflicts and is ready for review.