# Securing Hyperfy Components in World
Draft of requirements to describe how in-world security can be handled to support flexible and comprehensive security scenarios to enable seamless and productive collaboration between users.

## Example Use Cases
1. Event organizers can create a fully featured event with various activations (hyper apps) that provide distinct experiences to users. Event operators organized into control groups for specific areas of responsibilities such as moderation, API/blockchain minting experience, sound and light, recording.
2. Builder creates learning environment providing sandbox to users to interact and edit objects contained within learning environment but not disrupt learning setup.
3. Metaverse organizer invites builders to set up showcase stalls with custom built models and activations without interfering with other builders in world.
4. Host a world where external users can import external apps to be run in world.

## Basic need for securing components
* **Zone-based or group-based containers** to tie permissioned roles to apps contained within a phyiscal zone or app group.
* **Identity Authentication and Federation** to identify unique users and support role assignments in world.
* **Sample role-based access control (RBAC)** to define who can, access what.
* **World owner** to define core security configuration and designate sub-admin permissions.
* **Sub-admins** with broad control over world security hierarchy by setting Zone controls, App groups, and Permissioned Role controls on objects (admins can edit scripts).
* **Operators** with fine-tuned control over configuration assigned to an object (user cannot edit scripts only, change inputs).
* **App Importer** user enabled for permissioned authorization to import apps into world.
* **App User** basic user with access to navigate world (avatar) and interact with apps.
* **Logical grouping of features/functions** together to minimize effort to maintain security at a granular level such as any function that modifies position of an app.
* **Template role definitions** to provide a starting point for security and flexibility in world to customize further.

## Security hierarchy walkthrough
* Roles can be tied directly to apps (models) with set permissions to use, operate, or edit the app. This overrides inherited Zone/Group permissions (use sparingly).
* Apps (models) can be tied to zones to inherit security settings at the zone level.
* Zones permissions are set by sub-admin permissions. Some securable actions include:
* Ability to edit scripts within apps
* Ability to interact with apps
* Ability to move apps within zones
* Ability to configure apps (without script access)
* Ability to import apps within zones

### Example: App Grouping

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes
                
                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this
                AppGroups->{Lights Arcade GuestBook}
                Lights->{Model_a Model_b}
                Model_a->{Operator_1}
                Model_b->{Operator_1}
                Arcade->{Model_d}
                Model_d->{Operator_2}
                GuestBook->{Model_c}
                Model_c->{Admin_Y}

}

---

### Example: World Owner and Admin Span of Control

# World Owner

## Define Sub-Admin X (Zone Admin)
- Control zone creation and placement
- Import and assigns apps to zones
## Define Sub-Admin Y (App Group Manager)
- Assign apps to zones and groups
- Define operator permissions
- Configure app scripts
## Define Sub-Admin Z (Security Admin)
- Define app importer
- Define app user
- Moderate users (mute/kick/ban)

### Example: Zone Control

## *Zone 1 (Constrained Inheritance)*
- Model a
    - Usable by App User
    - Configurable by Zone 1 Operator
    - Script editable by Admin Y
- Model x
    - Imported by App Importer
    - Usable by App User
    - Configurable by Zone 1 Operator
    - Script editable by Admin Y 
## *Zone 2 (Default Unconstrained)*
- Model b (default object)
    - Usable by App Users
    - Configurable by Zone 2 Operator
    - Editable by Admin Y 
- Model c (locked to admin)
    - Usable by App User
    - Configurable and editable by Admin Y
- Model d (operator z1 enabled)
    - Usable by App User
    - Configurable by Zone 2 Operator
    - Configurable by Zone 1 Operator
    - Editable by Admin Y
- Model y (locked to importer)
    - Imported and usable by App Importer
    - Configurable and editable by Admin Y 

## Scope creep requirements
* **SCOPE CREEP:** Version control (ability to audit and recover changes made to objects across the world)
* **SCOPE CREEP:** Constraining specific commands to defined roles