---
# System prepended metadata

title: Tarkus

---

# Tarkus

1. Point-of-perspective is Activity

   1.1. Activity, as a communication subject, is generic and its data is basically *unknown* and determined by the *plugin*

   1.2. Activity Plugin is an implementation detail conforming to the interface defined for communication between one or multiple nodes involving Activity

   1.3. The entire system is a state machine whose next state is determined by the engine which is not intrinsic to the Activity, although Activity has next state and undo support (history)

   1.4. State machine is a server-side implementation also conforming to the interfaces defined in the *plugin* architecture

2. Once the *plugin architecture* is in place, *renderers* or modules which interpret state machine can be developed. Some examples of the renderers could be:

   a) music notation/lessons

   b) simple blackboard (like in schools)

   c) coding -> interactive VSCode

   d) games (Chess Tent being one variant, others might involve for e.g. card games)

   e) low-level screen sharing with possible screen-takeover

3. In tandem with renderers, an interactivity layer would be needed. It could have:

   1. low-level screen-takeover support (lower priority) and/or screen drawing support (suited for 2. b) scenarios)
   2. state machine/activity-related interactivity (mandatory)
      1. possible variant of it could be *raise hand* (ask for permission to intercept activity flow). If granted, another node takes over. 

4. Recording sessions

 