What is a federated social network?

MoodleNet federation

In the first of a monthly series of posts at moodle.com, MoodleNet Product Manager Doug Belshaw explains what federation is and why it’s important.

MoodleNet is our new open social media platform for educators. It is focused on professional development and the sharing of openly-licensed resources, and it is built on a federated model. Let’s explore that further!

Read the post here

MoodleNet Federation Testing Programme

UPDATE: Form is now fixed!

'Network' by John LeMasney used under a Creative Commons CC BY-SA license


We’re looking for volunteers (individuals/organisations) for a federation testing programme we’re running next month. There’s a pretty tight turnaround, so initially we’ll require all communication to be in English, although you’re welcome to set up your test instance in another language.

It’s important to note that this is NOT simply a way to be notified of updates to MoodleNet. It is an expression of interest to run a server requiring both technical knowledge and a time commitment. There will be another rare badge available for those who participate in the programme!

What is ‘federation’?

The easiest way to explain federation is to think about email. Anyone can create their own email address via any provider they choose, and they can use any email software they choose. As the whole system is standards-based, anyone can send an email to anyone else knowing that it will ‘just work’. You only need to know their email address, something like name@emailprovider.com.

If we extend that idea to social networks, so long as a social network adheres to a particular standard, then anyone can send a message or other content to anyone else knowing that it will ‘just work’. In our case with MoodleNet, the standard is ActivityPub, which is already used by social networks such as Mastodon, Peertube, and Pixelfed

To begin with, we are interested in federation between servers running MoodleNet. Thanks to ActivityPub, users will be able to join communities, follow collections, and interact with other users, no matter where they created their account. And then, in addition, users of other ActivityPub-compatible social networks (‘the Fediverse’) will be able to follow and interact with MoodleNet users, and vice versa. 

API federated
Image CC BY-ND Bryan Mathers

Why do we need a testing programme?

The aim of the MoodleNet Federation Testing Programme is to test all aspects of federation, both between MoodleNet instances and the wider Fediverse. The programme will be successful if it:

  1. Validates the statements we have made about data processing in MoodleNet’s DPIA
  2. Demonstrates that users on any MoodleNet instance may follow, join, and interact with communities and collections on any other MoodleNet instance. 
  3. Confirms the value proposition of organisations running their own MoodleNet instances
  4. Establishes that search and discovery is possible across MoodleNet instances connected to the Moodle HQ API-as-a-service (‘mothership’)
  5. Shows that Fediverse accounts can follow and interact with MoodleNet users.

We envisage that the testing programme will cover three areas:

  • Interaction between MoodleNet instances
    • Join communities, and follow users and collections
    • Add resources to MoodleNet collections
    • Discuss, comment, like, and flag content
  • Search and discovery 
    • Find MoodleNet users, collections, and communities
    • Locate MoodleNet resources with a specific tag
    • Browse fresh content from across all mothership-connected instances
  • Integration with the wider Fediverse
    • Follow Fediverse users from MoodleNet
    • Display Fediverse status updates which @mention MoodleNet users or communities
    • Interact with Fediverse users (e.g. reply to an @mention)

Who should be involved in the programme?

We’re looking for individuals and organisations with both the time and technical knowledge to be able to test MoodleNet effectively. This includes moderating communities, updating their instance to the latest version, and providing regular feedback to the MoodleNet team.

Ideally, we would have a combination of Moodle Partners, educational institutions, organisations, and interested individuals who:

  • Will accept the MoodleNet federation testing programme agreement (forthcoming)
  • Have a working knowledge of Linux server administration with Docker containers (MoodleNet’s stack includes Elixir, PostgreSQL, and React)
  • Can dedicate around 3-5 hours per week to testing MoodleNet over the testing period

When will the programme start?

Servers connecting together in a hashtag pattern
Image CC BY-ND Bryan Mathers

We will begin the testing programme when MoodleNet federation is ready to test. This should be before the end of August 2019, although it also depends on the corresponding user interface work being completed by that time. 

How do interested parties apply?

Please use the following form to express an interest in the federation testing programme. Note that not all applications will be successful, as we are looking for a range and spread of use cases.

We are currently finalising the User Agreement and MoodleNet Covenant for Instance Administrators and will share these with successful applicants, as well as in a blog post.

Header image: Network by John LeMasney used under a Creative Commons CC BY-SA license

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