meeting lee-kristof organization #3

New issue

Closed

opened 2025-12-17 12:07:44 +00:00 by despiegk · 0 comments

despiegk commented 2025-12-17 12:07:44 +00:00

Owner

Copy link

is for our HeroRoadmap

Team Report — Product & Architecture Direction (meeting notes)

Context

• Current product is not good enough and incremental fixes to the existing architecture are considered too slow.
• Team execution has been uneven: prior attempts to align via written “bluebooks/specs” did not produce deliverables, which is creating frustration and confusion about “the bigger picture”.
• AI-driven development has changed the cost/benefit of approaches: tasks previously considered “big limits” may now be solved much faster, and manual ops / manual scripting is becoming obsolete.

Core conclusions

• We need a new, simplified architecture and a first tangible product fast (weeks, not months), otherwise momentum with new supporters/partners risks dropping.
• “Just cloud / Kubernetes cloud” is not believed to be a strong enough use-case to fill capacity; we need an application-level product that creates pull-through for infrastructure.
• Organizationally: there’s a push to reduce manual work, reduce coordination overhead, and raise execution speed (AI-assisted), while avoiding a scenario where most of the team becomes unproductive in an “AI world”.

Product direction (low-hanging fruit)

Candidate “first product”

A decentralized GitHub alternative (code hosting + project management + CI/CD) with:

• Lightweight data model (opinionated defaults, fewer moving parts than typical forge platforms).
• Decentralization-first design, with eventual peer-to-peer sync and group-based access control.

Working name mentioned: HeroForge (forge/repo UI + backend).

Why this direction

• A “forge” product is tangible, demoable, and can attract both internal morale and external partners.
• It creates an immediate use-case for decentralized compute/storage fabric (and later “slices”, nodes, etc.).

Architecture direction (what’s emerging)

1) Backend: Fossil-like model + efficient syncing

• Fossil’s data model is seen as much more efficient than Git (patch-based, simpler model).
• A prototype approach shows strong throughput (order-of-magnitude numbers cited in conversation, e.g., tens of thousands ops/sec in stress tests).
• Current pragmatic backend is SQLite-based, with potential future option to swap datastore while keeping high-level primitives.

2) UI + data representation: “files-first” and generated UI

• A key insight: TOML/structured files → UI generation can happen extremely fast (hours).

• This suggests future value shifts from “hand-building UIs/products” to:

  • standardizing schemas/data
  • ensuring security + integrity
  • generating UX on top

3) Standardization / automation: OpenRPC → auto CLI/client/tooling

• Work underway on macros that:

  • generate OpenRPC automatically
  • generate CLI and clients from OpenRPC
  • generate an MCP server layer as needed
    Goal: “one-liner” integration across components.

4) Agentic dev workflow: ACP (Goose) + editor integration

• ACP (Agent Control Protocol) discussed as a practical standard supported by Goose and endorsed by tooling ecosystem.
• Vision: run Goose instances per container/context, connect via editor (e.g., Zed), and dramatically increase coding speed.
• Near-term: use cloud models pragmatically (cost acceptable), optimize later.

5) Proposed pivot away from MCP sprawl: RaiScript + MQTT broker idea

A more radical idea being explored:

• Instead of registering/maintaining many MCP servers, use:

  • predefined RaiScript libraries per component
  • a message broker (MQTT) to route commands/events by topic/context
  • and potentially embed a RAI engine inside each component

• Benefits targeted:

  • reduce tool registration/management overhead
  • shorten “spec surface area” for AI (OpenRPC seen as too verbose for models)
  • enable secure “contextual execution” (agent says: “that node is slow, investigate”)

Two variants discussed:

• Embed RAI engine per component (cost: a few MB per component).
• Or keep OpenRPC on unix socket and build a RAI↔OpenRPC bridge component.

6) Decentralized coordination layer: Holochain (selective use)

• Holochain seen as promising for:

  • group/circle membership
  • discovery (“which repos exist where”)
  • DNS-like coordination

• Not a blanket “put everything on Holochain” approach: need practicality for enterprise adoption.

7) Security & encryption approach (later phase)

• First prototype may run without encryption.

• Later: tie group management to encryption using:

  • public key lists for group members
  • encrypted payload keys per recipient (or derived keys to limit blast radius)

• Acknowledged constraint: Holochain’s private data model needs careful handling; workaround is explicit encryption + key distribution.

Team / operating model notes

• Short-term execution is expected to focus on a small core (Speaker 1 + Speaker 2 + Timur mentioned), with others contributing where they’re already effective (e.g., keeping “grid” live).
• Speaker 2 is asked to manage Maxime’s output and keep him productive, with a goal to improve execution speed.

Immediate action items (next 1–2 weeks)

1. HeroForge POC

   • Keep backend simple initially (SQLite acceptable).

   • Confirm repo syncing path (peer-to-peer / circles).

   • Clarify the split between:

     • “UI metadata repo” (users/issues/etc.)
     • “code repos” imported/linked behind it

2. Holochain research tasks (Speaker 2)

   • Review CDN repository
   • Investigate Holochain/holobox key-value store functionality and how to use it reliably

3. Editor + agent workflow

   • Validate current stability of editor + cloud agent workflow (Zed/Cloud mentioned).
   • Explore “bypass permissions” mode to reduce confirmation prompts during execution.

4. RaiScript developer experience

   • Create a plugin/feature for RaiScript syntax highlighting in Markdown (DX improvement).
   • Start experiments: can an agent reliably consume and execute RaiScript instruction packs?

5. MCP server path (parallel track)

   • Port MCP server to Rust (if not already underway).
   • Add a “populate index/graph/RAG DB” command to ingest Forgejo/forge data for fast queries (“outdated issues”, etc.).

6. Cadence

   • Daily short sync between Speaker 1 and Speaker 2.
   • Speaker 2 to coordinate Maxime work and report progress/output (speed + deliverables).

Open questions / decisions needed

• Data model decision: which objects stay fixed globally (labels/milestones) vs per-repo/per-org?
• Sync strategy: Fossil-like patching + SQLite now, but what is the target abstraction to allow alternative datastores later?
• RAI vs OpenRPC: do we standardize on RaiScript-first control plane, or keep OpenRPC as the canonical interface and generate RaiScript adapters?
• Holochain scope: exactly what responsibilities go to Holochain vs remain local in repos/services?
• Security model: define “context boundaries” (what an agent can do where), and the minimal group/ACL primitives for v1.

Key takeaway

We’re moving toward a files/repo-centric, decentralized forge product (HeroForge) as the first tangible deliverable, built with Rust-first velocity, and designed to become agentic by default (ACP + scripted control plane). The goal is to ship a credible prototype quickly, then iterate toward decentralization, stronger security, and a scalable team operating model.

> is for our HeroRoadmap # Team Report — Product & Architecture Direction (meeting notes) ## Context * Current product is **not good enough** and incremental fixes to the existing architecture are considered **too slow**. * Team execution has been uneven: prior attempts to align via written “bluebooks/specs” did not produce deliverables, which is creating frustration and confusion about “the bigger picture”. * AI-driven development has changed the cost/benefit of approaches: tasks previously considered “big limits” may now be solved much faster, and **manual ops / manual scripting is becoming obsolete**. ## Core conclusions * We need a **new, simplified architecture** and a **first tangible product fast** (weeks, not months), otherwise momentum with new supporters/partners risks dropping. * “Just cloud / Kubernetes cloud” is not believed to be a strong enough use-case to fill capacity; we need an application-level product that creates pull-through for infrastructure. * Organizationally: there’s a push to **reduce manual work**, **reduce coordination overhead**, and **raise execution speed** (AI-assisted), while avoiding a scenario where most of the team becomes unproductive in an “AI world”. ## Product direction (low-hanging fruit) ### Candidate “first product” A **decentralized GitHub alternative** (code hosting + project management + CI/CD) with: * Lightweight data model (opinionated defaults, fewer moving parts than typical forge platforms). * Decentralization-first design, with eventual peer-to-peer sync and group-based access control. Working name mentioned: **HeroForge** (forge/repo UI + backend). ### Why this direction * A “forge” product is tangible, demoable, and can attract both internal morale and external partners. * It creates an immediate use-case for decentralized compute/storage fabric (and later “slices”, nodes, etc.). ## Architecture direction (what’s emerging) ### 1) Backend: Fossil-like model + efficient syncing * Fossil’s data model is seen as **much more efficient than Git** (patch-based, simpler model). * A prototype approach shows strong throughput (order-of-magnitude numbers cited in conversation, e.g., tens of thousands ops/sec in stress tests). * Current pragmatic backend is **SQLite-based**, with potential future option to swap datastore while keeping high-level primitives. ### 2) UI + data representation: “files-first” and generated UI * A key insight: **TOML/structured files → UI generation** can happen extremely fast (hours). * This suggests future value shifts from “hand-building UIs/products” to: * **standardizing schemas/data** * ensuring **security + integrity** * generating UX on top ### 3) Standardization / automation: OpenRPC → auto CLI/client/tooling * Work underway on macros that: * generate OpenRPC automatically * generate CLI and clients from OpenRPC * generate an MCP server layer as needed Goal: “one-liner” integration across components. ### 4) Agentic dev workflow: ACP (Goose) + editor integration * ACP (Agent Control Protocol) discussed as a practical standard supported by Goose and endorsed by tooling ecosystem. * Vision: run Goose instances per container/context, connect via editor (e.g., Zed), and dramatically increase coding speed. * Near-term: use cloud models pragmatically (cost acceptable), optimize later. ### 5) Proposed pivot away from MCP sprawl: RaiScript + MQTT broker idea A more radical idea being explored: * Instead of registering/maintaining many MCP servers, use: * **predefined RaiScript libraries per component** * a **message broker (MQTT)** to route commands/events by topic/context * and potentially embed a **RAI engine inside each component** * Benefits targeted: * reduce tool registration/management overhead * shorten “spec surface area” for AI (OpenRPC seen as too verbose for models) * enable secure “contextual execution” (agent says: “that node is slow, investigate”) Two variants discussed: * **Embed RAI engine per component** (cost: a few MB per component). * Or keep OpenRPC on unix socket and build a **RAI↔OpenRPC bridge** component. ### 6) Decentralized coordination layer: Holochain (selective use) * Holochain seen as promising for: * group/circle membership * discovery (“which repos exist where”) * DNS-like coordination * Not a blanket “put everything on Holochain” approach: need practicality for enterprise adoption. ### 7) Security & encryption approach (later phase) * First prototype may run **without encryption**. * Later: tie group management to encryption using: * public key lists for group members * encrypted payload keys per recipient (or derived keys to limit blast radius) * Acknowledged constraint: Holochain’s private data model needs careful handling; workaround is explicit encryption + key distribution. ## Team / operating model notes * Short-term execution is expected to focus on a **small core** (Speaker 1 + Speaker 2 + Timur mentioned), with others contributing where they’re already effective (e.g., keeping “grid” live). * Speaker 2 is asked to **manage Maxime’s output** and keep him productive, with a goal to improve execution speed. ## Immediate action items (next 1–2 weeks) 1. **HeroForge POC** * Keep backend simple initially (SQLite acceptable). * Confirm repo syncing path (peer-to-peer / circles). * Clarify the split between: * “UI metadata repo” (users/issues/etc.) * “code repos” imported/linked behind it 2. **Holochain research tasks (Speaker 2)** * Review **CDN repository** * Investigate Holochain/holobox **key-value store** functionality and how to use it reliably 3. **Editor + agent workflow** * Validate current stability of editor + cloud agent workflow (Zed/Cloud mentioned). * Explore “bypass permissions” mode to reduce confirmation prompts during execution. 4. **RaiScript developer experience** * Create a **plugin/feature for RaiScript syntax highlighting** in Markdown (DX improvement). * Start experiments: can an agent reliably consume and execute RaiScript instruction packs? 5. **MCP server path (parallel track)** * Port MCP server to **Rust** (if not already underway). * Add a “populate index/graph/RAG DB” command to ingest Forgejo/forge data for fast queries (“outdated issues”, etc.). 6. **Cadence** * Daily short sync between Speaker 1 and Speaker 2. * Speaker 2 to coordinate Maxime work and report progress/output (speed + deliverables). ## Open questions / decisions needed * **Data model decision**: which objects stay fixed globally (labels/milestones) vs per-repo/per-org? * **Sync strategy**: Fossil-like patching + SQLite now, but what is the target abstraction to allow alternative datastores later? * **RAI vs OpenRPC**: do we standardize on RaiScript-first control plane, or keep OpenRPC as the canonical interface and generate RaiScript adapters? * **Holochain scope**: exactly what responsibilities go to Holochain vs remain local in repos/services? * **Security model**: define “context boundaries” (what an agent can do where), and the minimal group/ACL primitives for v1. ## Key takeaway We’re moving toward a **files/repo-centric, decentralized forge product** (HeroForge) as the first tangible deliverable, built with **Rust-first velocity**, and designed to become **agentic by default** (ACP + scripted control plane). The goal is to ship a credible prototype quickly, then iterate toward decentralization, stronger security, and a scalable team operating model.

despiegk closed this issue 2025-12-17 12:07:52 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels   

urgent

No labels

urgent

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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_research/home_lhumina#3

No description provided.