Add peers API endpoint toggle to Server Settings

[dariusk]

This PR adds back the admin panel toggle for the api/v1/instance/peers endpoint, which was removed in #19407. It lives under Administration -> Site Settings -> Discovery.

This also expands the hint text to explain further what the endpoint is used for. Added a "Recommended" tag since it was recommended in v3 before it was removed.

Fixes #22222

[PinballsWizard]

Out of curiosity, is it possible to also restore activity_api_enabled (provides api/v1/instance/activity) which was similarly removed from the admin interface in the same change as peers_api_enabled?

[dariusk]

@PinballsWizard Oh, good idea. I will certainly implement that in Hometown, and I will make a similar PR here too.

[dariusk]

@PinballsWizard Done! See #22833

[dariusk]

@Gargron I have noticed that the peers endpoint does not show suspended or silenced domains. Is that intended? If so I may need to change the wording here because that is an indirect information leakage about who you federate with.

For example, if mastodon.social is missing from the list, you could of course claim that your server has never discovered it, but that seems highly unlikely and someone could reasonably infer from peers that you block or silence the server.

[ineffyble]

@dariusk My understanding is that is intended, and I recently made a PR to fix the Misskey implementation to match.

[ClearlyClaire]

I'm not sure “Discovery” (maybe a new “Other” section would make more sense) is the right fit for it, but otherwise I'm all for it.

[ClearlyClaire]

@Gargron I have noticed that the peers endpoint does not show suspended or silenced domains. Is that intended? If so I may need to change the wording here because that is an indirect information leakage about who you federate with.

For example, if mastodon.social is missing from the list, you could of course claim that your server has never discovered it, but that seems highly unlikely and someone could reasonably infer from peers that you block or silence the server.

It is intended, as you don't want to make blocked servers any easier to discover, and a while ago, people misinterpreted the peers list to mean those were instances you were actively peering with.

[dariusk]

It is intended, as you don't want to make blocked servers any easier to discover, and a while ago, people misinterpreted the peers list to mean those were instances you were actively peering with.

Just to be clear, I think this makes blocked servers easier to discover than simply listing out all known servers (through inference, as I mentioned in my example of mastodon.social) -- but also, yeah, I could see people interpret it as a list of servers you federate with and misunderstandings arising from that. I also certainly don't want my server potentially advertising the existence of the domains I have blocked. So I think the filtering of the list is a compromise but a decent one.

[ineffyble]

It creates plausible deniability, which is enough. Maybe less plausible in the case of mastodon.social, but honestly I don't think anyone cares if someone's suspended m.s.