Support auto-redirection by <link rel=alternate type=application/activitypub+json>?

[saschanaz]

Background

It seems the redirection happens only when the interaction popup opens, but what if opening a remote instance can automatically redirect to the home instance, with more generic method than being too implementation-specific?

(I saw you showed some interest in raikasdev/mastodon4-redirect#6 which also does the auto redirection)

Proposed solution

Mastodon and Misskey inject <link rel=alternative type=application/activitypub+json href=(object id)> to the page, that way one can know the page can be loaded as an ActivityPub object. Since Mastodon has an API to resolve such object id, the extension can call the API to get a home instance URL and do the redirect.

Here is a proof of concept written as a userscript: https://gist.github.com/saschanaz/701908eb329af5991061f8813b5bf4bc

Alternatives

• Go contribute to https://github.com/raikasdev/mastodon4-redirect instead?: I figured it may be more useful to contribute to more active project, which is currently this one.

Additional context

(This may replace #104 and the existing Mastodon matcher)

[rugk]

(This may replace #104 …)

What does this have to do with MissKey hmm?

---

Security

In any way, we would need to make sure to not introduce a CSRF risk, because whatever we may only do a redirect to an existing site on such as a click and other link opening, we should never directly execute an action.
Instead, it should always only show that page as the extension currently does (i.e. status clicks show the toot and follow clicks show the intermediate site on your home instance, where you have to click/confirm the action again). I have tried to explain it here, already.

The idea

Mastodon and Misskey inject <link rel=alternative type=application/activitypub+json href=(object id)> to the page, that way one can know the page can be loaded as an ActivityPub object

That is new and sounds great, actually.
Also, the thing I described above can be achieved security-wise, if I understand it correctly. We can keep our current behavior and redirect on these intermediate sites instead.

As such, I think this is a great idea and code-improvement/refactoring (as the mechanism/result should not change for the user).

Go contribute to https://github.com/raikasdev/mastodon4-redirect instead?

Feel free to contribute whereever you want. However, i'd gladly accept contributions here, too.

[saschanaz]

What does this have to do with MissKey hmm?

Because it's supported there too! (BTW, I don't see how #104 can work since AFAICT there is no interaction page on Misskey? Have you tested it? Oh okay, I see how it works, although weird 😅)

In any way, we would need to make sure to not introduce a CSRF risk, because whatever we may only do a redirect to an existing site on such as a click and other link opening, we should never directly execute an action. Instead, it should always only show that page as the extension currently does (i.e. status clicks show the toot and follow clicks show the intermediate site on your home instance, where you have to click/confirm the action again). I have tried to explain it here, already.

That is new and sounds great, actually. Also, the thing I described above can be achieved security-wise, if I understand it correctly. We can keep our current behavior and redirect on these intermediate sites instead.

Yup, I agree that the redirection to the page is enough, and the user can do the action themself after checking the redirection result. The point is when the redirection happens:

• Current behavior: The extension adds some hooks for buttons and redirection happens when the user clicks those buttons. (This by design needs to be implementation specific)
• The PoC behavior: It redirects immediately if it can, and the user will see the content as if they opened it within their home server. The user then will start some action. (Any web page that support ActivityPub, even if indirectly via https://fed.brid.gy, can be supported)

I don't see much value to support redirection by <link> if the extension needs to keep injecting hooks, because that'll still be implementation specific.

[rugk]

Okay, read some more about this and found w3c/activitypub#310, it does not seem to be really standardized (yet), but anyway... it would be good enough to support.

I don't see much value to support redirection by if the extension needs to keep injecting hooks, because that'll still be implementation specific.

Hmm, we need hooks anyway to react on things as far as I see. However that link header could be useful for implementation, as it simplifies this a lot and could e.g. help for #86, i.e. we do not need to open a popup/redirect to that and catch that again in any case. It's refactoring that could be done when doing that.

[rugk]

It redirects immediately if it can, and the user will see the content as if they opened it within their home server. The user then will start some action.

Ah okay, now I understand, so opening any link or so redirects this to your home instance, even if you do not wanted to interact with it. That sounds like a good idea, too. Maybe optional though as it could be quite unexpected.
And from what I see it's CSRF safe as all interaction than happens on your own home instance.

The question would be does it also work with user profiles, i.e. the pages where you usually press the follow button? I guess it should, should not it?

[saschanaz]

The question would be does it also work with user profiles, i.e. the pages where you usually press the follow button? I guess it should, should not it?

Yes for Mastodon and Misskey, haven't tested it on Pleroma. AFAICT I don't think Pleroma supports it at all (although w3c/activitypub#310 (comment) says it did in 2018). I only see <link rel="alternate" type="application/atom+xml"> on Pleroma. (Edit, ah okay, it was supported in MastoFE which is deprecated in 2021.)

A caveat with non-immediate redirect is that <link> won't change when user navigates on the remote server. In that case the user needs to refresh the page in order to trigger this detection properly. A workaround would be to keep some implementation-specific regex for URLs. (It's needed anyway for other implementations that doesn't support <link>.)

[saschanaz]

Hmm, I've been using the immediate redirection for some days and the experience wasn't perfect. Could be better if:

• Use the injection code to add "open it in my home server" button (perhaps with a home icon) for some supported server implementations (so that one can see some extra info in the original page)
• If not, add a position: absolute fallback popup with the same button on the top of the page

What do you think?