Beyond the beta: revisiting the MoodleNet whitepaper and looking to the future

Roadmap

One of the things that we get asked on a regular basis is “when will feature X going be a part of MoodleNet?”

The MoodleNet beta is scheduled to be released at the Global Moot in November and, after that, the team will set our sights on a v1.0 release in Q2 2020.

Let’s revisit the MoodleNet whitepaper to have a look at the original 17 recommendations and what might end up in a v1.0 release next year, and a v2.0 release the year after:

Original recommendations Timescale Comments
#1: MoodleNet should respect copyright law while allowing educators to share their resources as freely and openly as possible. 2019 (beta) MoodleNet will be dedicated to openly-licensed resources, as outlined here.
#2: Open Educational Practices should be supported in MoodleNet by providing educators with tools to find, create, remix, and share each other’s resources. 2019 (beta) The ability to ‘find’ and ‘share’ OER will be available in the beta, and we will re-evaluate the desirability of ‘create’ and ‘remix’ functionality after garnering feedback from users.
#3: MoodleNet should provide educators with powerful functionality that is easy and pleasurable to use. 2019 (beta) After feedback received during value proposition testing process, we have redesigned the user interface of MoodleNet to make it easier to use and more ‘delightful’.
#4: MoodleNet should allow users to create and manage multiple accounts. Serious thought should be given as to the possibility of allowing some interactions to be anonymous, or pseudo-anonymous. 2021 (v2.0) The use of multiple accounts on a single instance (without logging out and then in again) is out of scope for the MoodleNet beta. Creating multiple accounts and being able to switch between them is not a priority feature for the team at the moment, but something we plan to get to eventually.
#5: Although easy to join and use, MoodleNet should be a robust, decentralised, federated system that does not have a single point of failure. 2019 (beta) Federation is something that we are on-track to implement for the MoodleNet beta. Although MoodleNet will have a ‘mothership’ for the purpose of search and discovery, instances do not have to be connected to it to be connected to one another.
#6: MoodleNet should put the user in control of all of their data. All data held about a user should be compliant with the terms of the GDPR and be removable from the system. Users should be given fine-grained controls over who can see personal data and information they have added. 2020 (v1.0) After a great deal of work on a DPIA, MoodleNet will be compliant with the majority of the GDPR. We will prioritise more fine-grained controls for v1.0 in 2020.
#7: MoodleNet should allow for digital credentials to be created, exchanged, and displayed. These should reflect the diverse and wide-ranging interests of users. 2020 (v1.0) We have already begun to issue Open Badges for contributions to the MoodleNet project. We would like to explore much richer functionality, linked to a wider Moodle strategy.
#8: The aim should be for MoodleNet portfolios to become the default place for educators to tell the story of their professional lives. 2020 (v1.0) For MoodleNet to become the default place for educators to tell their professional story, we need to respond to users. The basic functionality for this will be shipped in the beta, but we also plan to add the ability for users to show off digital credentials and list their job history.
#9: MoodleNet should employ end-to-end encryption on all messages sent through the system. It should also be clear to users who will be able to see their communications (e.g. public / group / one-to-one) 2020 (v1.0) For the beta, MoodleNet will be completely open, with no private messaging or groups. As a result, end-to-end encryption is not required until more private / locked-down aspects of MoodleNet functionality are developed in 2020.
#10: To the greatest extent possible, MoodleNet should be interoperable with open standards, including the import and export of data to and from other social networks. It should have an API that allows others to build upon the core functionality it offers. 2020 (v1.0) We are building MoodleNet upon open standards and licensing it in the most permissive way we can. Facilitating the migration of accounts to other social networks and building an API is an important part of our roadmap, and something we plan to get to after the public beta.
#11: MoodleNet should aim at helping educators create Communities of Practice, adding features and taking UX decisions that help with this (e.g through ‘call to action’ buttons). 2019 (beta) The MoodleNet user agreement and covenant for instance administrators outlines ways in which we will insist on certain minimum standards for instances connected to the HQ ‘mothership’. Over and above this, however, we expect MoodleNet communities to differ in their approach to their levels of formality and types of actions they see as acceptable.
#12: The three elements of news, status updates, and messaging should be controlled by users in MoodleNet. They should be separate if the user wishes, and combined if they prefer an approach more like other social networks. 2021 (v2.0) Although we have diverged from the tripartite approach of news, status updates, and messaging in the current MoodleNet UI, we still have in mind different ways in which MoodleNet can be used. We will make the notifications settings increasingly granular so that users can choose how they want to be informed of updates.
#13: MoodleNet should provide a raw, unfiltered feed to users, and make this available via an API that developers can build upon. Any other views or types of feed should be in addition to this. 2020 (v1.0) Every MoodleNet instance has a feed which is shown by default to local users on the ‘Discover’ page. Once we open up MoodleNet, all public posts will be readable by anyone without logging in.
#14: To provide a disincentive for ‘clickbait’ headlines and sensationalist content, MoodleNet should provide mechanisms to collaboratively rate the content shared in the network. 2019 (beta) For the reasons outlined here, we have declined to build a traditional rating system (e.g. with five stars) for resources. It is too subjective. However, we do want to surface quality content, so users will be able to like and boost resources.
#15: MoodleNet should provide a way for educators to be recognised for the contributions they make to the community, including in financial ways. 2021 (v2.0) Given the number of features we need to build out, the MoodleNet team is not prioritising the ability for user-to-user transactions.
#16: To avoid advertising within MoodleNet, members should be able to support the development of new features through membership and/or subscription options. 2020 (v1.0) Options around sustainability for MoodleNet are explored in this document. Our current thinking is that it is organisations, rather than users, who should pay for MoodleNet. By building MoodleNet plugins and adding them to MoodleCloud, we can provide a value-add that enhances the MoodleCloud proposition.
#17: MoodleNet should encourage the development of OER by educators through easy-to-use crowdfunding options. 2021 (v2.0) Crowdfunding is not a priority at the moment and so will be something we get to after, for example, events functionality.

This, of course is EXTREMELY tentative, but that means:

2019 (beta)

  • #1: MoodleNet should respect copyright law while allowing educators to share their resources as freely and openly as possible.
  • #2: Open Educational Practices should be supported in MoodleNet by providing educators with tools to find, create, remix, and share each other’s resources.
  • #3: MoodleNet should provide educators with powerful functionality that is easy and pleasurable to use.
  • #5: Although easy to join and use, MoodleNet should be a robust, decentralised, federated system that does not have a single point of failure.
  • #11: MoodleNet should aim at helping educators create Communities of Practice, adding features and taking UX decisions that help with this (e.g through ‘call to action’ buttons).
  • #14: To provide a disincentive for ‘clickbait’ headlines and sensationalist content, MoodleNet should provide mechanisms to collaboratively rate the content shared in the network.

2020 (v1.0)

  • #6: MoodleNet should put the user in control of all of their data. All data held about a user should be compliant with the terms of the GDPR and be removable from the system. Users should be given fine-grained controls over who can see personal data and information they have added.
  • #7: MoodleNet should allow for digital credentials to be created, exchanged, and displayed. These should reflect the diverse and wide-ranging interests of users.
  • #8: The aim should be for MoodleNet portfolios to become the default place for educators to tell the story of their professional lives.
  • #9: MoodleNet should employ end-to-end encryption on all messages sent through the system. It should also be clear to users who will be able to see their communications (e.g. public / group / one-to-one)
  • #10: To the greatest extent possible, MoodleNet should be interoperable with open standards, including the import and export of data to and from other social networks. It should have an API that allows others to build upon the core functionality it offers.
  • #13: MoodleNet should provide a raw, unfiltered feed to users, and make this available via an API that developers can build upon. Any other views or types of feed should be in addition to this.
  • #16: To avoid advertising within MoodleNet, members should be able to support the development of new features through membership and/or subscription options.

2021 (v2.0)

  • #4: MoodleNet should allow users to create and manage multiple accounts. Serious thought should be given as to the possibility of allowing some interactions to be anonymous, or pseudo-anonymous.
  • #12: The three elements of news, status updates, and messaging should be controlled by users in MoodleNet. They should be separate if the user wishes, and combined if they prefer an approach more like other social networks.
  • #15: MoodleNet should provide a way for educators to be recognised for the contributions they make to the community, including in financial ways.
  • #17: MoodleNet should encourage the development of OER by educators through easy-to-use crowdfunding options.

As well as suggestions from the community (via user testing and Changemap) these feed into the MoodleNet Roadmap

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