lhumina_code/hero_os_tfgrid_deployer
0
0
Fork 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions

meeting minutes #1

New issue
Open
opened 2026-05-20 17:24:43 +00:00 by despiegk · 1 comment
despiegk commented 2026-05-20 17:24:43 +00:00
Owner
Copy link

Meeting Minutes — Hero OS Grid Deployer / Demo Environment

Source: meeting transcript uploaded by user.

1. Main Goal

Create an internal deployment tool that can deploy Forge Hero OS demo environments as virtual machines on the ThreeFold Grid.

The first version is for internal/admin use, not yet self-service billing. The team will pay for the VMs using available TFT/DFT capacity, so demo users can try Hero OS without handling infrastructure.

2. Core Architecture

The deployment stack has two main parts:

Hero Compute backend

  • Low-level backend with one ThreeFold Grid private key.

  • Exposes an OpenRPC interface.

  • Responsible for:

    • creating VMs,
    • deleting VMs,
    • listing VMs,
    • adding/configuring web gateways.

  • Mahmoud is working on this and needs to finish the VM + web gateway functionality as priority.

Hero OS Grid Deployer

  • Admin-facing tool.

  • Used by the team to create demo users and deploy their VM.

  • Keeps records of:

    • user accounts,
    • SSH keys,
    • deployed nodes/VMs,
    • gateway URLs,
    • configuration/state.

  • Backend can use SQLite or the preferred schema/database approach.

3. VM Deployment Model

Each demo user receives:

  • One VM on the ThreeFold Grid.
  • Target size: 8 GB RAM.
  • VM should be large enough for the core Hero OS services, embedder, books, router, proxy, cockpit, etc.
  • The VM is considered non-production.
  • Users must be warned that data may be lost.

Deployment flow:

  1. Admin creates or selects a user.

  2. Tool checks whether the user exists in Forge.

  3. If not, tool creates the Forge account.

  4. Tool generates:

    • random password,
    • Forge key/token where needed,
    • dedicated SSH key for the VM.

  5. Tool deploys the VM through Hero Compute.

  6. Tool logs into the VM via SSH.

  7. Tool installs required binaries using the lab/service install flow.

  8. Tool starts required Hero services through Hero Proc.

  9. Tool configures Hero Proxy and web gateway access.

4. Forge Integration

The deployer must integrate with Forge.

Required behavior:

  • Check whether a Forge user exists.
  • Create a Forge user if missing.
  • Generate or store the required Forge key/token.
  • Later, the end user should be able to update their own email or account settings through a user-facing UI.

Forge is now the central account system.

5. Hero Proc and Service Selection

The VM should use Hero Proc to manage the installed services.

Idea:

  • Create one Hero Proc service definition that includes selected components.
  • Admin or user can select which components should be enabled.
  • Backend creates/updates the service definition based on selected components.
  • Initial install still needs to download/install required binaries using the lab command.

Core services expected:

  • Hero Proxy
  • Hero Router
  • Hero Proc
  • Embedder / small embedder model
  • Books
  • Cockpit
  • Possibly whiteboard, slides, call-up, agents, and selected demo services.

Office should not be enabled initially because it is too heavy unless hosted separately.

6. Web Gateway and Proxy

The external access model:

  • Web gateway maps an external name/URL to the VM.
  • Traffic goes through Mycelium where appropriate.
  • The gateway reaches Hero Proxy inside the VM.
  • Hero Proxy handles routing and authentication.
  • Proxy can map different URLs to different services.

The cockpit should be exposed as the main user-facing entry point.

7. User-Facing Tool: Hero Cockpit

A simple end-user UI is needed, tentatively called Hero Cockpit.

Purpose:

  • The user logs into their VM environment.
  • They can manage their own demo services.
  • It should be very simple.

Cockpit features:

  • View available services.

  • Enable/disable selected services.

  • Trigger install/delete/update actions through Hero Proc.

  • Set or update:

    • Forge token,
    • OpenRouter key,
    • Groq key,
    • SambaNova key.

  • Provide an upgrade button.

  • Show a simple manual/help page.

  • Possibly include AI help later.

  • Clearly state that this is a non-production demo environment.

Important: AI usage should be bring-your-own-key for now to avoid the team carrying AI inference costs.

8. Demo Content and Books

The VM should include a pre-populated Books collection.

Action needed:

  • Create a public repo or collection with safe demo content.
  • Avoid exposing too much internal/private information.
  • Possible name: ourworld_public, lumina_public, or similar.
  • Automatically load this into Books so users have useful content from the start.

9. Feedback Loop

A public feedback mechanism should be created through Forge.

Proposal:

  • Create a public organization, possibly lumina_public.
  • Create a repo such as feedback.
  • Give demo users access.
  • Cockpit should allow users to submit feedback by text or voice.
  • Feedback becomes structured issues or entries in the Forge repo.
  • Team can review, respond, and improve the product from real user feedback.

No complicated script is needed for now. Keep it simple: Cockpit calls Forge directly via REST/OpenRPC/client.

10. Demo Scope

Initial demo services should focus on what is light and impressive:

  • Books
  • Slides
  • Whiteboard
  • Call-up
  • Agents
  • Voice integration
  • Kimi/custom coding agents later

Avoid heavy components at first:

  • Office/document server should wait unless hosted externally.
  • Billing/onboarding with Stripe should wait.

11. Billing and Self-Service

Billing is explicitly not part of the first version.

Phase 1:

  • Internal/admin tool.
  • Team creates demo users manually.
  • Team pays for the VM capacity.
  • Users bring their own AI keys.

Future phase:

  • Add self-service onboarding.
  • Users enter credit card/payment details.
  • Billing and capacity charging are handled automatically.
  • This will require a separate higher-level service on top of the current OpenRPC deployer.

12. Team Priorities

Immediate priority:

  • Focus fully on the deployer.
  • Do not spend time on Stripe onboarding yet.
  • Mahmoud should finish Hero Compute and web gateway support.
  • Scott should continue integrating voice everywhere.
  • Embedder should use the smaller model to fit comfortably in 8 GB VMs.

13. Investor / Demo Importance

This tool is important because it allows the team to:

  • Deploy many Hero OS demo environments quickly.
  • Give access to investors, partners, community members, and Bifrost-related stakeholders.
  • Collect real feedback.
  • Show that Hero OS works end-to-end.
  • Increase confidence in the product.
  • Drive real usage of the existing ThreeFold Grid.

14. Decisions

  • Use 8 GB VMs for demo users.
  • Build first version as internal/admin deployer.
  • Use Forge accounts as the identity/account system.
  • Use Hero Compute as the backend for VM and gateway operations.
  • Use Hero Proc for installing/updating/running services inside the VM.
  • Use Hero Proxy as the secure external entry point.
  • Create a simple Hero Cockpit for end users.
  • Use bring-your-own AI keys for OpenRouter/Groq/SambaNova.
  • Add a public feedback repo through Forge.
  • Do not implement billing yet.
  • Keep the first demo lightweight and practical.

15. Action Items

Owner Action
Mahmoud Finish Hero Compute VM lifecycle functions: create, delete, list.
Mahmoud Add web gateway support to Hero Compute.
Team Define clean OpenRPC interface for Hero Compute.
Kristof / team Continue cleaning hero_os_grid_deployer repo.
Deployer owner Implement Forge user check/create flow.
Deployer owner Generate/store SSH keys per user/VM.
Deployer owner Store user, VM, gateway, and key metadata in backend DB.
Deployer owner Deploy 8 GB VM per demo user.
Deployer owner SSH into VM and run lab install flow.
Deployer owner Configure Hero Proc services for selected components.
Deployer owner Configure Hero Proxy and gateway routing.
Team Create simple Hero Cockpit repo/spec.
Team Add service enable/disable and upgrade actions to Cockpit.
Team Add BYO key settings for OpenRouter, Groq, SambaNova.
Team Create public demo Books content repo/collection.
Team Create public Forge organization/repo for user feedback.
Scott Continue voice integration across the demo environment.
Team Use smaller embedder model for demo VM profile.
Team Defer Stripe/billing/self-service onboarding until after the deployer works.
## Meeting Minutes — Hero OS Grid Deployer / Demo Environment **Source:** meeting transcript uploaded by user. ### 1. Main Goal Create an internal deployment tool that can deploy **Forge Hero OS demo environments** as virtual machines on the **ThreeFold Grid**. The first version is for **internal/admin use**, not yet self-service billing. The team will pay for the VMs using available TFT/DFT capacity, so demo users can try Hero OS without handling infrastructure. ### 2. Core Architecture The deployment stack has two main parts: **Hero Compute backend** * Low-level backend with one ThreeFold Grid private key. * Exposes an OpenRPC interface. * Responsible for: * creating VMs, * deleting VMs, * listing VMs, * adding/configuring web gateways. * Mahmoud is working on this and needs to finish the VM + web gateway functionality as priority. **Hero OS Grid Deployer** * Admin-facing tool. * Used by the team to create demo users and deploy their VM. * Keeps records of: * user accounts, * SSH keys, * deployed nodes/VMs, * gateway URLs, * configuration/state. * Backend can use SQLite or the preferred schema/database approach. ### 3. VM Deployment Model Each demo user receives: * One VM on the ThreeFold Grid. * Target size: **8 GB RAM**. * VM should be large enough for the core Hero OS services, embedder, books, router, proxy, cockpit, etc. * The VM is considered **non-production**. * Users must be warned that data may be lost. Deployment flow: 1. Admin creates or selects a user. 2. Tool checks whether the user exists in Forge. 3. If not, tool creates the Forge account. 4. Tool generates: * random password, * Forge key/token where needed, * dedicated SSH key for the VM. 5. Tool deploys the VM through Hero Compute. 6. Tool logs into the VM via SSH. 7. Tool installs required binaries using the lab/service install flow. 8. Tool starts required Hero services through Hero Proc. 9. Tool configures Hero Proxy and web gateway access. ### 4. Forge Integration The deployer must integrate with Forge. Required behavior: * Check whether a Forge user exists. * Create a Forge user if missing. * Generate or store the required Forge key/token. * Later, the end user should be able to update their own email or account settings through a user-facing UI. Forge is now the central account system. ### 5. Hero Proc and Service Selection The VM should use **Hero Proc** to manage the installed services. Idea: * Create one Hero Proc service definition that includes selected components. * Admin or user can select which components should be enabled. * Backend creates/updates the service definition based on selected components. * Initial install still needs to download/install required binaries using the lab command. Core services expected: * Hero Proxy * Hero Router * Hero Proc * Embedder / small embedder model * Books * Cockpit * Possibly whiteboard, slides, call-up, agents, and selected demo services. Office should not be enabled initially because it is too heavy unless hosted separately. ### 6. Web Gateway and Proxy The external access model: * Web gateway maps an external name/URL to the VM. * Traffic goes through Mycelium where appropriate. * The gateway reaches Hero Proxy inside the VM. * Hero Proxy handles routing and authentication. * Proxy can map different URLs to different services. The cockpit should be exposed as the main user-facing entry point. ### 7. User-Facing Tool: Hero Cockpit A simple end-user UI is needed, tentatively called **Hero Cockpit**. Purpose: * The user logs into their VM environment. * They can manage their own demo services. * It should be very simple. Cockpit features: * View available services. * Enable/disable selected services. * Trigger install/delete/update actions through Hero Proc. * Set or update: * Forge token, * OpenRouter key, * Groq key, * SambaNova key. * Provide an upgrade button. * Show a simple manual/help page. * Possibly include AI help later. * Clearly state that this is a non-production demo environment. Important: AI usage should be **bring-your-own-key** for now to avoid the team carrying AI inference costs. ### 8. Demo Content and Books The VM should include a pre-populated Books collection. Action needed: * Create a public repo or collection with safe demo content. * Avoid exposing too much internal/private information. * Possible name: `ourworld_public`, `lumina_public`, or similar. * Automatically load this into Books so users have useful content from the start. ### 9. Feedback Loop A public feedback mechanism should be created through Forge. Proposal: * Create a public organization, possibly `lumina_public`. * Create a repo such as `feedback`. * Give demo users access. * Cockpit should allow users to submit feedback by text or voice. * Feedback becomes structured issues or entries in the Forge repo. * Team can review, respond, and improve the product from real user feedback. No complicated script is needed for now. Keep it simple: Cockpit calls Forge directly via REST/OpenRPC/client. ### 10. Demo Scope Initial demo services should focus on what is light and impressive: * Books * Slides * Whiteboard * Call-up * Agents * Voice integration * Kimi/custom coding agents later Avoid heavy components at first: * Office/document server should wait unless hosted externally. * Billing/onboarding with Stripe should wait. ### 11. Billing and Self-Service Billing is explicitly **not part of the first version**. Phase 1: * Internal/admin tool. * Team creates demo users manually. * Team pays for the VM capacity. * Users bring their own AI keys. Future phase: * Add self-service onboarding. * Users enter credit card/payment details. * Billing and capacity charging are handled automatically. * This will require a separate higher-level service on top of the current OpenRPC deployer. ### 12. Team Priorities Immediate priority: * Focus fully on the deployer. * Do not spend time on Stripe onboarding yet. * Mahmoud should finish Hero Compute and web gateway support. * Scott should continue integrating voice everywhere. * Embedder should use the smaller model to fit comfortably in 8 GB VMs. ### 13. Investor / Demo Importance This tool is important because it allows the team to: * Deploy many Hero OS demo environments quickly. * Give access to investors, partners, community members, and Bifrost-related stakeholders. * Collect real feedback. * Show that Hero OS works end-to-end. * Increase confidence in the product. * Drive real usage of the existing ThreeFold Grid. ### 14. Decisions * Use **8 GB VMs** for demo users. * Build first version as **internal/admin deployer**. * Use **Forge accounts** as the identity/account system. * Use **Hero Compute** as the backend for VM and gateway operations. * Use **Hero Proc** for installing/updating/running services inside the VM. * Use **Hero Proxy** as the secure external entry point. * Create a simple **Hero Cockpit** for end users. * Use **bring-your-own AI keys** for OpenRouter/Groq/SambaNova. * Add a public feedback repo through Forge. * Do **not** implement billing yet. * Keep the first demo lightweight and practical. ### 15. Action Items | Owner | Action | | -------------- | ---------------------------------------------------------------------------- | | Mahmoud | Finish Hero Compute VM lifecycle functions: create, delete, list. | | Mahmoud | Add web gateway support to Hero Compute. | | Team | Define clean OpenRPC interface for Hero Compute. | | Kristof / team | Continue cleaning `hero_os_grid_deployer` repo. | | Deployer owner | Implement Forge user check/create flow. | | Deployer owner | Generate/store SSH keys per user/VM. | | Deployer owner | Store user, VM, gateway, and key metadata in backend DB. | | Deployer owner | Deploy 8 GB VM per demo user. | | Deployer owner | SSH into VM and run lab install flow. | | Deployer owner | Configure Hero Proc services for selected components. | | Deployer owner | Configure Hero Proxy and gateway routing. | | Team | Create simple Hero Cockpit repo/spec. | | Team | Add service enable/disable and upgrade actions to Cockpit. | | Team | Add BYO key settings for OpenRouter, Groq, SambaNova. | | Team | Create public demo Books content repo/collection. | | Team | Create public Forge organization/repo for user feedback. | | Scott | Continue voice integration across the demo environment. | | Team | Use smaller embedder model for demo VM profile. | | Team | Defer Stripe/billing/self-service onboarding until after the deployer works. |
mik-tf commented 2026-05-20 21:54:04 +00:00
Owner
Copy link

s132 close — VM bootstrap groundwork done, 7 sub-issues filed for v0.1

Bootstrap-from-binaries pipeline (Action Item 7 in §15 of the meeting notes — "deployer owner: SSH into VM and run lab install flow") is proven end-to-end on a fresh TFGrid VM at herolab.gent02.grid.tf. The deployer can SSH in + run setup-binaries.sh and end up with a running Hero OS (currently the bootstrap-core only — proc + router; the per-user component selection menu drives the rest in subsequent sessions).

Proof point

  • Fresh TFGrid VM provisioned via make deploy ENV=herolab (OpenTofu) in 61 s, mycelium-only access
  • make setup-binaries ENV=herolab → 34/34 PASS on lab build $repo --download --install (mycelium_network skipped — TFGrid native via zinit per §6 of the notes)
  • hero_proc_server PID 6971 + hero_router PID 7070 with 6/6 smoke tests
  • curl http://127.0.0.1:9988/.well-known/heroservice.json → HTTP 200

Code lives in hero_demo/deploy/single-vm/ — commit 09f8365.

Sub-issues filed for v0.1 (scope declared before code starts)

# Title
#2 v0.1 scope umbrella
#3 D1 — scaffold + sqlite schema
#4 D2 — Forge user lifecycle
#5 D3 — VM-deploy adapter (OpenTofu + hero_compute)
#6 D4 — post-deploy flow
#7 D5 — admin UI
#8 D6 — setup-binaries.sh manifest refactor

Cross-repo coordination

  • hero_cockpit#1 — deep spec for the end-user UI (Action Items 12–14: cockpit + BYO keys + service enable/disable + feedback + manual)
  • hero_compute#116 — coordination with @maxux. All needed methods (deploy_vm, deploy_webgateway, inject_ssh_keys, vm_exec, vm_logs, etc.) are already exposed via OpenRPC at crates/my_compute_zos_server/src/cloud/openrpc.json. Issue asks 4 confirmation questions + flags 4 small gaps.
  • lhumina_public/feedback#1 (PR) — repo bootstrap (README + .forgejo/issue_template/{bug,feature,feedback}.md). Awaiting merge — once in, cockpit's feedback iframe at §3.4 of the cockpit spec can land users on a polished surface (Action Items in §9 of the notes — "create public Forge organization/repo for user feedback").

Forward roadmap

24-26 sessions across 6 tracks; full session-by-session breakdown lives in the workspace's prompt.md §3. Priority over hero_onboarding per the meeting; we drive the whole arc on our side with light coordination issues to keep teammates aligned.

This issue stays open as the canonical reference to the meeting; sub-issue #2 is the umbrella for active v0.1 work.

## s132 close — VM bootstrap groundwork done, 7 sub-issues filed for v0.1 Bootstrap-from-binaries pipeline (Action Item 7 in §15 of the meeting notes — "deployer owner: SSH into VM and run lab install flow") is **proven end-to-end** on a fresh TFGrid VM at `herolab.gent02.grid.tf`. The deployer can SSH in + run `setup-binaries.sh` and end up with a running Hero OS (currently the bootstrap-core only — proc + router; the per-user component selection menu drives the rest in subsequent sessions). ### Proof point - Fresh TFGrid VM provisioned via `make deploy ENV=herolab` (OpenTofu) in 61 s, mycelium-only access - `make setup-binaries ENV=herolab` → 34/34 PASS on `lab build $repo --download --install` (mycelium_network skipped — TFGrid native via zinit per §6 of the notes) - hero_proc_server PID 6971 + hero_router PID 7070 with 6/6 smoke tests - `curl http://127.0.0.1:9988/.well-known/heroservice.json` → HTTP 200 Code lives in [hero_demo/deploy/single-vm/](https://forge.ourworld.tf/lhumina_code/hero_demo/src/branch/development/deploy/single-vm/) — [commit 09f8365](https://forge.ourworld.tf/lhumina_code/hero_demo/commit/09f8365). ### Sub-issues filed for v0.1 (scope declared before code starts) | # | Title | |---|---| | [#2](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/2) | v0.1 scope umbrella | | [#3](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/3) | D1 — scaffold + sqlite schema | | [#4](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/4) | D2 — Forge user lifecycle | | [#5](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/5) | D3 — VM-deploy adapter (OpenTofu + hero_compute) | | [#6](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/6) | D4 — post-deploy flow | | [#7](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/7) | D5 — admin UI | | [#8](https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/issues/8) | D6 — setup-binaries.sh manifest refactor | ### Cross-repo coordination - [hero_cockpit#1](https://forge.ourworld.tf/lhumina_code/hero_cockpit/issues/1) — deep spec for the end-user UI (Action Items 12–14: cockpit + BYO keys + service enable/disable + feedback + manual) - [hero_compute#116](https://forge.ourworld.tf/lhumina_code/hero_compute/issues/116) — coordination with @maxux. All needed methods (`deploy_vm`, `deploy_webgateway`, `inject_ssh_keys`, `vm_exec`, `vm_logs`, etc.) are already exposed via OpenRPC at `crates/my_compute_zos_server/src/cloud/openrpc.json`. Issue asks 4 confirmation questions + flags 4 small gaps. - [lhumina_public/feedback#1 (PR)](https://forge.ourworld.tf/lhumina_public/feedback/pulls/1) — repo bootstrap (README + `.forgejo/issue_template/{bug,feature,feedback}.md`). Awaiting merge — once in, cockpit's feedback iframe at §3.4 of the cockpit spec can land users on a polished surface (Action Items in §9 of the notes — "create public Forge organization/repo for user feedback"). ### Forward roadmap 24-26 sessions across 6 tracks; full session-by-session breakdown lives in the workspace's `prompt.md` §3. Priority over hero_onboarding per the meeting; we drive the whole arc on our side with light coordination issues to keep teammates aligned. This issue stays open as the canonical reference to the meeting; sub-issue #2 is the umbrella for active v0.1 work.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_os_tfgrid_deployer#1
No description provided.