Status: accepted
Online BarCamps that are organized with this BarCamp platform are taking place in a Matrix Space (ADR003) and use Matrix events to store the state (ADR004). In order to make make it work, we need to decide in which of the Matrix rooms in the BarCamp space we want to store the Matrix events.
Different data needs to be accessible from different locations:
- Topic Suggestions: They are used during the planning process and are only needed in the planning room.
- Session Grid (tracks, time slots, assigned topics): They are created and updated from the planning room. Every room needs to access the data to show a local agenda.
- Room mapping: They are created and updated from the planning room. Every room needs to access the data to know the assignment to a topic.
Some relevant properties of the Widget API:
- Each event belongs to a single room.
- Spaces are rooms with a special type.
- A widget must ask the user for permission to read or write events in a room (MSC2762).
- The permissions negotiation is done on widget initialization.
A widget could renegotiate the permissions during runtime, but this feature is not usable due to open issues (MSC2974,
matrix-widget-api#52
,matrix-react-sdk#7454
). - A widget can expand all permissions to a list of rooms, or all rooms a user joined (MSC2762).
- A widget can only interact with rooms that a user has already joined (MSC2762).
- A widget can only access the newest state event for each
state_key
(MSC2762). - There is no guarantee that a widget receives all room events in the timeline (MSC2762). The Matrix client can only provide timeline data that is loaded from the Matrix Server, which might be incomplete. There is no backfill so the widget must be reloaded to receive older data that the client fetched in the background.
- Additional parameters can be provided to the widget in the URL that is stored in the widget state event (by default: user name, room id, …) (MSC2764).
We will store the state events in the space room because they must be readable from every room in the space:
net.nordeck.barcamp.linked_room
net.nordeck.barcamp.session_grid
net.nordeck.barcamp.topic
We will store the room events in the lobby room because they only need to be accessible in the planning session:
net.nordeck.barcamp.topic_submission
We expect that every user joined the space.
We will also use the m.room.member
events of the space room.
The m.room.power_levels
event will be considered according to the location of the event.
We could also store all the state in the lobby room. But we can't guarantee that every user has joined the lobby room.
Find the space that stores the events with the following algorithm:
- The room that is listed in the
m.space.parent
of the room withcanonical === true
. - If the listed room has a
m.room.create
event withtype === 'space'
. - If the listed space has a
m.space.child
event that links back to the original room.
- Is there a
net.nordeck.barcamp.session_grid
with thestate_key === <own_room_id>
? → lobby room - Is there a
net.nordeck.barcamp.linked_room
with thestate_key === <own_room_id>
? → A topic room - Else → show welcome screen.
In order to display the grid, the widget must be able to read the data.
Since the capability renegotiation is unstable, we opt to request all required capabilities for everyone in all rooms.
We also aren't aware of the space that stores the data without reading the m.space.parent
event.
This includes:
m.room.members
: readm.room.power_levels
: readm.room.name
: read, writem.room.topic
: read, writem.room.create
: readm.space.child
: readm.space.parent
: readnet.nordeck.barcamp.linked_room
: read, writenet.nordeck.barcamp.session_grid
: read, writenet.nordeck.barcamp.topic
: read, writenet.nordeck.barcamp.topic_submission
: read, writeim.vector.modular.widgets
: read, write
Access space room
When working with spaces, it's often helpful to access the room of the space. To do that, enable the "Developer mode" lab option in the settings. Afterwards you can click "See room timeline (devtools) on the space menu.