search

kitsune-soc / kitsune

🦊 (fast) ActivityPub-federated microblogging
https://joinkitsune.org
Other
291 stars 19 forks source link

Make Kitsune to sign outgoing GET requests #267

Open perillamint opened 12 months ago

perillamint commented 12 months ago

Currently, Kitsune is not signing profile GET requests and able to federate with instances which does not require signed GET requests.

However, some Mastodon instances require signed requests to fetch profile and (public / unlisted) toots.

Proposal

Implement signed GET request to enhance interoperability between some Mastodon instances

aumetra commented 12 months ago

Definitely a good addition

Something I also want to mention is that GoToSocial's default mode is "authorized fetch" mode, so to federate with any GoToSocial instance, we have to sign our fetches

perillamint commented 7 months ago

So... here is my abstract idea to choose the key to sign the request:

If the fetch request is initiated by a user with valid session: Use the user key to sign the request. If the fetch request is initiated by an anonymous user: Use the system actor key to sign the request, OR sent out the unsigned request (not desirable, but it will be easier to implement, because it does not depend on #318)

tesaguri commented 7 months ago

If the fetch request is initiated by a user with valid session: Use the user key to sign the request.

I think the use of users' keys has some privacy implications (which I've elaborated on at https://github.com/mastodon/mastodon/issues/34#issuecomment-1703650033) and believe that the system actor's key should be used instead whenever the user's key isn't necessary (e.g. when fetching the outbox of a remote actor whom the requesting user isn't following).

However, I'm not aware of a feature of Kitsune as it stands that fetches remote objects by users' request and doesn't require the user's key. The closest one is GET /api/v1/accounts/search?resolve=true, but the endpoint also benefits from the user's key when fetching private objects. It might still be sensible to have a mechanism for opting out of the use of the key in this endpoint, but that would likely to involve a new Mastodon API parameter and hence should be designed by the upstream Mastodon team first, I think (if they are willing to introduce such a feature).