MoodleNet/tech/stack - Revision history

Paul.hodgson2: Replaced content with "<< [https://docs.moodle.org/dev/MoodleNet/tech Back to MoodleNet Tech index]"

2022-05-09T09:26:47Z

Replaced content with "<< [https://docs.moodle.org/dev/MoodleNet/tech Back to MoodleNet Tech index]"

Mayel at 10:51, 27 August 2018

2018-08-27T10:51:39Z

← Older revision		Revision as of 10:51, 27 August 2018
Line 1:		Line 1:
			<< [https://docs.moodle.org/dev/MoodleNet/tech Back to MoodleNet Tech index]

	= Rationale for choosing Elixir for the MoodleNet back-end =		= Rationale for choosing Elixir for the MoodleNet back-end =

Mayel: /* Research process */

2018-08-06T16:01:59Z

Research process

← Older revision		Revision as of 16:01, 6 August 2018
Line 18:		Line 18:
	The process began with an extensive review of web application programming languages. More specifically, the technologies used for apps based on [https://en.wikipedia.org/wiki/ActivityPub ActivityPub federation standard] - which will enable MoodleNet to be a '''decentralised platform, you will be able self-host an instance''' (just like you can install Moodle on a server, and customise it) but all the instances will be '''interconnected'''.		The process began with an extensive review of web application programming languages. More specifically, the technologies used for apps based on [https://en.wikipedia.org/wiki/ActivityPub ActivityPub federation standard] - which will enable MoodleNet to be a '''decentralised platform, you will be able self-host an instance''' (just like you can install Moodle on a server, and customise it) but all the instances will be '''interconnected'''.

	A [https://ethercalc.org/fediverse-stacks spreadsheet of fediverse apps and their stacks] (and [https://social.coop/@mayel/100469319126679591 crowdsourced extra information via the fediverse]) was compiled. This showed that besides Ruby on Rails, there were a few ActivityPub projects using Python (and a couple intending to use PHP) and some other languages, however, most projects are still in early development and many are not yet federated. Considering that '''ActivityPub is still relatively new it is understandable that there are limited examples of full implementations''', let alone ones that are proven to work and be interoperable.		A '''[https://ethercalc.org/fediverse-stacks spreadsheet of fediverse apps and their stacks]''' (and [https://social.coop/@mayel/100469319126679591 crowdsourced extra information via the fediverse]) was compiled. This showed that besides Ruby on Rails, there were a few ActivityPub projects using Python (and a couple intending to use PHP) and some other languages, however, most projects are still in early development and many are not yet federated. Considering that '''ActivityPub is still relatively new it is understandable that there are limited examples of full implementations''', let alone ones that are proven to work and be interoperable.

	One of the first languages that stood out was Go, one of the only a few to actually have an [https://github.com/go-fed/activity ActivityPub library]. The developer was contacted and offered his assistance for future collaboration (although in full-time employment and developing the Go library in his spare time). What this meant was that the MoodleNet team would have to modify the library in order to tailor it to the project’s needs. The main obstacle to this, however, is that Go is a ‘statically typed’ language which means every ActivityStreams extension would have to be hard coded pre-compilation. This would make things less flexible, so this option was set aside.		One of the first languages that stood out was Go, one of the only a few to actually have an [https://github.com/go-fed/activity ActivityPub library]. The developer was contacted and offered his assistance for future collaboration (although in full-time employment and developing the Go library in his spare time). What this meant was that the MoodleNet team would have to modify the library in order to tailor it to the project’s needs. The main obstacle to this, however, is that Go is a ‘statically typed’ language which means every ActivityStreams extension would have to be hard coded pre-compilation. This would make things less flexible, so this option was set aside.

Mayel at 15:38, 6 August 2018

2018-08-06T15:38:58Z

Dajbelshaw: /* References */

2018-08-06T15:03:21Z

References

← Older revision		Revision as of 15:03, 6 August 2018
Line 195:		Line 195:
	Regarding the connection between the back-end and front-end app, the ActivityPub standard comes with a suggested [https://www.w3.org/TR/activitypub/#client-to-server-interactions client-server REST API specification], but for some reason Mastodon and many other fediverse apps have created their own custom REST APIs (and Pleroma implemented Mastodon’s so that it can share front-end apps). So an interesting option at this point for MoodleNet (and ''Pub of the Commons''), may be to still support Mastodon’s client REST API (for compatibillity with existing front-ends like [https://github.com/nolanlawson/pinafore Pinafore]) and additionally to '''implement a new GraphQL-based API that would allow more flexibility and extensiblity between the server and front-end apps''' (any functionality/activities/objects not supported by Mastodon would only have to be implemented in the server-to-server REST API and the [https://graphql.org GraphQL] API).		Regarding the connection between the back-end and front-end app, the ActivityPub standard comes with a suggested [https://www.w3.org/TR/activitypub/#client-to-server-interactions client-server REST API specification], but for some reason Mastodon and many other fediverse apps have created their own custom REST APIs (and Pleroma implemented Mastodon’s so that it can share front-end apps). So an interesting option at this point for MoodleNet (and ''Pub of the Commons''), may be to still support Mastodon’s client REST API (for compatibillity with existing front-ends like [https://github.com/nolanlawson/pinafore Pinafore]) and additionally to '''implement a new GraphQL-based API that would allow more flexibility and extensiblity between the server and front-end apps''' (any functionality/activities/objects not supported by Mastodon would only have to be implemented in the server-to-server REST API and the [https://graphql.org GraphQL] API).

	== References ==		= References =

	* [https://ethercalc.org/fediverse-stacks Spreadsheet of fediverse apps and their stacks]		* [https://ethercalc.org/fediverse-stacks Spreadsheet of fediverse apps and their stacks]

Dajbelshaw: /* The plan for Moodlenet (so far) */

2018-08-06T15:03:03Z

The plan for Moodlenet (so far)

← Older revision		Revision as of 15:03, 6 August 2018
Line 195:		Line 195:
	Regarding the connection between the back-end and front-end app, the ActivityPub standard comes with a suggested [https://www.w3.org/TR/activitypub/#client-to-server-interactions client-server REST API specification], but for some reason Mastodon and many other fediverse apps have created their own custom REST APIs (and Pleroma implemented Mastodon’s so that it can share front-end apps). So an interesting option at this point for MoodleNet (and ''Pub of the Commons''), may be to still support Mastodon’s client REST API (for compatibillity with existing front-ends like [https://github.com/nolanlawson/pinafore Pinafore]) and additionally to '''implement a new GraphQL-based API that would allow more flexibility and extensiblity between the server and front-end apps''' (any functionality/activities/objects not supported by Mastodon would only have to be implemented in the server-to-server REST API and the [https://graphql.org GraphQL] API).		Regarding the connection between the back-end and front-end app, the ActivityPub standard comes with a suggested [https://www.w3.org/TR/activitypub/#client-to-server-interactions client-server REST API specification], but for some reason Mastodon and many other fediverse apps have created their own custom REST APIs (and Pleroma implemented Mastodon’s so that it can share front-end apps). So an interesting option at this point for MoodleNet (and ''Pub of the Commons''), may be to still support Mastodon’s client REST API (for compatibillity with existing front-ends like [https://github.com/nolanlawson/pinafore Pinafore]) and additionally to '''implement a new GraphQL-based API that would allow more flexibility and extensiblity between the server and front-end apps''' (any functionality/activities/objects not supported by Mastodon would only have to be implemented in the server-to-server REST API and the [https://graphql.org GraphQL] API).

	~~'''~~References~~'''~~		== References ==

	* [https://ethercalc.org/fediverse-stacks Spreadsheet of fediverse apps and their stacks]		* [https://ethercalc.org/fediverse-stacks Spreadsheet of fediverse apps and their stacks]

Dajbelshaw: /* A generic agent-centric approach to federation? */

2018-08-06T15:00:20Z

A generic agent-centric approach to federation?

← Older revision		Revision as of 15:00, 6 August 2018
Line 167:		Line 167:
	== A generic agent-centric approach to federation? ==		== A generic agent-centric approach to federation? ==

	Another fediverse app being developed in Elixir ([https://github.com/beta-phenylethylamine/fontina Fontina], for photo sharing - although it has been put on hiatus) is now working on a [https://github.com/fontina-project/pubstomp generic ActivityPub server] to serve as back-end (there may be a good opportunity to join efforts…) Here is how the developer describes it: ~~>~~ “I’m working on pubstomp, a generic AP server that is intended for services like mastodon/pixelfed/peertube to work as frontends to it and would indeed support single account [per person, versus having an account on an instance of each of those apps]. > That said, one of my goals down the road is to build”api adaptors" that would basically plug into pubstomp and adapt to, say, the mastoAPI, pleromaAPI, etc.”		Another fediverse app being developed in Elixir ([https://github.com/beta-phenylethylamine/fontina Fontina], for photo sharing - although it has been put on hiatus) is now working on a [https://github.com/fontina-project/pubstomp generic ActivityPub server] to serve as back-end (there may be a good opportunity to join efforts…) Here is how the developer describes it:

			<blockquote>“I’m working on pubstomp, a generic AP server that is intended for services like mastodon/pixelfed/peertube to work as frontends to it and would indeed support single account [per person, versus having an account on an instance of each of those apps]. > That said, one of my goals down the road is to build”api adaptors" that would basically plug into pubstomp and adapt to, say, the mastoAPI, pleromaAPI, etc.”</blockquote>

	This is a good example of an '''agent-centric approach''', where instead of having one '''monolithic app per use-case''' it is possible instead to seperate out federation logic and custom app logic (both back-ends could still share a database on the same server, and share a JavaScript-based front-end app that talks to both APIs).		This is a good example of an '''agent-centric approach''', where instead of having one '''monolithic app per use-case''' it is possible instead to seperate out federation logic and custom app logic (both back-ends could still share a database on the same server, and share a JavaScript-based front-end app that talks to both APIs).

	I started a [https://social.coop/@mayel/100469525067581562 thread about this on the fediverse] (please join the conversation!): ~~>~~ There’s need for a generic agent-centric #ActivityPub server, so that instead of signing up to a bunch of different servers, a user could have their indentity and data all in one place, and all the apps they use (clients, but if necessary server-side “plugins” as well) would interact with the activity/objects types that they support.		I started a [https://social.coop/@mayel/100469525067581562 thread about this on the fediverse] (please join the conversation!):

			<blockquote>There’s need for a generic agent-centric #ActivityPub server, so that instead of signing up to a bunch of different servers, a user could have their indentity and data all in one place, and all the apps they use (clients, but if necessary server-side “plugins” as well) would interact with the activity/objects types that they support.</blockquote>

	== The plan for Moodlenet (so far) ==		== The plan for Moodlenet (so far) ==

Dajbelshaw: /* Performance */

2018-08-06T14:59:13Z

Performance

← Older revision		Revision as of 14:59, 6 August 2018
Line 44:		Line 44:
	<blockquote>“We like Elixir and have seen some pretty big wins with it. The system that manages rate limits for both the Pinterest API and Ads API is built in Elixir. Its 50 percent response time is around 500 microseconds with a 90 percent response time of 800 microseconds. Yes, microseconds.”		<blockquote>“We like Elixir and have seen some pretty big wins with it. The system that manages rate limits for both the Pinterest API and Ads API is built in Elixir. Its 50 percent response time is around 500 microseconds with a 90 percent response time of 800 microseconds. Yes, microseconds.”
	</blockquote>		</blockquote>
	And an [https://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the-future-of-web-apis-and-apps/ adopter of the Phoenix framework] says: ~~>~~ “A rather large JSON request was taking about 1.5-2.0s against our Rails backend (no caching). That same request (same h/w, database queries and data) takes about 400ms with Phoenix. Our entire application went from using just shy of 1 GB across 2 dynos to a single dyno using less than 100 MB. That single dyno is notably faster and can handle higher concurrency (about 10x). Importantly, Phoenix (without caching) performs better than Rails (with caching).”
			And an [https://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the-future-of-web-apis-and-apps/ adopter of the Phoenix framework] says:

			<blockquote>“A rather large JSON request was taking about 1.5-2.0s against our Rails backend (no caching). That same request (same h/w, database queries and data) takes about 400ms with Phoenix. Our entire application went from using just shy of 1 GB across 2 dynos to a single dyno using less than 100 MB. That single dyno is notably faster and can handle higher concurrency (about 10x). Importantly, Phoenix (without caching) performs better than Rails (with caching).”</blockquote>

	One thing that makes Erlang/Elixir so efficient is [https://www.brianstorti.com/the-actor-model/ the actor model], which ActivityPub seems to have taken inspiration from.		One thing that makes Erlang/Elixir so efficient is [https://www.brianstorti.com/the-actor-model/ the actor model], which ActivityPub seems to have taken inspiration from.

Dajbelshaw: /* Developer Productivity & Happiness */

2018-08-06T14:58:40Z

Developer Productivity & Happiness

← Older revision		Revision as of 14:58, 6 August 2018
Line 62:		Line 62:
	More important then is which framework helps write software faster, of a better quality, and which benefits the programmer’s wellbeing.		More important then is which framework helps write software faster, of a better quality, and which benefits the programmer’s wellbeing.

	As Pinterest concluded from using Elixir: ~~>~~ “We’ve also seen an improvement in code clarity. We’re converting our notifications system from Java to Elixir. The Java version used an Actor system and weighed in at around 10,000 lines of code. The new Elixir system has shrunk this to around 1000 lines. The Elixir based system is also faster and more consistent than the Java one and runs on half the number of servers.”		As Pinterest concluded from using Elixir:

			<blockquote>“We’ve also seen an improvement in code clarity. We’re converting our notifications system from Java to Elixir. The Java version used an Actor system and weighed in at around 10,000 lines of code. The new Elixir system has shrunk this to around 1000 lines. The Elixir based system is also faster and more consistent than the Java one and runs on half the number of servers.”</blockquote>

	And [http://www.techworld.com/apps-wearables/how-elixir-helped-bleacher-report-handle-8x-more-traffic-3653957/ Bleacher Report], who went from 150 servers to 5 using Elixir: > "The new language has led to cleaner code base and much less technical debt. It has also increased the speed of development.		And [http://www.techworld.com/apps-wearables/how-elixir-helped-bleacher-report-handle-8x-more-traffic-3653957/ Bleacher Report], who went from 150 servers to 5 using Elixir: > "The new language has led to cleaner code base and much less technical debt. It has also increased the speed of development.

Dajbelshaw: /* Simplicity */

2018-08-06T14:58:00Z

Simplicity

← Older revision		Revision as of 14:58, 6 August 2018
Line 94:		Line 94:
	== Simplicity ==		== Simplicity ==

	For modern web applications (written in languages like PHP or Ruby on Rails) to do everything we require of them, they depend on a lot of other pieces running on the server, for example: * Only one web request can be handled at a time, and it is not possible to spin up new processes as needed, so tools are needed to spawn multiple application servers up front and put a web server like Nginx in front of them to hand off requests. * It is not possible to do slow background tasks without blocking web requests, so something like [http://resque.github.io Resque] needs to be added to take care of running background jobs. * It is not advisable to use a precious process to maintain a websocket connection with a user, so something like Pusher needs to be added to get realtime functionality (meaning extra costs). * It is not possible to keep a big process running all the time to do scheduled tasks, so a dependency on cron needs to be added. * No built-in tool for managing multiple parts of a running system currently exists, so tools like [https://www.theforeman.org foreman] are used to start and monitor them.		For modern web applications (written in languages like PHP or Ruby on Rails) to do everything we require of them, they depend on a lot of other pieces running on the server, for example:

			* Only one web request can be handled at a time, and it is not possible to spin up new processes as needed, so tools are needed to spawn multiple application servers up front and put a web server like Nginx in front of them to hand off requests.
			* It is not possible to do slow background tasks without blocking web requests, so something like [http://resque.github.io Resque] needs to be added to take care of running background jobs.
			* It is not advisable to use a precious process to maintain a websocket connection with a user, so something like Pusher needs to be added to get realtime functionality (meaning extra costs).
			* It is not possible to keep a big process running all the time to do scheduled tasks, so a dependency on cron needs to be added.
			* No built-in tool for managing multiple parts of a running system currently exists, so tools like [https://www.theforeman.org foreman] are used to start and monitor them.

	In Elixir on the other hand, it is possible to spin up a nearly limitless number of processes as needed, so it is possible (in theory) to forego all those tools above.		In Elixir on the other hand, it is possible to spin up a nearly limitless number of processes as needed, so it is possible (in theory) to forego all those tools above.
Line 102:		Line 108:
	<blockquote>“Functional programming is associated with concurrency but it was not by design. It just happens that, by making the complex parts of our system explicit, solving more complicated issues like concurrency becomes much simpler.” - [http://www.sitepoint.com/an-interview-with-elixir-creator-jose-valim/ Jose Valim]		<blockquote>“Functional programming is associated with concurrency but it was not by design. It just happens that, by making the complex parts of our system explicit, solving more complicated issues like concurrency becomes much simpler.” - [http://www.sitepoint.com/an-interview-with-elixir-creator-jose-valim/ Jose Valim]
	</blockquote>		</blockquote>

	== Flexibility ==		== Flexibility ==

← Older revision		Revision as of 15:38, 6 August 2018
Line 10:		Line 10:
	== Introduction ==		== Introduction ==

	MoodleNet is a new open social media platform for educators, ~~focussed~~ on professional development and open content. It will be an integral part of the Moodle ecosystem.		MoodleNet is a new open social media platform for educators, focused on professional development and open content. It will be an integral part of the Moodle ecosystem.

	Just like the ~7,000 languages that are spoken in the world today, there many different types of programming languages that allow humans to communicate with computers (and tell them nicely what to do). An important decision for our team was what technical language(s) Moodlenet should speak, and this document highlights the decision-making process which ended up with choosing the ‘Elixir’ language.		Just like the ~7,000 languages that are spoken in the world today, there are many different types of programming languages that allow humans to communicate with computers (and tell them nicely what to do). An important decision for our team was what technical language(s) Moodlenet should speak, and this document highlights the decision-making process which ended up with choosing the ‘Elixir’ language.

	== Research process ==		== Research process ==

	The process began with an extensive review of web application ~~appprogramming~~ languages. More specifically, the technologies used for apps based on [https://en.wikipedia.org/wiki/ActivityPub ActivityPub federation standard] - which will enable MoodleNet to be a '''decentralised platform, you will be able self-host an instance''' (just like you can install Moodle on a server, and customise it) but all the instances will be '''interconnected'''.		The process began with an extensive review of web application programming languages. More specifically, the technologies used for apps based on [https://en.wikipedia.org/wiki/ActivityPub ActivityPub federation standard] - which will enable MoodleNet to be a '''decentralised platform, you will be able self-host an instance''' (just like you can install Moodle on a server, and customise it) but all the instances will be '''interconnected'''.

	A [https://ethercalc.org/fediverse-stacks spreadsheet of fediverse apps and their stacks] (and [https://social.coop/@mayel/100469319126679591 crowdsourced extra information via the fediverse]) was compiled. This showed that besides Ruby on Rails, there were a few ActivityPub projects using Python (and a couple intending to use PHP) and some other languages, however, most projects are still in early development and many are not yet federated. Considering that '''ActivityPub is still relatively new it is understandable that there are limited examples of full implementations''', let alone ones that are proven to work and be interoperable.		A [https://ethercalc.org/fediverse-stacks spreadsheet of fediverse apps and their stacks] (and [https://social.coop/@mayel/100469319126679591 crowdsourced extra information via the fediverse]) was compiled. This showed that besides Ruby on Rails, there were a few ActivityPub projects using Python (and a couple intending to use PHP) and some other languages, however, most projects are still in early development and many are not yet federated. Considering that '''ActivityPub is still relatively new it is understandable that there are limited examples of full implementations''', let alone ones that are proven to work and be interoperable.
Line 24:		Line 24:
	Alongside researching the documentations, codebases, issue trackers and communicating with developers of the apps in the spreadsheet, many of them were installed and tested (including Mastodon, Pleroma, and Prismo). The latter, while having some functionality that MoodleNet will need, confirmed an earlier impression from running a Mastodon instance: '''Rails apps tend to not be lightweight and often rely on many external dependencies'''.		Alongside researching the documentations, codebases, issue trackers and communicating with developers of the apps in the spreadsheet, many of them were installed and tested (including Mastodon, Pleroma, and Prismo). The latter, while having some functionality that MoodleNet will need, confirmed an earlier impression from running a Mastodon instance: '''Rails apps tend to not be lightweight and often rely on many external dependencies'''.

	After comparing the possible language candidates, the focus shifted on detailing the pros and cons for each, ~~finaly~~ focusing on the following:		After comparing the possible language candidates, the focus shifted on detailing the pros and cons for each, finally focusing on the following:

	* The '''[https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine) Erlang VM]''' is time tested (more than 20 years old), very fast and has good concurrency and inter-process communication (called OTP).		* The '''[https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine) Erlang VM]''' is time tested (more than 20 years old), very fast and has good concurrency and inter-process communication (called OTP).
Line 38:		Line 38:
	The Phoenix web framework has been found to perform better than Rails, PHP, and Python. [https://github.com/mroth/phoenix-showdown/blob/master/README.md#benchmarking One benchmark] showed Phoenix handling over 10x more requests than Rails in a given period. Phoenix was also much more consistent under load - Rails was more prone to have some requests bog down. This can cause a “chain reaction”, because Rails apps are configured with a fixed number of application processes, so if some of them are slow, it can mean that others have to wait in line, which dramatically increases the app’s response time.		The Phoenix web framework has been found to perform better than Rails, PHP, and Python. [https://github.com/mroth/phoenix-showdown/blob/master/README.md#benchmarking One benchmark] showed Phoenix handling over 10x more requests than Rails in a given period. Phoenix was also much more consistent under load - Rails was more prone to have some requests bog down. This can cause a “chain reaction”, because Rails apps are configured with a fixed number of application processes, so if some of them are slow, it can mean that others have to wait in line, which dramatically increases the app’s response time.

	Furthermore, Phoenix apps '''without caching''' drastically outperform Rails apps '''with caching'''. This is important because caching is notorious for being a source of complexity and bugs, and because caching can’t be used for moment-by-moment, ~~personalized~~ content. The [https://youtu.be/AdY5AfXs7aw?t=3m14s Bleacher Report] for example went from over 100 AWS servers to 5, with CPU usage rarely going above 10%, and saw a 10x performance improvement over their Rails app.		Furthermore, Phoenix apps '''without caching''' drastically outperform Rails apps '''with caching'''. This is important because caching is notorious for being a source of complexity and bugs, and because caching can’t be used for moment-by-moment, personalised content. The [https://youtu.be/AdY5AfXs7aw?t=3m14s Bleacher Report] for example went from over 100 AWS servers to 5, with CPU usage rarely going above 10%, and saw a 10x performance improvement over their Rails app.

	There are a growing number of software projects using Elixir - e.g. Pinterest [https://github.com/bignerdranch/why_elixir who say]:		There are a growing number of software projects using Elixir - e.g. Pinterest [https://github.com/bignerdranch/why_elixir who say]:
Line 59:		Line 59:
	<blockquote>“At the time of writing there are application servers written in Erlang that can handle more than two million connections on a single server in a real production application, with spare memory and CPU! The Web is concurrent, and Erlang is a language designed for concurrency, so it is a perfect match. <br><br> Of course, various platforms need to scale beyond a few million connections. This is where Erlang’s built-in distribution mechanisms come in. If one server isn’t enough, add more! Erlang allows you to use the same code for talking to local processes or to processes in other parts of your cluster, which means you can scale very quickly if the need arises.”		<blockquote>“At the time of writing there are application servers written in Erlang that can handle more than two million connections on a single server in a real production application, with spare memory and CPU! The Web is concurrent, and Erlang is a language designed for concurrency, so it is a perfect match. <br><br> Of course, various platforms need to scale beyond a few million connections. This is where Erlang’s built-in distribution mechanisms come in. If one server isn’t enough, add more! Erlang allows you to use the same code for talking to local processes or to processes in other parts of your cluster, which means you can scale very quickly if the need arises.”
	</blockquote>		</blockquote>

	== Developer Productivity & Happiness ==		== Developer Productivity & Happiness ==

Line 171:		Line 172:
	<blockquote>“I’m working on pubstomp, a generic AP server that is intended for services like mastodon/pixelfed/peertube to work as frontends to it and would indeed support single account [per person, versus having an account on an instance of each of those apps]. > That said, one of my goals down the road is to build”api adaptors" that would basically plug into pubstomp and adapt to, say, the mastoAPI, pleromaAPI, etc.”</blockquote>		<blockquote>“I’m working on pubstomp, a generic AP server that is intended for services like mastodon/pixelfed/peertube to work as frontends to it and would indeed support single account [per person, versus having an account on an instance of each of those apps]. > That said, one of my goals down the road is to build”api adaptors" that would basically plug into pubstomp and adapt to, say, the mastoAPI, pleromaAPI, etc.”</blockquote>

	This is a good example of an '''agent-centric approach''', where instead of having one '''monolithic app per use-case''' it is possible instead to ~~seperate~~ out federation logic and custom app logic (both back-ends could still share a database on the same server, and share a JavaScript-based front-end app that talks to both APIs).		This is a good example of an '''agent-centric approach''', where instead of having one '''monolithic app per use-case''' it is possible instead to separate out federation logic and custom app logic (both back-ends could still share a database on the same server, and share a JavaScript-based front-end app that talks to both APIs).

	I started a [https://social.coop/@mayel/100469525067581562 thread about this on the fediverse] (please join the conversation!):		I started a [https://social.coop/@mayel/100469525067581562 thread about this on the fediverse] (please join the conversation!):

	<blockquote>There’s need for a generic agent-centric #ActivityPub server, so that instead of signing up to a bunch of different servers, a user could have their ~~indentity~~ and data all in one place, and all the apps they use (clients, but if necessary server-side “plugins” as well) would interact with the activity/objects types that they support.</blockquote>		<blockquote>There’s need for a generic agent-centric #ActivityPub server, so that instead of signing up to a bunch of different servers, a user could have their identity and data all in one place, and all the apps they use (clients, but if necessary server-side “plugins” as well) would interact with the activity/objects types that they support.</blockquote>

	== The plan for Moodlenet (so far) ==		== The plan for Moodlenet (so far) ==
Line 181:		Line 182:
	# Fork the Pleroma back-end to create a set of ActivityPub libraries (or a generic ActivityPub server)		# Fork the Pleroma back-end to create a set of ActivityPub libraries (or a generic ActivityPub server)
	# Add suport for authenticating as OAuth client		# Add suport for authenticating as OAuth client
	# Add support for group accounts (agents that represent a ~~severa~~ users)		# Add support for group accounts (agents that represent a several users)
	# Create ActivityStreams extensions		# Create ActivityStreams extensions
	# Test federation		# Test federation
Line 187:		Line 188:
	# Create front-end app with React.js (web and mobile)		# Create front-end app with React.js (web and mobile)

	We are planning to fork the [https://git.pleroma.social/pleroma/pleroma Pleroma back-end] to '''create a set of ActivityPub/ActivityStreams libraries'''. If that proves to not be feasible, we will turn it into a generic ActivityPub server back-end that can support any type of activity and object (including extensions to ActivityStreams) and is easily extensible which doesn’t ship with any frontend (possible name: ''Pub of the Commons''). Pleroma is written with [https://elixir-lang.org Elixir]’s [https://phoenixframework.org Phoenix Framework], and ~~licenced~~ as AGPL (which is also being used for MoodleNet) so the upstream project will be able to use any improvements we make.		We are planning to fork the [https://git.pleroma.social/pleroma/pleroma Pleroma back-end] to '''create a set of ActivityPub/ActivityStreams libraries'''. If that proves to not be feasible, we will turn it into a generic ActivityPub server back-end that can support any type of activity and object (including extensions to ActivityStreams) and is easily extensible which doesn’t ship with any frontend (possible name: ''Pub of the Commons''). Pleroma is written with [https://elixir-lang.org Elixir]’s [https://phoenixframework.org Phoenix Framework], and licensed as AGPL (which is also being used for MoodleNet) so the upstream project will be able to use any improvements we make.

	Firstly, any parts of the code coming from Pleroma that we don’t needed will be removed (like support for the deprecated OStatus protocol, and the two front-ends which ship with Pleroma - its own Vue.js interface and Mastodon’s React.js interface), and we’ll add some things that can be '''universally useful''' like '''support for groups''' (actors made of several users), a basic HTML registration/authentication interface (and '''OAuth client''' functionality, so users can sign in using their existing accounts elsewhere) so that at least those things can be done without relying on a front-end app.		Firstly, any parts of the code coming from Pleroma that we don’t needed will be removed (like support for the deprecated OStatus protocol, and the two front-ends which ship with Pleroma - its own Vue.js interface and Mastodon’s React.js interface), and we’ll add some things that can be '''universally useful''' like '''support for groups''' (actors made of several users), a basic HTML registration/authentication interface (and '''OAuth client''' functionality, so users can sign in using their existing accounts elsewhere) so that at least those things can be done without relying on a front-end app.
Line 193:		Line 194:
	While we work on creating models/vocabulary for MoodleNet, we can use this generic ActivityPub server to test our ActivityStreams extensions and make sure federation works well in real time (using the API only). Only once that is ready, will we start plugging in custom MoodleNet logic and developing the front-end app (which is the reverse from many fediverse app projects, who have first implemented MVPs of their use case, and then often find it challenging to add federation on top).		While we work on creating models/vocabulary for MoodleNet, we can use this generic ActivityPub server to test our ActivityStreams extensions and make sure federation works well in real time (using the API only). Only once that is ready, will we start plugging in custom MoodleNet logic and developing the front-end app (which is the reverse from many fediverse app projects, who have first implemented MVPs of their use case, and then often find it challenging to add federation on top).

	Regarding the connection between the back-end and front-end app, the ActivityPub standard comes with a suggested [https://www.w3.org/TR/activitypub/#client-to-server-interactions client-server REST API specification], but for some reason Mastodon and many other fediverse apps have created their own custom REST APIs (and Pleroma implemented Mastodon’s so that it can share front-end apps). So an interesting option at this point for MoodleNet (and ''Pub of the Commons''), may be to still support Mastodon’s client REST API (for ~~compatibillity~~ with existing front-ends like [https://github.com/nolanlawson/pinafore Pinafore]) and additionally to '''implement a new GraphQL-based API that would allow more flexibility and ~~extensiblity~~ between the server and front-end apps''' (any functionality/activities/objects not supported by Mastodon would only have to be implemented in the server-to-server REST API and the [https://graphql.org GraphQL] API).		Regarding the connection between the back-end and front-end app, the ActivityPub standard comes with a suggested [https://www.w3.org/TR/activitypub/#client-to-server-interactions client-server REST API specification], but for some reason Mastodon and many other fediverse apps have created their own custom REST APIs (and Pleroma implemented Mastodon’s so that it can share front-end apps). So an interesting option at this point for MoodleNet (and ''Pub of the Commons''), may be to still support Mastodon’s client REST API (for compatibility with existing front-ends like [https://github.com/nolanlawson/pinafore Pinafore]) and additionally to '''implement a new GraphQL-based API that would allow more flexibility and extensibility between the server and front-end apps''' (any functionality/activities/objects not supported by Mastodon would only have to be implemented in the server-to-server REST API and the [https://graphql.org GraphQL] API).

	= References =		= References =