Skip to content

Contributing to the Fun Fediverse Development

Contributions to Fun Fediverse Development are welcome. They are best made through pull requests to the main repository. In the following sections, a general vision of where this project should evolve to is outlined. It will hopefully be helpful in deciding if you want to contribute and how.

Technical notes

This website is build using Material for MkDocs. This means that the site is statically generated from markdown files. Generation occurs automatically on updates of the main branch using continuous integration. Similarly, the python package fediverse-pasture is updated on new tags.

The following badge should show the current build status: status-badge

The following badge should show compliance with reuse (licensing): REUSE status


The goal of Fun Fediverse Development is improving the Developer Experience in the Fediverse, and thus making writing new Fediverse applications more fun. This means that what is exposed here should be

  • Easy to use
  • Easy to understand

For example the entries in testing tools all are written in a way to be self contained. So somebody, wanting to use them doesn’t have to consult a lot of documentation. Similarly, test expectations should be provided when it makes the result easier to understand.

For you would be contributor, this means all issues regarding to clarifying something or making it easier to use is welcome.

Second one has to acknowledge that there in the Fediverse, one has problems

  • where application should agree on a common strategy, e.g. general data format or how to authenticate against each other,
  • and also stuff where applications can act very differently, e.g. a text only application will not display any images.

We are addressing this by providing testing tools for the former case and support tables for the latter.


There unfortunately does not exist a single silver bullet solution to achieve this, instead several approaches are taken:

  • Fediverse pasture provides a docker compose environment that is capable of running many existing Fediverse applications. If an application is missing, adding it, would be a great contribution. See this issue list.
  • Fediverse pasture provides tools, e.g. verifying your actor that allow one to test a Fediverse application. Expectations are chosen to ensure interoperability in the Fediverse. This means if your application passes the tests, this part will probably interoperate.
  • For topics, where no clear expectations exist, instead of defining one, we will provide Support Tables. This means the behavior of different applications is documented, so developers are better informed. The generation of the support tables should be automated and reproducible.

Adding new approaches is possible. However, it takes time to mature ideas. For example, I believe that fediverse-features is a good idea. I also consider the idea not mature enough to include here. Currently, it is just another way to state expectations on the Fediverse and not something that necessarily helps a Fediverse developer.