Milestones for federation grant

Federation
1

Milestone: go-fed implementation

The go-fed library implements the ActivityPub protocol and the forgefed vocabulary. It is integrated in Gitea to enable the concrete implementation.

  • Refactor codebase to integrate go-fed library, and create initial middleware to accept json-ld payloads
  • foundations of integration testing to ensure Gitea is able to federate with itself

Milestone: user private keypairs

Activitypub defacto standard requires signing federating request with HTTP Signatures, these keypairs are internal to the application and allow other instances to confirm that a specific instance performed an action (to confirm that a specific user took an action then users should continue to manually verify commit signatures via GPG)

  • Refactor user settings DB schema and to use the UserSetting table
  • Add the actor API endpoint to obtain its public key to verify HTTP requests
  • Implement sending and receiving a signed ActivityStream note

Milestone: ActivityStream vocabulary

A minimal subset of the ActivityPub vocabulary allows interoperability with other servers such as Mastodon. A user from a Gitea instance can be followed and will display its activity, either via forgefed or via notes if the vocabulary is lacking.

  • Implement AP outbox for instance
  • Implement AP inbox for instance
  • Follow remote users
  • Unfollow remote users

Milestone: Forgefed : evolution of the vocabulary

The forgefed vocabulary has not been updated in over a year and never use in real world situation. It needs to be adapted for the need of Gitea.

  • adapt Commit forgefed vocabulary into needs of Gitea
  • adapt Repository forgefed vocabulary into needs of Gitea

Milestone: Link with external data

External users are represented in Gitea and can be linked with a native Gitea user. It is used to keep track of the relationship with user authenticated via, for instance, OAuth2 providers such as a third party forge (Gitea, GitLab, etc.). A similar representation is required to associate a project, an issue, a pull request with its federated counterpart located in another forge.

  • add a database representation for external issues
  • add a database representation for external pull requests
  • add a database representation for external project

Milestone: Converting external references

An issue is referenced from a pull request with a short mention such as #2345 or !5445. These references are relative to the project being federated and must be converted when represented in the context of another federated forge.

  • Reference external users in comments
  • Reference external PRs in comments
  • Reference external issues in comments

Milestone: Rate Limiting

As Gitea becomes more well-known and federation becomes possible, preventing inappropriate use and preventing too much load due to requests will become more and more important.

  • Rate Limit API requests
  • Rate Limit User signups
  • Rate Limit issue creation/commenting in UI

Milestone: Reporting / Video conferences

Monthly report published with detailed information about the work done regarding federation since the last report, including links where it can be audited.

Organize a monthly public, online, meeting to discuss the monthly report. The video conference is open to the general public and recorded.

Diversity

Improving the gender and linguistic diversity is an ongoing challenge for every Free Software project, Gitea included. It must be addressed by concrete actions to improve the situation. Users and Repositories need to be able to block interactions from harassing individuals. The rate limiting milestones above are also related to this.

  • Allow users to block other users from interacting with them
  • Setup self-hosted translation interface to allow contributors to Gitea to submit translations for Application and documentation
6 Likes
2

cc: @dachary @zeripath

1 Like
3

Thanks for putting this together. One question:

Is this supposed to be “Users and Servers”? It seems to me that those are the two obvious points of decision and filtering. If not, how would it work for Repositories?

4

Sentient Dodecahedron proposed to help with the implementation in the development chatroom. Other developers could also be interested to help in the same way.

At present @techknowlogick and @zeripath are the only beneficiaries of the grant and will get paid when they provide proof to NLnet that they implemented items from the workplan above. If someone else does it, they cannot be paid: this is fair.

But it does not mean they will get less funding. If an item turns out to be implemented by someone else, they can replace the item with another. For instance if a conversion for external references in comments already exist, the Milestone: Converting external references could be redefined to implement them in the repository description and projects.

I think it is a sensible way to address the collaborative nature of a Free Software project. Some people declare their intention to work on some tasks (that’s what the workplan is about) but this should not prevent other people from implementing a task if they are motivated to do so sooner rather than later.

In a nutshell, if someone implements a task from the workplan it will not create a problem, on the contrary: it will allow to go further than expected.

2 Likes