search

mastodon / mastodon

Your self-hosted, globally interconnected microblogging community
https://joinmastodon.org
GNU Affero General Public License v3.0
47.2k stars 7k forks source link

Federated links for anonymous/unauthenticated users #21203

Open muks opened 2 years ago

muks commented 2 years ago

Pitch

Commit 07229089a63151a941e3bf9ff8e2fb5037b14b43 fixed #19652 where federated account links are linked locally, instead of to a remote instance. This change appeared to us after an upgrade from Mastodon 3.x to 4.0.2.

We don't like this change as a remote user's timeline (including all federated posts) appear to unauthenticated users as served by the local WEB_DOMAIN, when browsing a local user's timeline and clicking on a boosted federated post's poster's account. Previously in Mastodon versions < 4, it linked to the federated user's WEB_DOMAIN, but now that user's timeline, images and other resources appear as being served by the local WEB_DOMAIN to unauthenticated users. I can understand why #19562 was implemented for better UI experience for authenticated users, but I feel the original behavior of linking to the poster's WEB_DOMAIN is desirable when browsed by unauthenticated/anonymous users.

Ours is a company Mastodon instance in a country with anti-pornography laws. We want to federate, but don't want non-boosted remote federated content to show up in public timelines.

Instead of hardwiring it one way or the other, could you make this behavior configurable so local admins may configure it as desired?

Thank you

Mukund

Motivation

Mastodon instance operators in countries with anti-pornography laws may be able to configure Mastodon such that non-boosted content will not be served by the local WEB_DOMAIN to the general public (anonymous users).

afontenot commented 2 years ago

This seems more like a bug, because if you try to navigate directly to an external profile when logged out, you get redirected to the original instance. E.g. try this link in a private browsing window: https://mastodon.social/@oxidecomputer@hachyderm.io

Probably the issue is that before the change, the link was external and some JS caught the click when you were logged in and kept you on your home instance, and now, the link is internal, but the JS wasn't fixed to redirect you when logged out.

muks commented 2 years ago

If you see the commit linked in the description, it appears this change was implemented on purpose (i.e., not an inadvertent bug) to keep the user on the local WEB_DOMAIN.

Strike that. I don't know if there's some other layer that's supposed to catch this link and rewrite it for unauthenticated users.

afontenot commented 2 years ago

I just meant that it's a bug in the sense that it's unintended behavior. The point of that commit was to change the URL for logged in users, to avoid sending them to other instances when middle-clicking (or right click, open in new tab). It wasn't intended to change the behavior for logged out users.

Most likely, foreign timeline posts aren't supposed to be rendered at all when logged out - except in cases where it's explicit like the federated timeline. I can't be 100% confident of that part though.

muks commented 2 years ago

@trwnh Could you look at this bug please? I am not able to tell from the commit if it is an inadverent regression, but in any case, could a config option bring back the old behavior when the web user is unauthenticated?