MoodleNet/tech/architecture

<< Back to MoodleNet Tech index

Note: terms in bold are defined in the glossary at the end of the document.

---

There are broadly three approaches we can take to building out MoodleNet’s platform architecture. These are:

1. Fully peer-to-peer
2. Fully federated
3. Federated with HQ API-as-a-service [Note: this is the architecture approach that was selected]
4. Centralised SaaS

This document outlines three of the potential architectural approaches, and explains why we have chosen to focus on the second option. We believe that creating MoodleNet with a federated architecture combined with a HQ API-as-a-service will balance an open approach with a sustainable way of managing the project.

Irrespective of architectural decision, we plan for MoodleNet to be consistent with Moodle’s philosophy of libre software. Moodle Core is licensed under the GNU General Public License (GNU GPL), which is compatible with the GNU Affero General Public License (GNU AGPL) that we intend to use for MoodleNet. The latter is recommended for software being run over a network. Like Moodle Core, MoodleNet is an open source platform, meaning that anyone can adapt, extend or modify the software for both commercial and non-commercial projects without any licensing fees.

---

Federated with HQ API service

Moodle HQ will run a MoodleNet HQ API-as-a-service serving as a central index of information across the network. This enables consistent discovery and search experiences across all MoodleNet instances (including the one provided by Moodle HQ).

Each MoodleNet instance stores the full data of local users, communities, and collections (including personal information, private messages, and public comments/discussions).

The database of the MoodleNet HQ API service contains lists of all public communities, collections, resources, and users across the network, along with a copy of some metadata. A search index also sits behind the API to enable fast and accurate search results. Each item always refers back to the originating MoodleNet instance for the full data (e.g. membership, permissions, comments/discussions).

In practice, this means that the MoodleNet network, while federated, is reliant upon the MoodleNet HQ API service for search and discovery. This provides users with a better and more consistent experience, reducing fragmentation and spreading the shared content more widely, and also gives Moodle HQ more control over the overall network.

Another HQ API service, the Moodle resources repository, could also provides hosting for Moodle course content that users share on MoodleNet. This could later be facilitated with P2P file sharing protocols like IPFS.

This network can also be based on existing protocols and standards to form a decentralised collection of nodes that send, receive, and store data. The data handling module can be based on an extended ActivityStreams data format and at least some of the APIs on the ActivityPub protocol to ensure compatibility between systems.

Interactive diagram: https://whimsical.co/Xh45SHnfdAuNAJgGqQu8hL

Advantages of a federated network:

• Robust and resilient
• Scales horizontally
• Private data stays on each user’s home instance
• Each instance is responsible for its content (moderation of discussions, etc)
• Standards-based but also extensible
• Open

Advantages of HQ API service:

• Some Moodle HQ influence over the network
• Consistent network-wide search and discovery experiences
• No duplication of resources for core functions like the indexing of resources from OER APIs, global search indexing, and Moodle resource hosting
• Each instance is still responsible for its content (moderation of discussions, etc)
• Moodle HQ controls the evolution/standardisation of content/metadata types and formats

Disadvantages of HQ API service:

• Single point of failure (HQ API service operated by Moodle HQ).
• Moodle HQ may be responsible for the content that shows up in search / discovery
• Some infrastructure costs for Moodle HQ
• Slightly higher number of components

---

Glossary

ActivityPub - a standard decentralised social networking protocol based on ActivityStreams.

ActivityStreams - a standard format for syndicating social activities.

API - Application Programming Interface. A set of definitions, protocols, and tools for building application software, to enable communication between various components.

API-as-a-service - Software as a Service (SaaS) primarily exposed as an API.

Canonical - the main or reference location for something (eg. canonical URL)

Data handling module - a database abstraction library, using an ORM approach, which would have added support for caching and federation (when applicable).

Decentralisation - the process by which the activities of a network are distributed or delegated away from a central, authoritative location or group.

Federation - the ability for decentralised systems to send data to one another in a standardised way, to prevent fragmentation of the network. Email is a great example of a federated system.

GNU AGPL - a free, copyleft license published by the Free Software Foundation, and based on version 3 of the GNU General Public License (GPL) and the Affero General Public License. This license is compatible with the GPL and is recommended for any software that will commonly be run over a network.

GNU GPL - a widely used free software license guaranteeing end users the freedom to run, study, share and modify the libre software.

Instance - See also node. Can refer to an independently-hosted version of a software package.

IPFS - the InterPlanetary File System is a new hypermedia distribution protocol, addressed by content and identities. IPFS enables the creation of completely distributed applications. It aims to make the web faster, safer, and more open.

Libre software - software that is distributed under terms that allow users to run the software for any purpose as well as to study, change, and distribute it (and any adapted versions).

Metadata - data that provides information about other data. For educational resources, it could describe various aspects of the material, including grade level, subject area, and content type or format.

MoodleNet instance - an independently-hosted version of MoodleNet.

Moodle instance - an independently-hosted version of Moodle Core.

Node - a member of a decentralised network, which can sometimes serve as client, sometimes as server. See also instance.

Open Source - a decentralized software-development model that encourages open collaboration, with products such as source code, blueprints, and documentation freely available to the public.

ORM - Object-relational mapping, used to create a ‘virtual object database’ which can then be referenced programmatically (with less code and more flexibility as to the underlying data storage).

Protocol - a defined set of rules and formats that determine how data is transmitted.

SaaS - Software as a Service. Web-based software that’s centrally hosted and made available to use (free or by subscription).

Scaling horizontally - implies adding more nodes to a system to support its growth, for example installing copies of the same software on three web servers instead of just one.

Scaling vertically - implies adding resources (like CPUs or memory) to a single server in a system to support its growth.

Search index - a component of search engines which collects, parses, and stores data to facilitate fast and accurate search and information retrieval. Index design incorporates interdisciplinary concepts from linguistics, cognitive psychology, mathematics, informatics, and computer science.

Standard - a collection of agreed specifications, usually organised by a standards body such as the W3C.