WIP: Federated following, starring, issues, forks, and pull requests

[ghost]

EDIT: I'm now working on federation for Forgejo, and after it is merged in Forgejo, I will create a new PR to upstream federation to Gitea.

This (very WIP) pull request implements the federated features of following, starring, issues, forks, and pull requests. 🎉

Much of the code is still incomplete, but I wanted to create the PR now since I'd like to get some feedback on some of the high-level design decisions here, such as the UI, or how remote users and repos are handled.

Remote users

This PR stores remote users in the database using the new LoginType Federated, with the full username@instance.com as the username.

More information: #2

Closes #9045

Following

See #19981

ForgeFed vocabulary implementation

This PR includes an implementation of the ForgeFed vocabulary using a custom fork of go-ap. The fork exports more helper functions to make it easier to add AP extensions to go-ap. Discussion about this can be found on the go-ap mailing lists.

Issues and comments

I haven't written the implementation for federated issues yet, but it should be relatively easy. Federated commenting works, but Gitea<->Mastodon interoperability is tricky. There is currently an issue in Mastodon that prevents Mastodon users from commenting on Gitea issues. Also, Mastodon has threads and Gitea doesn't.

Forks and pull requests

TODO, since the code will be rewritten to use the AGit flow for handling federated pull requests.

More information: #7

Closes #184, closes #15392

Federation.md

A Federation.md file describes how a certain software uses ActivityPub. This PR's FEDERATION.md describes Gitea's future federation capabilities, not what features that this PR adds to Gitea.

UI

I'm working on a UI right now, see #8. Since the UI is far from finished, for now I'm hand-writing ActivityStreams objects and then POSTing them to the inbox API endpoints with the help of some scripts.

Limitations

This PR only implements a few federated features to prevent the PR from getting too big. For a list of features that will be implemented later but not in this PR, see the task list.

TODO

• Properly cache remote user avatar and public key
• Fix problems with extending go-ap
• Serve issues and pull requests as ForgeFed objects at /api/v1/activitypub/ticket/username/reponame/number.
• Finish starring, issues, and pull requests implementations
• Implement issue, PR, or comment state changes (https://codeberg.org/ForgeFed/ForgeFed/issues/98)
• Finish /authorize_interaction?uri= implementation
• Create redirect UI for redirecting from a remote instance to your instance
• Use AGit flow for federated PRs to save disk space
• Send out activities to followers when starring or creating a repo
• Fix lint errors
• Write integration tests

[Gusted]

Might be me, but we might also implement the prevention of impersonation(AttributedTo still seems to be not checked)

[Gusted]

Uh for performance reasons we likely want to not do this(Increased pagesize is fine), does AP supports list/pages options like this?

[ghost]

AP does support pagination, but the problem is we only want the repo creation actions, but we don't know how many pages of the DB we'll have to query for. Is there a way we can make models.GetFeeds only return repo creation actions?

[Gusted]

2373b41 is the right direction but we need to implement star action types in another PR so we can remove the stars code.

[ghost]

Might be me, but we might also implement the prevention of impersonation(AttributedTo still seems to be not checked)

Thanks for reminding me to implement that. I'll do it today.