Feature Request: Convert post link to local instance?

[hybridhavoc]

I was wondering if it would be possible to convert post links to one that is local to a defined instance. If I'm running a wall for use by members of my instance, it would ease interactions with posts if posts on the wall would open on our local instance. Ideally this config would be separate from the "servers" entry in the config file, as it can be helpful to pull the wall from a larger instance than one's own.

[defnull]

Sounds useful, but I am not sure if that's possible. Post IDs (and their direct links) are different for each server. Every time server A fetches a post from server B, it assigns a new (local) ID. Only way to compute a link to server B that shows a post from server A would be to search for the post on B to get the local ID there. Triggering a search for every single post would run into rate limits pretty quickly though.

[andypiper]

This is possible if you were to do something like this. Switch out the link to the post with a link in the format:

[LOCAL_INSTANCE]/authorize_interaction?uri=[original_post_link]

This is how Fediverse Explorer does the same thing, and I've tested it as a potential option locally.

It does mean that you'd want to add a way to set the user's local instance, which you could do via a cookie or something (like Fediverse Explorer) and only do the substitution on the front end; or, you could add some kind of server-side profile support if you wanted to be able to run this multitenanted.

[defnull]

I didn't know about the /authorize_interaction endpoint. Its an API defined by http://ostatus.org/schema/1.0/subscribe (don't bother visiting that link, the domain was snatched a while ago... I have no words) and as the name suggest, meant to show a subscribe-page. It also works with posts at the moment, but I'm not sure if we can make that assumption for all (future) versions of Mastodon. It would work, but it's more like hack than a solution.

Fediwall does not have any server-side logic and I'd like to keep it that way, so in order to remember the home instance of a user (and not assume it's the first one listed) we need a concept of a user profile (stored in local storage) and the UI to access and manage it. The same state should also remember manually blocked accounts or posts. Doable, but quite a lot of work to pull off. Let's keep this issue open as a reminder.