Add whitelist mode

[Gargron]

Fix #11237

• Authorized fetch mode
• Only process accounts from allowed domains
• Disable LD-Signatures
• Disable app-only and unauthenticated REST API access
• Admin UI for whitelisting domains
• Disable activity and peers APIs
• Disable /about and /about/more pages
• Disable profile directory
• Disable unauthenticated access to public account and status pages as well as feeds

[ClearlyClaire]

Seems mostly good, obviously still missing UI.
Also, switching an existing instance to whitelist mode should be considered. As far as I can see, the current state of this PR will still allow remote followers from non-whitelisted instances to receive local toots, but not send interactions back.

[kpcyrd]

Wouldn't this discourage self hosted instances and instead push everybody into the few instances that are too big to fail, like mastodon.social?

[ClearlyClaire]

@kpcyrd I understand the concern, but I think a whitelist mode remain useful both for some small communities and for stuff like schools or other organizations. In both cases, “big instances that are too big to fail” such as mastodon.social are probably not what those whitelist-based instances would be interested in federating with in the first place.

[ClearlyClaire]

• Disable activity and peers APIs
• Disable profile directory
• Disable unauthenticated access to public account and status pages as well as feeds

Those are all things I am not sure about and that can (or should imho, for the last one) be changed independently.

• Disable /about and /about/more pages

I am pretty concerned about this one, people may want to have approval-based signup on a whitelisted instance, it makes sense for them to have /about and /about/more.

Also, the case of switching from a blocklist-based to a whitelist-based approach on an existing instance will not remove existing known accounts from non-whitelisted instances from search results, and it will not stop them from receiving toots they are mentioned in. I think it also lets people fetch statuses from already-known remote accounts that are not whitelisted?

[Gargron]

I am pretty concerned about this one, people may want to have approval-based signup on a whitelisted instance, it makes sense for them to have /about and /about/more.

I just don't think that "who runs it" and "how many users are there" should be published in this mode, the instance is essentially for private use only. Anything that must still be public can be put on the /terms page.

Also, the case of switching from a blocklist-based to a whitelist-based approach on an existing instance will not remove existing known accounts from non-whitelisted instances from search results, and it will not stop them from receiving toots they are mentioned in. I think it also lets people fetch statuses from already-known remote accounts that are not whitelisted?

Well, how do you imagine it should work? Do you want me to purge the accounts at boot time? That could really backfire if an admin doesn't realize it's what this environment variable does. I would put it into a tootctl command instead.

[ClearlyClaire]

I just don't think that "who runs it" and "how many users are there" should be published in this mode, the instance is essentially for private use only. Anything that must still be public can be put on the /terms page.

I am not completely convinced. For instance, https://awoo.space/about is a whitelist-based instance and does have an about page (and also user directory).

I would put it into a tootctl command instead.

Yes, that is what I would suggest as well.

[Gargron]

I am not completely convinced. For instance, https://awoo.space/about is a whitelist-based instance and does have an about page (and also user directory).

Awoo.space can simply keep using whatever they're using. They don't have to use this code. This PR's objective is not to create more of awoo.space or counter.social, but to help private networks like schools and universities. Networks that do not attract random people from the internet.

[Gargron]

tootctl domains purge --whitelist-mode will remove accounts from domains that aren't whitelisted

[ClearlyClaire]

ActivityPub::InboxesController also inherits from Api::BaseController and should skip :require_authenticated_user!