Convert fediverse URLs in posts to internal links

[strypey]

When I come across a post that contains a link to a fediverse post, like this one https://mastodon.nzoss.nz/@strypey/103293315214387446 , and click on the link, I get taken out of Pinafore and into the web UI of the instance the link points to. Is there some way Pinafore can test links to see if they point to a fediverse object, and if they do, load it within Pinafore? If they don't contain a detectable fediverse object, obviously the destination page would then open as normal.

[nolanlawson]

That's interesting, I wonder what the Mastodon UI does in this case? I've always just assumed it was designed to work this way.

Arguably you could say that designing it this way avoids virality effects similar to a quote tweet, even if it is a less-than-ideal user experience (but the friction is what limits virality).

Still technically this seems possible.

[nolanlawson]

Although arguably this is a better feature for the Mastodon server (i.e. to change the link) since otherwise the client would have to fire off an HTTP request for every link in order to test whether it's a fediverse link or not. Arguably the server should have a list of known servers which would winnow down the list a lot.

[nolanlawson]

There are also privacy implications since the client would be firing off requests to URLs without the user explicitly clicking on them.

[strypey]

@nolan

There are also privacy implications since the client would be firing off requests to URLs without the user explicitly clicking on them.

My suggestion is that the request only be fired off the first time the user clicks on that link. From that point on, the Pinafore instance in their browser can associated that external link with its internal link in that post and any other in which it appears (if I understand correctly how Pinafore works).

To address the virality issue, maybe there could be a tickbox in the settings to turn it on, and selecting 'enable all' in the Wellness settings would turn it off?

[strypey]

BTW this already seems to sort of work with some URLs, like this one:
https://mastodon.me.uk/@dilgreen/103167002137604715

... in the sense that I can paste the URL into the search tab and have the post loaded as a Pinafore post card.

[Krinkle]

I believe the server generally already fetches mentioned URLs for the open graph / card previews, right?

It's by design and social policy that no previews of toots are shown, however I suppose the server could at least remember that it encountered a fediverse-compatible response, and annotate the HTML anchor link in some way for clients to hook into for native navigation indeed.

Is there an upstream issue for this?

[nolanlawson]

@Krinkle I searched the tootsuite/mastodon repo but didn't find one. Which is surprising, since you'd think someone would have thought of this by now. Perhaps it's worth opening an issue.

Handling it server-side would definitely be better for privacy, and wouldn't require any changes on Pinafore's end.

[strypey]

@nolanlawson

Handling it server-side would definitely be better for privacy

Could it even be a protocol-level issue? Does there need to be a tweak in the AP standard for making fediverse URIs stand out from general web URLs? Not that this would prevent a Mastodon-specific solution, but ...

[nolanlawson]

After some reflection, I think this should be handled server-side. If we proactively test all URLs to see if they're fediverse URLs, it's either bad for privacy (firing off requests to remote servers) or perf (firing off requests to our home server's search API to see if anything returns). If we don't do it proactively, then we slow down every click to an outbound URL, which is annoying. Plus we would have to handle Ctrl-clicks, shift-clicks, etc., and we wouldn't be able to handle right-clicks (save as bookmark), etc.

If the server could figure this out for us, though, then it could annotate the <a> tag (e.g. with attributes) to let us know that it's a fediverse link. E.g. it could embed some structured information so that we don't even need to fire off a search request in the first place. So I think this issue should be filed on Mastodon itself.