Note: also available on the MoodleNet blog
Building on the success of the design sprint last month, the MoodleNet team has started laying down some milestones for the project. One of the first is to define the system architecture, upon which Mayel de Borniol (Technical Architect) has begun work, with input from Doug Belshaw.
We’ve defined three approaches to building MoodleNet, from a fully-federated architecture through to a centralised SaaS architecture:
(Note: right-click on images and select ‘open link in new tab’ to see detail)
Our current preference is for an approach which takes some of the benefits of both, which is a Core API-as-a-service architecture. The extract below from a overview document we’re putting together, with terms in bold defined in the glossary at the end of that document:
In this scenario, Moodle HQ runs a single core MoodleNet 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 core MoodleNet 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 core 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 core API service, the Moodle resources repository, 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 decentralisedcollection 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 ActivityPubprotocol to ensure compatibility between systems.
We invite comments from the community, after which we will update the overview document and move it to the project wiki. You are welcome to give your feedback here or in the comments section of the blog post.