It is an exciting time to be building in the Fediverse!

I've been doing a lot of thinking lately around ways in which the experience could be improved for developers looking to get started in Fediverse projects - and by extension, how to improve the space for everyone involved.

There's already an active community around one of the prominent standard protocols (the SocialHub community for ActivityPub). I've had an account there since the beginning of last year, primarily as a reader trying to stay informed about the various activities. However, there's more to developing for the Fediverse than "just" ActivityPub: many of the related projects implement some but not all elements of the ActivityPub standard; there are other important protocols to know about; and, there are new projects looking to federate, appearing over time as the interest grows.

It feels like a good point to offer to help to join some of the dots here. I jotted down some of my thoughts ahead of a meeting that was setup to bring together interested parties from across different Fediverse projects, and I'm sharing the first part of these below. This is very much a starting point, which I'm posting to share and develop with others, collaboratively.

There are broadly two sets of developer documentation and community in the Fediverse space, which are interrelated and overlapping:

1. The “core” Fediverse stack, i.e. ActivityPub and the other ~14 protocols involved (The Federation has a nice description of the protocols it deems part of the core).

   • this is where we might also see "external" projects such as Medium / WordPress / Tumblr / Flickr participate, adding interoperability with the core protocols (Flipboard already mentioned that they are looking at better and more complete ActivityPub implementation at the heart of their system), thus becoming their own instances of... →

2. Individual Fediverse projects, e.g. Friendica, PeerTube, Mastodon, PixelFed, OwnCast et al. These share one or more of the core protocols, so developers are likely to have an interest in the protocols themselves; they may also have their own specific APIs and behaviours (Mastodon is a strong example of that - client app developers talk to the Mastodon API, rather than using ActivityPub directly).

   • there’s potentially a sub-group here, related to individual instances of specific projects, e.g. a particular PeerTube or Mastodon server may have a group of interested developers who wish to add bespoke features for their own use or purpose.

I think of it conceptually as something along these lines (source graphic available here):

In the context of the core, there are already some key developer resources, for example:

• ActivityPub specification - a W3C Recommendation
• ActivityPub Rocks SocialHub community / ActivityPub conference
  • there are some excellent threads and posts in the SocialHub community for folks looking to implement ActivityPub, which are a solid foundation for broader work in this space.
• W3C Social Web Incubator

For the individual Fediverse projects, it is most likely a good idea if each of the projects that wish to deeply collaborate and be part of the conversation, have someone who takes part in these groups and conversations - as well as taking part in the Fedidevs discussion that started over recent weeks out of the Social Web CG, Fediforum, etc. That person could be seen as a sort of "ambassador" between the individual project, and other interoperable participants in the ecosystem.

At the individual project level, there are efforts to build good reference documentation both across the board, and for individual projects. Fedidocs has set out to do this both as a central point for the core technologies, and with links to the end projects; it currently lists FunkWhale, Mastodon and OwnCast.

There is also a third key developer educational need, related to culture and expectation.

In general, there are a number of core pushbacks and concerns around how the technologies are used:

• User privacy and/or expectation as to how their Fediverse posts are shared. We’ve seen various instance admins block apps that attempt to implement features such as universal search, for example. Tracking and other user-hostile behaviours in apps are generally deemed not OK.
  • → “Rights Expression Language” (Bob Wyman)
• Commercial gain / use of the platforms is often a difficult area to navigate.
• Finally, there’s a generally-strong feeling around negative communities that may not meet the ethos of the broader Fediverse communities (this overlaps with the moderation and admin aspects of the growth of the Fediverse space).

If you set out as a developer without staying aware of this third space, your project is not likely to mesh successfully with the others.

I'm looking to collaborate with many of the folks active in the space to help to bring these thoughts together and build better documentation and community resources to describe how to be successful in the Fediverse as a developer.

Ways to get involved (as of now)

• check out the Fedidocs repository on GitHub, and read the proposed FAQ for the Fediverse Developer Network
  • [we’re in the process of moving this to fedidevs.org]
• add @fedidevs@venera.social to your main Fediverse feed, and mention that handle to boost related conversations
• join the new fediverse-devs Matrix room

Check out my related posts on the opportunity for developers on Mastodon!

Explore the Glitch Community Guide to Building for the Fediverse.

(thanks to the folks on today's initial Fedidevs call for their comments and feedback on my earlier draft)

(header image credit: Midjourney v5)