[feature] Request some API without Auth

[reonokiy]

Is your feature request related to a problem ?

I'm using Elk as the front end. When I want to search a user's profile without login, the mastodon instance works well but the GoToSocial instance cannot access the API without authorization.

Successful Mastodon Examples (the official Elk deployment works with m.webtoo.ls mastodon instance):

• https://elk.zone/@antfu
• https://elk.zone/@gotosocial@superseriousbusiness.org
• Search a user at https://elk.zone/search

The reason is Mastodon allows some public API endpoints, But GoToSocial requires authorization for this API.

Related APIs：

• /api/v1/accounts/lookup
• /api/v2/search
• ...

Describe the solution you'd like.

Add some environmental variables to control whether to allow unauthorized requests and allow public API access like #1039

Describe alternatives you've considered.

NONE

Additional context.

No response

[tsmethurst]

Thanks for opening! We'll have to have a think about this one. It would be nice if users could opt-in to exposing their profile via search, if the admin has decided to expose these endpoints, rather than the admin deciding that all users on the instance should be so exposed. Perhaps we could use the discoverable flag for this...

[daenney]

Being able to have a profile as public seems fine by me, but I don't think we should be removing auth from those endpoints.

If I'm not logged in, and I search for someone on an instance, then I suppose it'll reach out to <instance>/api/v1/accounts/lookup etc. But, /api/v1/accounts/lookup doesn't have to be used for this purpose. Webfinger can do the same and is already available without auth. After that, you can retrieve the actor. In many cases instances will require that request to be signed, if they run in secure mode. I don't think setting a profile as discoverable should opt out of that, as the signature lets us block an instance being bad.

Using /api/v1/search on a remote instance doesn't sit right with me either. My instance shouldn't have to service random unauthenticated search requests performed through its client API. Anyone who has a legitimate use for that endpoint will have an account on my instance. So yes, you'll need to login, but that seems fine by me.

[reonokiy]

Thank you for your reply. I think the most important thing for me is also the public profile page. The APIs I listed (like search and lookup) are just some of the APIs that I have found I get errors when displaying profiles using the elk front end. because the public accessibility of these APIs is not the same as Mastodon. It would certainly be nice if this could display the same content without using these APIs. I just checked webfinger though, and it may only be able to navigate to the user profile interface of the gotosocial server.

As a backend-first app, I think providing a limited access to the profile API without logging in is a reasonable request. If I don't use the gotosocial web interface, there's something odd about the fact that I need to access the APIs of other mastodon servers to display public pages. But exactly which APIs to use is debatable. I may be overlooking a possible problem behind the scenes though. Surely a configurable API access control would be better.

[tsmethurst]

Just for a bit of clarity, can I ask what your use-case is for wanting to expose these APIs?

My understanding currently is that you want to be able to deploy your own Elk instance, and point it towards your GoToSocial instance 'by default'. This would allow anyone (logged in or not) to access your Elk instance at eg https://elk.example.org, and look up public timelines and accounts by making requests to your GoToSocial instance at eg https://gts.example.org, to have those accounts show up in Elk.

So, that would be similar to the elk deployments at:

• https://elk.universeodon.com
• https://elk.cupoftea.social

Which use their respective instances as data providers even for the logged-out view.

Is that correct? Or am I totally misunderstanding what you're wanting to do here?

[reonokiy]

Yes, you're right.

[rbauduin]

As discussed on Matrix, here's another usage currently prevented:
I'm trying to use https://github.com/dpecos/mastodon-comments with GTS.
Seems the mastodon-comment code sends this request: https://$GTS/api/v1/statuses/${tootid}/context
which gets a 401.
This prevents me from using GTS as a commenting system on a static site, which would be a great usage.

[RoblKyogre]

As discussed on Matrix, here's another usage currently prevented: I'm trying to use https://github.com/dpecos/mastodon-comments with GTS. Seems the mastodon-comment code sends this request: https://$GTS/api/v1/statuses/${tootid}/context which gets a 401. This prevents me from using GTS as a commenting system on a static site, which would be a great usage.

apologies for the necropost, but i was setting up the same thing for my own website and was running into the same pitfalls as well. would also like to see this endpoint accessible without auth (given the privacy settings of the user allows it ofc)