MoodleNet and CommonsPub: a peek into the rollercoaster of creating a federated app

Rollercoaster (Christina Boemio via Unsplash)

Think of well-known social networks such as Facebook and Twitter. They all have something in common: they’re centralised information silos, controlled by a single organisation. We wanted to do something very different with MoodleNet, a new resource-centric social network for educators. We wanted it to be federated, based on the latest technologies and approaches to community-building. This is in keeping with Moodle Core, open source software which is developed by Moodle Pty Ltd and customised by Moodle Partners and other organisations.

In 2018, after a lot of research and testing, we envisioned MoodleNet as a social network that not only anyone could join, but anyone could help run; a decentralised network to empower global knowledge sharing and collaboration. For this reason, MoodleNet had to not only be open source but also find a way to connect together users across different ‘instances’. It was at this point, we realised that ActivityPub, an awesome new protocol for federating apps (which recently became a W3C web standard), would be perfect for our needs.

CommonsPub: “let’s help everyone federate everything”

As ActivityPub is a new protocol, the ecosystem around it is still maturing. We looked for a generic ActivityPub server on which to build MoodleNet and, not finding one, set out to see if we could help build one. After all, the value of a federated social network increases with the number of nodes in the network!

Creating federated apps today is quite a challenge, as developers have to:

  1. Wrap their heads around several different standards
  2. Become aware of the conventions used by existing implementations (to ensure interoperability)
  3. Code that all up in their development language of choice (usually only bothering with the parts they need, resulting in many partial implementations)

Long story short, it can take months to create a functional beta version of a federated app.

From some conversations between Mayel and his friends at the Open Coooperative Ecosystem, he realised that it would be useful if there was a ‘hello world’ starter project to enable developers to build ActivityPub-based federated applications much more easily.

From this came the idea for CommonsPub: a project to create a generic ActivityPub server, as an extensible library/framework. It would give developers lots of common functionality out-of-the-box, so they can focus on the specific logic of their application. It was also beneficial to what we were trying to achieve with MoodleNet, so seemed like a real win-win situation.

Mayel began the process by finding and analysing virtually every federation app and implementation out there (with almost 70 documented projects to date, at various stage of development), looking into what software stacks they used, and the pros and cons of their approaches. From all of these cases, the architecture for CommonsPub began to take form.

We chose Elixir as the main backend language together with Phoenix, a modern framework similar to Ruby on Rails, but so resource-friendly that it can be run on a Raspberry Pi! It made sense to fork Pleroma as an initial starting point, as not only did Pleroma already have working federation, but it was built with a generic database schema which stores ActivityStreams data as-is.

Our original goal when Alex, an experienced Elixir developer joined the MoodleNet team, was to create a framework containing any useful reusable logic and then build MoodleNet’s custom application logic and client API endpoints on top of that. This was not a small undertaking, and proved to be so complex that, over time, Alex ended up rewriting most of the code so that very little (if any) of the Pleroma code remained.

Federation is fundamental for the aims of MoodleNet, but creating a generic library is out of scope

MoodleNet is a small team working on an innovation project using new technologies. As such, we have to make difficult decisions about where to channel our resources. You may be familiar with the Project Management Triangle, often referred to as the ‘fast, cheap, good’ triangle. A project, it is suggested, can only choose two of these.

Right now, our triangle looks more like this:

MoodleNet project triangle

Given its importance, getting federation working for MoodleNet is now taking precedence over anything else. We’ve frozen all unrelated backend development until federation is ready. Given our resources and scope, MoodleNet could not achieve federation (i.e. launch on time with more than a single Moodle-run instance) at the same time making all the backend code generic in the way the CommonsPub project intended.

As a result, the MoodleNet team has decided not to continue contributing to the development of CommonsPub as a generic federated server. Instead, we are focusing on implementing federation as soon as possible in what is becoming a more MoodleNet-specific backend. To be clear, we’re forking the CommonsPub repository, and continuing our development in the MoodleNet repository, so that we can focus on delivering on our federated project roadmap without worrying about how generic the resulting code is.

CommonsPub is now in the hands of the free software community

CommonsPub continues to exist as a project, but will no longer benefit from development time from Moodle Pty Ltd. This, of course, is likely to affect the timeframe for CommonsPub becoming a viable foundation on which other projects can build their federated apps.

In other words, CommonsPub is now fully in the hands of the free software community. If you’re interested in what might come next for the generic library, please read the follow-up post at the CommonsPub website.


Thanks to Mayel for his assistance with this post. Image by Christina Boemio via Unsplash