Fediventure

Note: all of this is currently in flux - the best to participate in the fediventure community is to join our community or participate in the linked tracking issues and voice your opinion on these approaches.

Requirements

The high-level requirements for any federation solution is:

• A *space can host their own WA instance (backend, frontend, pusher, mapserver) to participate in the network.
• A space can defer to some other trusted space to host/colocate their instance for them
• Users of the fediventure should be able to easily travel between these instances

Solutions

There are multiple concurrent approaches currently being explored for federating WorkAdventure across different spaces. We aim to implement the first (stopgap) as fast as possible to get anything running, and simultaneously work on matrixful and matrixless* as a long-term solution.

'stopgap'

a.k.a. “Just run some WA instances and use existing functionality to link them together.”

Currently, just deploying WorkAdventure in any way yields to some possiblity of linking instances together, if you modify your map to point to other reachable maps, which in turn point to other backend/pusher instances.

Notably missing are, however:

1) any lobby/directory/discoverability 2) cross-instance identity

Status: implementation ; see: Tracking issue

'matrixless'

a.k.a. “Use something like indieauth and some backend changes to build some bespoke federated system”

Status: design, discussion ; see: Tracking issue.

This naturally conflicts with the matrixful approach defined below. The community will have to decide which one of these to pick.

'matrixful'

a.k.a. “This maps well into Matrix, let's try doing that”

Status: waiting for design proposal

This naturally conflicts with the matrixless approach defined above. The community will have to decide which one of these to pick.