Secure Architecture

Written for AI agents. See Log Methodology Note below for details.

as noted in 02 - Jay Element and Component and in 09 - save events, the main architecture idea for securing Jay Components is to run the Component in a worker, while the Element runs in the main window.

This document explores this architecture.

Basic Architecture

The basic architecture of a jay application is a tree of elements and components as in the following diagram

We note that a component has only one child element, while an element may have one or more child components. The child components of an element can be static, under condition, or under for each.

The secure architecture is

We note in this diagram a few additional things

1. we have two root components - the main root and the worker root, which are responsible for the creation of the Jay component and element structure and establishing a communication channel.
2. on the worker, we replace each element with an element bridge or element stab.
3. The element bridge is generated by the compiler and acts like the element, except it does not render DOM. instead, it records the input ViewState and creates instances of child components when needed
4. The element stab only role is to record the input ViewState and need not be compiler generated
5. The Null Component is in the position of the root component in the main thread and passes the recorded ViewState of the root component to the first element
6. The Component Bridge receives the ViewState from the worker and passes it into the Element.

The Communication Challenge

In order to facilitate communication between the main and worker instances, we have to create some language that identifies the relationships of elements and components, in three aspects

• identify element -> component relation (1:N) in both main and worker
• identify component -> element relation (1:1) in both main and worker
• identify component <-> component relation (1:1) between the worker and main

Mapping Challenges 1,2

The first two can be easily solved using a unique id generated by the first element childComp construct for each child component, and passing that id also for the component child element. Those ids can be generated by the element bridges in the worker as global ids for uniqueness between components.

We can denote those ids as tree id as those ids are mapping the relations element -> component -> element

Mapping Challenge 3

The third challenge is to sync the element in the main with the element in the worker and how they correlate to one another. The element in main and the element bridge in the worker can be generated with unique coordinates that are in sync, used to create the tree ids in sync.

The algorithm

We use the ConstructionContext (internal to runtime) as the storage for coordinates as the nested structure of ConstructionContexts makes it simple to create coordinates built from the matchBy ids of collection with an id on the ChildComp member. So for a nested component under two collections, the coordinate will be [{first forEach matchBy},{second forEach matchBy},{ChildComp coordinates}].

The coordinatess are then guaranteed to be unique and consistent, defined during component creation. Keep in mind that the coordinatess are only unique within the scope of a single element.

We then exchange the coordinatess with tree ids (tree ids are globally unique). During component creation in the worker, the element bridge has the coordinates. we generate a new unique tree id and pass the mapping coordinates -> tree id to the main.

On the main, the component bridge gets the coordinates from the parent element, and is using the coordinates -> tree id mapping to get its data.

---

Log Methodology Note

Note: These design logs are written primarily for AI agents as part of the Design Log methodology and made accessible here for human readers. The language and structure are optimized for machine consumption — expect precise, specification-style prose rather than narrative documentation.