Most of the work done in the past month revolved around writing software within the Friendly Forge Format and struggling to figure out how to implement ActivityPub in Gitea. The chat room that forgefriends shares with ForgeFlux has been welcoming and productive. This absence of problems was cause for an informal celebration.
- A wiki with documentation about the workflow, development notes on Federated following and Federated starring.
- A pull request implementing ActivityPub inbox outbox implementation for discussion purposes.
- An inventory of useful links regarding ActivityPub and federation.
Gusted published an in-depth analysis of the go-fed library and how it could fit in Gitea. The conclusion is unfortunately not good and go-fed cannot be merged in Gitea main. It was suggested to start from scratch, maybe using generics.
The go-ap project was suggested as a replacement. It is another ActivityPub implementation in Go that is actively maintained and has a small binary size. Discussions are ongoing on the mailing list to explore this possibility.
The gofff reference implementation is complete for formats (with their JSON schemas) as well as the package to read/write them from file. The Gitea implementation is mostly complete and tests are added to verify it provides all aspects of the Gitea downloader which it is designed to replace.
A merge request was opened in forgefriends to attempt a replacement of the Gitea migration with the gofff package, which led to adjustments in the API (such as allowing the caller to set a logger of its choice). It’s not functional just yet, but it compiles and looks right from a distance.
The implementation of repositories and pull requests were challenging because they required a modification of the Gitea workflow. In a nutshell the migration process is Gitea is neatly separated between a downloader which reads from the incoming forge and the uploader which writes to the destination forges, i.e. Gitea itself. But the repositories are read by the uploader which breaks this pattern. The gofff implementation introduces a slightly different API where the downloader is in charge of downloading the repository. Although Gitea uses a mixture of the git CLI and go-git it was decided to stick with the git CLI in gofff. The downside is that gofff is not standalone: it depends on the availability of the git client. The upside is that it does not depend on a library that lack features and is not as actively maintained as it was in the past.
As more features are implemented, the fixtures become increasingly complex. They were initially implemented as static files in gofff, just as Gitea does. It is however difficult to work with and was replaced by dynamic fixtures generated from code and composable to create various test cases.
Although Gitea does not transition from using a forked vfsgen to embed for embedding templates because it lacks compression, the size of the schemas is small and it is now used in gofff because it is simpler and natively supported.
The Gitea sdk hides error messages when 4xx error occurs, which happened a few times during test. A bug report was sent and a pull request merged shortly afterwards. It will be available in the next release.
Hostea & al.
A blog post is being drafted and involves forgefriends, Hostea, Easter-Eggs, the Center of Excellence in Artificial Intelligence and Robotics which states they cooperate towards a common goal involving forge federation and Gitea hosting.
A friendly fork was proposed to move forgefed by 6543. Shortly after the issues were scrubbed at the new location and CI configured to publish the updated website at a new location https://forgefed.codeberg.page/.
A user working on what appears to be a student project used all CI resources and blocked other users during a few hours. This is the first incident of the kind.
Since NLnet directly and indirectly funds work towards federation in Gitea, the addition of the logo to the Gitea home page was proposed and approved.