Getting feedback on resource uploading in MoodleNet

Upload

Over the past week, we’ve taken the opportunity to talk with 10 community members about uploading resources into MoodleNet. These range from an expert in metadata standards to an educator who is less technical — with the majority being somewhere on the spectrum somewhere inbetween.

What we have been attempting to establish is the simplest and most straightforward way for users to add resources to MoodleNet, while capturing an appropriate level of metadata. We don’t want users to feel that adding appropriately-licensed resources to MoodleNet (and making them easily-discoverable) is a laborious process.

Context

As we explained in a previous post, we plan to restrict users uploading resources to three ‘Free Culture’ licenses:

If a user adds a resource via a link, then they don’t need to indicate within MoodleNet which license that resource is made available under. That’s because after the user clicks through, the external site should provide this information along with the resource. It also saves us from having to display a long and unwieldy list of licenses.

MoodleNet - add resource

Another thing by way of context is that, as we outlined in our post about MoodleNet metadata, resources will ‘inherit’ tags from their collection. At the moment, we’re thinking of implementing this in such a way that the interface automatically starts to complete tags for the resource — language(s), grade level(s), and subject area(s). That’s not actually shown on the screen below, but you can imagine ‘English’, ‘Postgraduate’ and ‘Education Science’ before ‘IDmodel’.

Tagging resources in collections

What we discovered

Here were the top 10 things that were on the mind of those we spoke with about resource uploading in MoodleNet:

  1. Drag-and-drop – extremely important for ease-of-use, rather than having to navigate a computer’s file system.
  2. Resource type – this is perhaps not strictly necessary as a field, but it was certainly felt that MIME types (e.g. PDF) aren’t particularly useful. Instead, we could simply differentiate, as Moodle LMS does, between an ‘activity’ and a ‘resource’. Alternatively, we could consider a free text approach (with autocomplete) using the generic name of ‘assets’.
  3. Metadata fields – some interviewees weren’t sure whether they were just used to certain fields or whether they were genuinely useful. One example of this was an indication of the time it would take to complete a learning activity.
  4. Accepted filetypes – should zip files of resources be allowed?
  5. Previews – a preview feature would be useful within MoodleNet to have a quick peek at potentially-relevant resources.
  6. Accessibility – perhaps we could add a field which referenced the IMS AccessForAll metadata standard? Or make it available as an option?
  7. Illegal resources – as Open Source software, MoodleNet could be used to facilitate the sharing and discussion of extremely problematic content. We should implement some safeguards around that, for example with a NSFW filter applied to search results by default, as well of course as the revocation of a MoodleNet ‘mothership’ API key.
  8. Maximum filesize – this should be configurable by administrators, with perhaps users having an overall amount of storage space.
  9. Tagging – private tagging of uploaded resources would allow users to tag resources in ways they may not want others to see.
  10. Version control – there are some post-launch options here around git, dat, and IPFS.

One interviewee commented that, with other systems: “I always feel like I’m using against what it was meant for”. This is why we’re putting so much thought into what some would consider small details. Another interviewee told us of a system they were forced to use for a resource-sharing project that was so unwieldy that colleagues stopped using it entirely.

Final remarks

During our conversations, interviewees touched on a number of things that were slightly tangential to resource uploading, but were nevertheless interesting:

  • Perhaps you should only be able to see resources that are Moodle activities if they are compatible with your Moodle LMS version?
  • Some people are much more likely to share resources in smaller groups — even if those resources are also publicly available.
  • Tags and license information from resources and collections could/should feed through to Moodle LMS via the MoodleNet plugin.

Many thanks to those who shared their insights with us, they have proved to be very helpful!

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

An update on likes and boosts in MoodleNet

Back in March of this year, we published a post entitled What we talk about when we talk about rating systems. While the fundamental approach that we outlined in that post remains unchanged, we’re tweaking the implementation of it for the beta launch in November.

We’re all familiar with the ability to ‘reshare’ and ‘like’ content on social networks. On Twitter it’s called ‘retweeting’ and ‘favouriting’, while on Mastodon (see screenshot below) it’s ‘boosting’ and ‘favouriting’

Boosts and likes

This approach is unproblematic for status updates, but of course with MoodleNet we’re also dealing with resources. As a result, to make things simple, the approach we outlined in our previous post was that there would be a single option (‘likes’) on resources.

Likes on resources

This would serve not only to allow a user to easily re-find something they’d liked via their profile, but it would be a vote for the resource within the collection. Simple, straightforward, and effective!

Likes on profiles

The problem with this, as pointed out by Mayel (our Technical Architect) is that this isn’t in line with Fediverse conventions. We want to be interoperable with other federated social networks, and with those, ‘likes’ don’t show up in feeds, — but ‘boosts’ do.

This led us down somewhat of a rabbithole, as there are several ways we could fix this. One thing to bear in mind is that both ‘likes’ on comments and likes on resources should show up in the relevant section of a user’s profile.


As MDLNET-372 outlines, we initially considered three options:

  1. Users have the option to ‘boost’ or ‘like’ comments, but only ‘like’ resources (which, behind the scenes is actually ‘like+boost’). Likes show up in the timeline on user profiles.
  2. Users can ‘applaud’ (like+boost) both comments and resources. Applause shows up in the timeline on user profiles.
  3. Users can ‘boost’ or ‘like’ comments, and ‘applaud’ (boost+like) resources. Both applause and likes show up in the timeline on user profiles.

Eventually, however, we rejected all of these options, because they would force users into an option where they have to both like and boost something, rather than perform these actions separately.

Finally, there’s terminology to inspect here as well. While Mastodon and Pleroma use stars and call them ‘favourites’, Twitter and Pixelfed use hearts and call them ‘likes’. Given that we want to use stars instead of hearts, we may as well stick with convention and call them ‘favourites’!


The solution to all of this doesn’t sound groundbreaking, but still involved a bit of thought: MoodleNet users will be able to ‘favourite’ and/or ‘boost’ both comments and resources. Favouriting something means it ends up on your profile, while a boost is both a way for users to give a thumbs-up to a resource and share it with their followers.

MoodleNet and ‘free speech’

Network

Background

Moodle’s stated aim is to “empower educators to improve our world”. We do this in alignment with our values:

  • Education – We understand that education is the foundation of making the world a better place. We are always learning, improving how we learn, and helping those around us to learn and to teach.
  • Integrity – We employ the highest ethical standards, demonstrating honesty and fairness in every action that we take.
  • Respect – We treat everyone with respect and sensitivity, recognising the importance of their contributions: team members, customers, partners, suppliers and competitors.
  • Innovation – We encourage a progressive culture of data-driven experimentation and research, where entrepreneurship and prudent risk-taking are encouraged, rewarded and incorporated.
  • Openness –  We strive to be open in our goals, our tools, our processes and our results, as much as is practical.  We encourage team members and our community to communicate freely both internally and externally. We promote accessibility and embrace international cultures across all our products.

Context

MoodleNet is a new open social media platform for educators, focussed on professional development and open content. It sustainably empowers communities of educators to share and learn from each other to improve the quality of education. It is an integral part of the Moodle ecosystem.

As a federated social network using the ActivityPub protocol, MoodleNet will be part of the Fediverse. This means that users can follow accounts on other services such as Mastodon, Pleroma, and Pixelfed. This works both ways, of course, so users on any server using, for example, Pleroma as a basis for their social network, can follow and interact with MoodleNet users.

This is a huge step forward for social networking, as instead of having silos such as Instagram and Twitter, you can follow any account on any other network. You can also maintain different accounts for different facets of your personality, so for example mastodon.art is a community artists, and scholar.social is for academics. But what if there was an instance for… fascists? And what if those users went out of their way to harrass and troll other users?

The wider problem

This is not a hypothetical issue. Since the start of the year, the Fediverse has had to deal with a social network called Gab which claims to be focused on ‘free speech’ but actually contains a disproportionate number of users who identify as Nazi sympathisers. It’s blatant enough for both Apple and Google to have banned Gab’s app from their app stores for contraventions of their policies on ‘hate speech’.

In response, Gab decided to fork Mastodon, an Open Source project. This manoeuvre meant that Gab users could simply install any generic app that was compatible with Mastodon without Apple or Google being able to ban it. An article in The Verge explains the headache that this caused the Fediverse. The important paragraphs are quoted below:

Over the past few years, Mastodon has become the model for a friendlier kind of social network, promising to keep out the hateful or ugly content that proliferates on larger and more centralized networks. Journalists hailed it as “Twitter without Nazis” and for years, it’s generally lived up to that promise. But last week, the social network Gab migrated to Mastodon — and Mastodon’s admins have been forced to deal with the internet’s Nazi problem head-on.

[…]

Some Gab content has crossed the line into criminal activity. The UK jailed two teenage neo-Nazis in June for posting terrorist propaganda. Florida police also arrested a user last month for posting racist threats and possessing a firearm as a convicted felon. And in 2018, a man posted an anti-Semitic Gab message just before killing 11 members of a synagogue in Pittsburgh. Gab denies that it condones hatred — CEO Andrew Torba says it simply allows any speech that’s “legal in the United States” with a few exceptions. It correctly notes that Facebook and Twitter also contain hate speech and violent threats. Gab is far smaller than these sites, however, and its bad posts are particularly concentrated.

When Gab migrated to Mastodon, that content threatened to spill into the larger platform. Mastodon is organized into a “Fediverse,” which means that users on one instance can follow and interact with users from another. It helps make Mastodon feel like a single community, but by default, it could make users from one instance vulnerable to trolls from another. Fortunately, administrators can block instances, too, keeping out any posts or users from that server.

So far, that’s been the default response to Gab. Mastodon’s official site will only list instances that follow the Mastodon Server Covenant. The covenant mandates “active moderation against racism, sexism, homophobia, and transphobia” — which pretty much nixes any contact with Gab. For Rochko, it seems like the clearest way forward. “The software that powers Mastodon is released under an open-source free software license, which means anybody can use it,” he says. “And you know, that offers a great number of benefits — but some disadvantages.”

As you can see, there’s no way to remain neutral here. Developing software is a political act. Most Fediverse administrators seem to have blocked Gab instances, and many app developers have blacklisted all Gab domainsSo how is this going to affect MoodleNet?

Our response

MoodleNet is Free and Open Source Software (FLOSS) that we are developing and releasing under the terms of the AGPL. Anyone can use it for any purpose. However, in addition to MoodleNet, and to improve the user experience, administrators running a MoodleNet instance may apply for an API key to connect to the Moodle HQ ‘mothership’. This means that users on their instance can search all other connected instances to discover new content, follow users and collections, and join communities.

Given what has been going on in the Fediverse, we are going to be very careful in terms of who we hand out API keys to. They can, of course, be revoked, but we want to establish minimum standards, especially as we’re planning on creating a MoodleNet equivalent of the join Mastodon page.

With all this in mind, the MoodleNet team has been working with our Privacy Officer to draft two documents and put them out for community consultation. As outlined in an earlier post, the first of these is a MoodleNet User Agreement, which includes six sections:

  1. Terms
  2. Code of Conduct
  3. Contribution, Use, Modification and Distribution Licenses
  4. Disclaimers
  5. Modifications
  6. Instance Rules

The second is a MoodleNet Covenant for Instance Administrators, which also has six points. Admins running a MoodleNet instance who want to connect to the ‘mothership’ (for search and discoverability) must agree to:

  1. Foster an open and welcoming environment.
  2. Actively moderate their instance
  3. Perform daily backups
  4. Give emergency access to the server infrastructure to at least two people
  5. Give users at least 3 months of advance warning in case of shutting down
  6. Make available the source code of any customisations to your instance, regardless how small

The full version of the first point on this list mandates that administrators contribute to “a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation”. The second that they actively moderate against “racism, sexism, homophobia, transphobia, harassment, defamation, doxxing, sexual depictions of children, and conduct promoting alt-right and fascist ideologies”.

The ‘free speech’ issue

Many people who use FLOSS tend to be those who value their independence and liberty. As a result, we’ve received messages expressing concern that we’re taking a “political stance” which might be inappropriate in an educational setting.

Our response has been to remind the people sending these message that our approach isn’t about restricting the discussion of this kind of stuff, but the promoting of it. We’ve cited the Paradox of Tolerance:

“Unlimited tolerance must lead to the disappearance of tolerance. If we extend unlimited tolerance even to those who are intolerant, if we are not prepared to defend a tolerant society against the onslaught of the intolerant, then the tolerant will be destroyed, and tolerance with them.” (Karl Popper)

To reiterate, we are not specifying how people use MoodleNet. We are setting the minimum standards we expect from administrators (and their users) on instances connected to the MoodleNet mothership. This does not contravene the free software definition, as anyone is free to install and run MoodleNet, as they wish, for any purpose. They are also welcome to contribute to the code base subject to our Community Code of Conduct.

We hope that clarifies a few things. If you’ve got questions/concerns about this, please add a comment below, or email: moodlenet-moderators@moodle.com

MoodleNet overview slide deck (September 2019)

Update: Check out a 10-minute screencast of this slide deck!

Here’s the latest version of the slide deck we use to explain MoodleNet. You are very welcome to use it to introduce MoodleNet to others, personally or professionally.

Access the slides directly here: http://bit.ly/2lvTci5

We’ve completely restructured this slide deck from the one shared in July. It’s now much more focused on MoodleNet functionality, so we’ve moved the more technical aspects to the end.

MoodleNet development timeline
MoodleNet development timeline

Comments? Questions? Add them below!

Late August 2019 update

MoodleNet UI 2.0 — a work in progress
MoodleNet UI 2.0 — a work in progress

Work on MoodleNet continues apace, with the above screenshot no longer being a clickable prototype, but live code on our staging server! Ivan, our talented UX designer and front-end developer, has created a ‘read-only’ version of the new user interface before he heads off on a well-deserved holiday for a couple of weeks.

During that period, James will be finishing off a very necessary refactoring of the core functionality on backend code, Karen is continuing making good progress on federation, and Mayel has submitted a plugin to the Moodle LMS team for their review and (possible) integration into Moodle 3.8.

We’re still on track for a November beta release with everything from the ‘must’ section of our MoSCoW prioritisation grid. However, we’ve had to push back the federation testing until October as we’re a small team working on a complex project, and many things have to come together at the same time!

Thank you to those who have commented (only privately, so far) on our draft MoodleNet User Agreement and Covenant for Instance Administrators. Please do consider giving your feedback — positive or negative!

*DRAFT* MoodleNet User Agreement and Covenant for Instance Administrators

Happy Birthday Moodle! 🎉🎉🎉

As promised in our post about the upcoming federation testing programme, we are now ready to share draft versions of two relevant documents.

While anyone is free to use MoodleNet for any purpose (Freedom 0 of the ‘Four Freedoms‘), in order to connect to the HQ ‘mothership’ for reasons of search and discovery, instance administrators must:

  • Either use the MoodleNet User Agreement as-is, or only add reasonable terms that do not negate any element of the existing agreement.
  • Agree to be bound by the terms of the MoodleNet Covenant for Instance Administrators.

The first is a MoodleNet User Agreement, which includes six sections:

  1. Terms
  2. Code of Conduct
  3. Contribution, Use, Modification and Distribution Licenses
  4. Disclaimers
  5. Modifications
  6. Instance Rules

The second is a MoodleNet Covenant for Instance Administrators, which also has six points. Those admins running a MoodleNet instance who want to connect to the ‘mothership’ (for search and discoverability) must agree to:

  1. Foster an open and welcoming environment.
  2. Actively moderate their instance
  3. Perform daily backups
  4. Give emergency access to the server infrastructure to at least two people
  5. Give users at least 3 months of advance warning in case of shutting down
  6. Make available the source code of any customisations to your instance, regardless how small

To be as clear and direct as possible, the MoodleNet team is committed to fostering an open and welcoming environment, meaning that racism, sexism, homophobia, transphobia, harassment, defamation, doxxing, sexual depictions of children, and conduct promoting alt-right and fascist ideologies will not be tolerated.

We welcome the community’s feedback on these drafts, either as comments directly on the documents, in comments below this post, or on the MoodleNet forum. If you have particular concerns or comments that you like to make more privately, please email: moodlenet-moderators@moodle.com

Planning for the MoodleNet public beta

In the spirit of working openly, we’d like to share a MoSCoW prioritisation grid for the public beta release of MoodleNet in November 2019. While any project is subject to changing priorities as it progresses, this is where we are in early August.

For those that prefer a more accessible text-based version, please see below.


MUST

Instances:

  • Federation with other instances
  • Connect to HQ ‘mothership’
  • Search across federated instances
  • Discover page
  • My MoodleNet
  • Profiles
  • Flags/reporting
  • Moderation tools
  • Sign-up page (username/password)
  • Open to browse without signing in

Communities:

  • Image upload
  • Join/create/edit/leave a community
  • Every @community is hyperlinked

Collections:

  • Category tags
  • Create/edit a collection
  • Every +mention is hyperlinked

Resources:

  • Like resources
  • Add resource via URL
  • Add hashtags to added resources

Profiles:

  • Bio & links
  • Avatar
  • Header image
  • User timeline
  • Joined communities
  • Followed collections
  • Liked resources

Users:

  • Every @username is hyperlinked
  • Unique usernames

Moodle Core integration:

  • Plugin to pull resources from MoodleNet

Misc.

  • Basic security audit

SHOULD

Instances:

  • Help pages
  • Interoperability with other ActivityPub apps
  • Blocklists

Communities:

  • Share link to community 

Collections:

  • Hashtags 
  • Pinned resources
  • Share link to collection

Resources:

  • Upload resources
  • Add licence to uploaded resources

Profiles:

  • Follow other users

Users:

  • Notifications if mentioned within a community
  • Receive weekly emails about recent activity

COULD

Instances:

  • Analytics
  • Sign-up page (social accounts)

Communities:

  • Related communities

Collections:

  • Related collections
  • Sort/filter listed resources

Resources:

  • Auto-complete hashtags

Profiles:

  • Add other users to a contact list
  • Invite other people to create a MoodleNet profile
  • Add interests (based on hashtags)

Users:

  • Sort/filter ‘My MoodleNet’

Misc.

  • In-depth security audit

WON’T

  • Private communities / collections
  • Request a resource
  • Copy/fork a collection into another community
  • Events functionality
  • Emoji ID
  • Open Badges on profiles
  • Query 3rd-party repositories

MoodleNet overview slide deck (July 2019)

Update: we recorded a 13-min screencast version of the slide deck below!


We regularly update the slide deck used to give an overview of MoodleNet. It not only helps us continue to (hopefully!) get better at explaining what MoodleNet is, but is a useful resource for community members who may want to introduce it to others.

Access the slides directly here: http://bit.ly/2OkahJN

What we’ve changed this time around:

  • Removed ‘non-technical’ from the title
  • Replaced references to ‘decentralisation’ with ‘federation’
  • Updated the slide referencing Mastodon with a similar MoodleNet-focused one (see below!)
  • Added slides showing the UI 2.0 clickable prototype
  • Replaced the slide referencing Aha! with one showing Moodle Tracker
It doesn't matter which MoodleNet instance you are a member of - you can join communities, and follow other people and collections fro any other instance!
New MoodleNet federation overview slide

Comments? Questions? Add them below!