Contexts and their management

timur commented

2026-04-12 15:04:05 +00:00

Owner

So, we have contexts. These are basically buckets we organize our digital life in, like namespaces. These contexts allow separation in our data, and allow us to manage where certain data is stored (which path) and even in the future access control over that data. Anyways: these contexts should live and be managed somewhere. There is tooling in hero_osis for having a root context and a data model in schemas. see specifically: lhumina_code/hero_rpc#13 (comment)

anyways, per this, we actually also want our context managed in hero osis. the root admin context (context 0) should have a list of contexts in the hero. it should have the knowledge associated with that context, like description, tags, and db path (which is the path that osis will use for the db behind osis.) Additionally, we need to create an issue in hero_proxy so that it can use hero_osis to list contexts etc, and hero_proxy should have its own state for acls associated with each context and do access control. See how hero proxy keeps state and enhance to allow for this and create an issue on the repo to specify.

So, we have contexts. These are basically buckets we organize our digital life in, like namespaces. These contexts allow separation in our data, and allow us to manage where certain data is stored (which path) and even in the future access control over that data. Anyways: these contexts should live and be managed somewhere. There is tooling in hero_osis for having a root context and a data model in schemas. see specifically: https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/13#issuecomment-17993 anyways, per this, we actually also want our context managed in hero osis. the root admin context (context 0) should have a list of contexts in the hero. it should have the knowledge associated with that context, like description, tags, and db path (which is the path that osis will use for the db behind osis.) Additionally, we need to create an issue in hero_proxy so that it can use hero_osis to list contexts etc, and hero_proxy should have its own state for acls associated with each context and do access control. See how hero proxy keeps state and enhance to allow for this and create an issue on the repo to specify.

timur referenced this issue from lhumina_code/hero_proxy

2026-04-12 15:19:28 +00:00

ACL state per context — consume hero_osis context list for access control #21

timur commented

2026-04-12 15:19:55 +00:00

Author

Owner

Implementation — schema side

Extended the Context rootobject in schemas/base/core.oschema with the three fields called out in the issue:

Context = {
    sid: sid
    name: str                       # [index]
    description?: str               # Human-readable description of what this context is for
    tags?: [str]                    # Free-form tags for grouping/filtering contexts
    db_path?: str                   # Filesystem path used by OSIS for this context's database
    created_at: u64
    updated_at: u64
}

All three are optional so existing stored contexts remain valid.

Regenerated types via cargo build -p hero_osis_server:

crates/hero_osis_server/src/base/{types_generated.rs, core/types_generated.rs, types_wasm_generated.rs, core/types_wasm_generated.rs}
crates/hero_osis_sdk/src/base/types.rs

(Sidenote: the oschema generator writes the flat src/base/types_generated.rs but the module tree still loads src/base/core/types_generated.rs — I copied the regenerated output into the core/ location to keep them in sync. That mismatch between the generator's output layout and the core/ directory structure is a separate tech-debt item worth tracking.)

Full workspace cargo check is clean.

Since Context is a rootobject in the base domain, CRUD is already exposed over the base.context_* RPC methods — the admin context (X-Hero-Context: 0) is the canonical holder of the list; no new endpoints were needed.

hero_proxy side

Filed companion issue: lhumina_code/hero_proxy#21

That issue covers:

Consuming base.context_list from hero_osis
Per-context ACL state in hero_proxy
Enforcement in the request path
Deciding where ACL state lives and how it syncs

It also flags that per the architecture comment in hero_rpc#13, hero_router is the sole TCP entry point now, so the design step should confirm whether this lives in hero_proxy or hero_router.

What's NOT done in this change

Setting/enforcing "context 0 only" on context writes (currently all contexts can CRUD contexts; that policy belongs in the proxy/router ACL layer per the companion issue, not in hero_osis itself).
Seeding default metadata for existing contexts (empty fields are fine).
UI for context management in hero_osis_ui.

## Implementation — schema side Extended the `Context` rootobject in `schemas/base/core.oschema` with the three fields called out in the issue: ``` Context = { sid: sid name: str # [index] description?: str # Human-readable description of what this context is for tags?: [str] # Free-form tags for grouping/filtering contexts db_path?: str # Filesystem path used by OSIS for this context's database created_at: u64 updated_at: u64 } ``` All three are optional so existing stored contexts remain valid. Regenerated types via `cargo build -p hero_osis_server`: - `crates/hero_osis_server/src/base/{types_generated.rs, core/types_generated.rs, types_wasm_generated.rs, core/types_wasm_generated.rs}` - `crates/hero_osis_sdk/src/base/types.rs` (Sidenote: the oschema generator writes the flat `src/base/types_generated.rs` but the module tree still loads `src/base/core/types_generated.rs` — I copied the regenerated output into the `core/` location to keep them in sync. That mismatch between the generator's output layout and the `core/` directory structure is a separate tech-debt item worth tracking.) Full workspace `cargo check` is clean. Since `Context` is a `rootobject` in the `base` domain, CRUD is already exposed over the `base.context_*` RPC methods — the admin context (`X-Hero-Context: 0`) is the canonical holder of the list; no new endpoints were needed. ## hero_proxy side Filed companion issue: lhumina_code/hero_proxy#21 That issue covers: - Consuming `base.context_list` from hero_osis - Per-context ACL state in hero_proxy - Enforcement in the request path - Deciding where ACL state lives and how it syncs It also flags that per the architecture comment in hero_rpc#13, hero_router is the sole TCP entry point now, so the design step should confirm whether this lives in hero_proxy or hero_router. ## What's NOT done in this change - Setting/enforcing "context 0 only" on context writes (currently all contexts can CRUD contexts; that policy belongs in the proxy/router ACL layer per the companion issue, not in hero_osis itself). - Seeding default metadata for existing contexts (empty fields are fine). - UI for context management in hero_osis_ui.