[feature] Add config toggle to expose `/api/v1/accounts/lookup` without auth

[mhils]

Describe the bug with a clear and concise description of what the bug is.

Followgraph (website, GitHub) is a tool that allows users to expand their connection graph and find new people to follow. It would be great if that worked with GoToSocial! Right now, when entering my handle, the app fails with a 401 Unauthorized for https://fedi.hi.ls/api/v1/accounts/lookup?acct=max.

https://docs.gotosocial.org/en/latest/configuration/instance/ lists some configuration knobs to expose more APIs to unauthorized users, but based on the docstrings /v1/accounts/lookup does not seem to be one of them. At least for my use case, I feel that /v1/accounts/lookup could just be public/unauthorized.

What's your GoToSocial Version?

0.9.0 git-282be6f

How to reproduce it?

1. Visit https://followgraph.vercel.app/
2. Enter your GTS handle (or use max@fedi.hi.ls)
3. Click "Search"

Anything else we need to know?

Thanks for building GoToSocial! 🍰 😃

[tsmethurst]

Do you mind if I reword the title of this to indicate that it's a feature request for a toggle to expose /v1/accounts/lookup?

[mhils]

Not at all of course, please do!

[tsmethurst]

Alright changed! Not saying we'll actually do it by the way: it seems that the repo is no longer maintained, and the maintainer doesn't seem to have posted on fedi in a long time, so I'm assuming it's a hobby project they threw out there and then bailed on. Which is fine! But maybe not worth compromising our own app's privacy for :thinking: I'm not sure. How necessary do you think this followgraph thing is?

[mhils]

How necessary do you think this followgraph thing is?

Necessary is very subjective. I think the Fediverse would benefit from the availability of a) tools to discover more relevant people to follow and b) algorithmic feeds (that are not engineered towards maximizing outrage).

https://whomtofollow.com/ is another (more recent) example of basically the same idea, failing with GTS for the same reason. FWIW I don't mind making my following list public, I don't consider that to be particularly worthy of protection. But I appreciate that GTS has a privacy-by-default stance. :)

[daenney]

The lookup endpoint is documented as:

Quickly lookup a username to see if it is available, skipping WebFinger resolution.

But it strikes me as entirely pointless, as the information is already available through webfinger. For local accounts the webfinger lookup isn't any more expensive or difficult so the advantage of "skipping webfinger resolution" is 0. When this endpoint says "no I don't know about this account", for a local account that means it doesn't exist. For a remote account, it means they've never seen it before which is not quite the same thing as what the docs would suggest.

Given that the same information is already available over webfinger which is unauthenticated, I think making the lookup endpoint configurably unauthenticated is probably fine.

But all these tools should be using webfinger instead of the Masto client API.

[daenney]

I'm going to close this. It's not something we want to implement.

Making the endpoint unauthenticated would reveal profile information, which is something we don't allow unauthenticated and have no intention of changing. Even if some folks wanted this on an instance, it's likely that not everyone would want to participate, so this would have to be configurable on a per-user basis. There might be better ways of doing this by going through the AP following and followers collections.