Multiplayer session APIs

Hi, i see that the Multiplayer session APIs are currently only available on 

Will we eventually be able to use these on our own servers as well?

Great work!


BV52's picture

Hi Ian,

The Multiplayer content types will only be available for customers who are on enterprise or standard rate plans. Please check the June 2021 release notes for more details.


These look really nice! Is there a plan to make them available as open-source?

BV52's picture

Hi mi3ll,

Yes, but it may take a while. The Multiplayer content types were designed to utilize the infrastructure available in so developing it for the plugins may take some time to accomplish.


otacke's picture


Oh, sweeeet! I am volunteering to assist.



serettig's picture

Hi BV,

This is great news! Could you ask the core team if they will release the API sepcs or some samples soon, even if the plugins and the h5p core aren't updated yet? We've had requests for our NodeJS version of the H5P server to add multiplayer capabilities (and funding prospects) and we'd have to implement everything ourselves anyway. It would be much better if we didn't have to do our own API which would obviously be incompatible.


Great news! Looking forward to it.

falcon's picture

There are no generic multiplayer APIs on The content types built so far are running "game logic" (js) both on the servers and on the clients. We considered allowing content types to include server side scripts or libraries, but that would be problematic especially from a security perspective. We found no sensible way to create generic APIs for what we wanted to do with the content types built so far.

It would be awesome if you would start working on a generic multiplayer API for H5P and share your plans here in the forum as you move forward with it. We could also do a call to sync if that makes sense. It will be important to find a good way for content types to define what operations the players are allowed to do on the game state and when, or we have to define a very simple API that limits what might be created with it.

serettig's picture

Thank you for the insights!

We've thought along the lines of integrating ShareDB into the system. It seems like a good pick for allowing collaboration through websockets and circumventing all the complexities of syncing states. The server would run on NodeJS (PHP isn't great for using websockets, which are persistent after all) and we already use it anyway. It would also be possible to have the NodeJS multiplayer server as a standalone microserve that is used by PHP implementations, I guess.

My ideas were to indeed have a generic multiplayer API:

  • the client is free in how it organizes its state and what transactions it uses, but it has to use ShareDB to send transactions to the server (H5P.ShareDB library as a proxy)
  • the server hooks into the ShareDB lifecycle events and performs validation checks; the validation checks are defined in a schema file that is similar to semantics.json
  • it validates every transaction it receives against a static JSON schema (e.g. or the custom semantics.json schema) defined by the library & checks if the transaction is allowed by the user (there would be a student and a teacher role)
  • it sanitizes transactions to avoid XSS
  • it performs same more complex logic checks that can be declaratively defined in the schema (e.g. equality of JSON paths, uniqueness of values etc.)
  • transactions can include placeholders like %userId or %datetime which are inserted into the transaction by the server; this avoid abuse
  • after the transaction is applied to the state it validates the new state against a static JSON schema for the whole state (again JSON schema or custom H5P) and performs logic checks (uniqueness of values to avoid multiple votes etc.)

That way you could have a generic server and all the individual content type functionality could still lie in the JS frontend libraries. There's no need to install custom code on the server as you only have schema files that are declarative.

I would love a short call about how to go forward on this, especially about possible ways of integrating technologies. You can contact me at [email protected]. We might get funding for this or at least parts of it in early 2022.


falcon's picture

Sounds great! I think we can do a lot with that. I sent you an email. There are also many scenarios that will be difficult to do with that approach (see below) and I think we just have to limit the scope a bit if we don't want to be running too complex game specific logic on the servers.

Some interesting scenarios for multiplayer are for instance voting, document collaboration, ludo and competitions using existing content types. For the first two the participants pretty much collaborates on a set of data. Voting may have some extra states (pause, presenter allows voters to change their mind after a discussion, timers etc. but nothing too complicated. Ludo introduces more complex rules and what are valid choices depends on the state of the game and the number on the dice and the dice must be thrown by the server(random number from the server). Competition with existing content types introduces the need for the server to check the answers and award points also taking into account any scoring options the content type may have(if we don't want to allow cheating). I think if we are to allow any game we will need such complex server side logic that we might as well use an existing language to descibe it(js for instance) instead of writing our own json based. 

otacke's picture

Here"s a demo/draft.