# 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