April 20, 2022
ActivityPub support in Gitea
The pull request to add go-fed did not get much attention and another was opened instead, with a more concrete goal: adding user keypairs and HTTP signatures. It is significantly larger and includes go-fed: it caught the attention of five reviewers. As expected the size of the go-fed dependency was discussed and although a few ideas were proposed, it is yet unclear when and how it could be accepted in the main Gitea branch. Other technical points were addressed such as proxy awareness or clarified such as the rationale for the Clock type (also discussed in the Gitea development chat room). Once merged it will obsolete the commits implemented a few months ago. In the meantime they are rebased onto Gitea main on a weekly basis without too much trouble (about 2 hours work this month) but are otherwise left unmodified to not duplicate the effort.
A more ambitious undertaking was started to go even further by implementing the inbox and outbox so that Gitea users can follow users on different instances. The code currently only supports ActivityPub-federated following for users on the same instance, since remote following requires modifying the Gitea internals and database to support remote users. A Gitea federation monthly meetup will be scheduled in the next few days to discuss potential changes to Gitea for remote user support.
Friendly Forge Format
The gofff reference implementation now has JSON Schema for all Gitea migration types. The migration is tested with file to file and file to Gitea for issues and comments. Significant time was spent on figuring out how the library should be architectured, the most challenging part being the generic forge package that is used by the migration logic. More details can be found in commit list.
Foreign references (e.g. the mapping between two issues mirroring each other on different forges) are stored in a database. In the context of Gitea this database will be replaced by the Gitea database and the ForeignReference table.
A computer science student asked for advice on applying to Outreachy or GSOC. A few private emails were exchanged because they did not feel comfortable having the discussion in public. It turned out that they did not need the income derived from these programs: their interest was more to learn new technical skills and better understand how Free Software communities work. It was proposed that they visit the forgefriends chat room and ask for orientation, with the promise that there will be a friendly followup. By working on a trivial typo fix in the documentation, they would get a short and friendly introduction to how Free Software communities interact and the tools they use. Their interest was more to AI and deep learning, there was no chance they would stay: this would not have been beneficial to forgefriends. But it would have been beneficial to diversity of the Free Software ecosystem as a whole. Unfortunately they chose to not followup but it is was worth a shot.
The Hostea project started a month ago and is committed to implement federation with both ForgeFlux and forgefriends, even at a very experimental stage. It aims at providing Gitea+Woodpecker hosting, starting July 2022. ForgeFlux and forgefriends would be available for experimentation as soon as they are ready, with the necessary provisions to recover and avoid bugs that would disrupt live Gitea instances. It is a critical first step for forgefriends: it would otherwise be very difficult to field test experimental versions. Even the smaller Gitea instances (such as Chapril) would be relunctant to take the risk of trusting a new federation proxy because of the extra workload it entails.
A few months ago an offer was made to help with the maintenance of forgefed for which there has been no activity or communication in a long time. The lead replied positively a few months later which will help put an end to the status quo. The current specification and web pages can be forked and the work can resume, if and when someone has the time.