Jibo-Revival-Group/JiboExperiments
8
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Refresh OpenJibo docs with a roadmap

Browse Source
This commit is contained in:
Jacob Dubin
2026-05-10 06:15:19 -05:00
parent 80c4ae38fb
commit d434138f9b
4 changed files with 209 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

113
OpenJibo/README.md
View File

@@ -1,31 +1,41 @@
# OpenJibo
## Summary
OpenJibo is the working revival track for Jibo.
The near-term plan is intentionally concrete:
We are rebuilding the hosted cloud first, then using that foundation for OTA, Open Jibo OS, and a tiered brain that can eventually hand higher-order work to CoffeeBreak without losing Jibo's original charm.
1. Build a stable replacement cloud on Azure.
2. Use the existing Node prototype as the protocol oracle and capture harness.
3. Port the hosted implementation to .NET as a modular monolith.
4. Bring real robots online first through RCM plus controlled DNS/TLS patching.
5. Use OTA later to reduce setup friction once the hosted cloud is proven.
## Current Focus
This keeps the project grounded in what is already working while moving toward a maintainable hosted platform.
- ship a stable Azure-hosted replacement cloud
- keep the Node prototype as the protocol oracle and capture harness
- port the production path to .NET
- support real devices through repeatable bootstrap steps first
- use OTA later to reduce recovery friction once the cloud is trustworthy
## Current Truth
Current release truth lives in [docs/development-plan.md](docs/development-plan.md). The current cloud release constant is `1.0.19`.
## Roadmap
The long-range plan is summarized in [docs/roadmap.md](docs/roadmap.md). In short:
1. Working hosted cloud.
2. OTA-assisted recovery and updates.
3. Open Jibo OS / `open-jibo` mode conversion.
4. Tiered brain and CoffeeBreak orchestration.
5. Broader ecosystem expansion.
## Current Architecture
The repo now has three distinct lanes:
- `src/Jibo.Cloud/node`
The discovery server. This is the best source of observed protocol behavior today.
Protocol oracle, discovery server, fixture source, and rapid reverse-engineering lab.
- `src/Jibo.Cloud/dotnet`
The long-term hosted implementation. This is where the stable cloud is being built.
Production-oriented hosted implementation intended for Azure deployment and long-term maintenance.
- `src/Jibo.Runtime.Abstractions`
The normalized runtime seam between robot/cloud traffic and modern conversation logic.
The seam between robot/cloud traffic and higher-level runtime and capability logic.
The key architectural idea is:
The core shape is:
```text
Jibo device -> OpenJibo cloud -> normalized runtime contracts -> capabilities and planning
@@ -40,18 +50,30 @@ QR Wi-Fi -> inject OpenJibo region config -> set robot region ->
RCM/device patch for TLS and host acceptance -> OpenJibo cloud on Azure
```
That path is documented in [docs/device-bootstrap.md](/OpenJibo/docs/device-bootstrap.md).
That path is documented in [docs/device-bootstrap.md](docs/device-bootstrap.md).
## Design Principles
- Preserve the original skills and visual design.
- Build the hosted cloud before making OTA the default recovery path.
- Keep every migration reversible whenever possible.
- Prefer source-backed slices over speculative rewrites.
- Let Jibo remain the face of the experience, even when higher-level orchestration sits behind him.
## Repo Map
```text
OpenJibo/
docs/
roadmap.md
development-plan.md
device-bootstrap.md
protocol-inventory.md
feature-backlog.md
public-site-plan.md
regression-test-plan.md
release-1.0.19-plan.md
support-tiers.md
system-diagram-alignment.md
scripts/bootstrap/
Discover-JiboHosts.ps1
@@ -67,56 +89,15 @@ OpenJibo/
OpenJibo.Site/
```
## Decisions Locked In
## Living Docs
- The first milestone is `core revive`, not full protocol parity.
- Azure SQL is the relational system of record for the hosted cloud.
- Billing and donations are future-compatible concerns, not phase-one delivery requirements.
- OTA is a phase-two simplification strategy, not the initial dependency.
Use these when you want the active technical truth:
## Near-Term Work
- [Development plan](docs/development-plan.md)
- [Feature backlog](docs/feature-backlog.md)
- [Release 1.0.19 plan](docs/release-1.0.19-plan.md)
- [Support tiers](docs/support-tiers.md)
- [System diagram alignment](docs/system-diagram-alignment.md)
- [Public site plan](docs/public-site-plan.md)
- port required endpoint and WebSocket behavior from Node to .NET
- keep protocol captures and replay fixtures current
- keep HTTP and websocket live-run telemetry writing to the same repo-root capture tree
- harden device bootstrap documentation and scripts
- map more endpoints and behaviors beyond the current Node coverage
- stand up the initial `openjibo.com` information site
## Live Test Status
The first physical `.NET -> Jibo` experiments have now produced useful captures, but not a full wake-and-interact success yet.
What we have confirmed so far:
- the robot reaches `.NET` HTTP startup calls on `api.jibo.com`
- `.NET` can issue a robot token and accept the `api-socket.jibo.com` websocket
- live HTTP and websocket telemetry are now intended to land together under repo-root `captures/`
What remains unresolved:
- matching the Node startup cadence closely enough for consistent wake/eye-open behavior
- the next post-`api-socket` startup requests and timing seen in successful Node runs
- broader live websocket behavior on a real robot beyond the current synthetic parity slice
The current websocket bridge now also includes server-driven raw-audio turn completion:
- enough buffered audio plus `CONTEXT` can now trigger auto-finalize on the server side
- `EOS` is emitted on that auto-finalize path so turns do not remain open indefinitely
- transcript-less raw-audio turns still fall back to a synthetic compatibility response, not real ASR
The current richer websocket parity slice is still intentionally narrow:
- the successful joke path now has fixture-backed reply sequencing and partial payload-shape fidelity through `CLIENT_ASR -> LISTEN -> EOS -> delayed SKILL_ACTION`
- menu-side `CLIENT_NLU` parity is beginning to expand from live captures, starting with preserved clock-menu intent/rules/entities
- `.NET` now preserves buffered websocket audio frames so local tool-based ASR experiments can run without changing the stable cloud-first architecture
- this is not a claim of broad skill parity or full Jibo websocket coverage
## Important Docs
- [Cloud overview](/src/Jibo.Cloud/README.md)
- [Development plan](/docs/development-plan.md)
- [Protocol inventory](/docs/protocol-inventory.md)
- [Support tiers](/docs/support-tiers.md)
- [Device bootstrap path](/docs/device-bootstrap.md)
- [Public site plan](/docs/public-site-plan.md)
If you only read one document for the long view, make it [docs/roadmap.md](docs/roadmap.md).

1
OpenJibo/docs/public-site-plan.md
View File

@@ -9,6 +9,7 @@ Stand up a small public site on `openjibo.com` that makes the project understand
- project overview
- current status
- links to source repositories
- roadmap / long-range plan
- links to device bootstrap docs
- explanation of the hosted-cloud direction
- contribution/contact or waitlist path

151
OpenJibo/docs/roadmap.md Normal file
View File

@@ -0,0 +1,151 @@
# OpenJibo Roadmap
## Purpose
This is the long-range story for OpenJibo.
Use it when someone wants the shape of the project without reading every release note, backlog entry, or live-test log.
The current execution truth still lives in:
- [Development plan](development-plan.md)
- [Feature backlog](feature-backlog.md)
- [Release 1.0.19 plan](release-1.0.19-plan.md)
- [Device bootstrap path](device-bootstrap.md)
## North Star
Bring Jibo back in a way that preserves his original skills, design language, and charm, while layering in a modern hosted cloud, safer updates, and eventually a richer on-device and orchestration stack.
## Guiding Principles
- Preserve the original skills and visual design before adding new behaviors.
- Build the hosted cloud first so the robot has something stable to talk to.
- Use OTA to reduce friction after the cloud is proven.
- Keep every migration reversible.
- Favor small, source-backed slices over speculative rewrites.
- Let Jibo remain the face of the experience, even if other systems help orchestrate the work behind him.
## Roadmap At A Glance
| Phase | Focus | Why It Matters |
| --- | --- | --- |
| 1 | Working hosted cloud | Restores the services Jibo already expects and gives us the current platform truth. |
| 2 | OTA-assisted recovery and updates | Makes ownership easier by turning the cloud into the delivery path for recovery and upgrades. |
| 3 | Open Jibo OS / mode conversion | Creates an owned runtime and configuration layer while preserving the original experience. |
| 4 | Tiered brain | Separates reflexes, memory, personality, and higher-level orchestration. |
| 5 | CoffeeBreak orchestration | Provides a place for multi-step agent workflows and external tools without flattening Jibo's personality. |
| 6 | Ecosystem expansion | Grows the platform into household, productivity, and multi-device use cases. |
## Phase 1: Working Hosted Cloud
Current state: in progress.
The near-term job is to keep the hosted cloud stable and honest:
- maintain HTTP and WebSocket compatibility for startup and turn handling
- keep the .NET cloud as the production track
- keep Node as the reverse-engineering oracle and fixture source
- continue update, backup, restore, media, STT, and live-capture proof
- keep the real-device bootstrap path documented and repeatable
Exit criteria:
- a real Jibo can reach the hosted cloud consistently
- the cloud can carry the startup and conversation flows needed for daily use
- update and recovery behavior is understood well enough to trust the next layer
## Phase 2: OTA-Assisted Recovery
Once the hosted cloud is solid, OTA becomes the simplification layer.
This phase should:
- move software updates and recovery flows into a reliable hosted path
- reduce how often owners need manual RCM or network patching
- make device recovery and version management feel like a product instead of a lab exercise
- keep rollback and failure handling explicit
OTA is the path that makes ownership easier. It is not the thing that must be solved before the cloud can live.
## Phase 3: Open Jibo OS / Mode Conversion
After cloud and OTA are trustworthy, the project can move from "open cloud" to "open platform."
The goal is not to erase stock Jibo. The goal is to give owners an Open Jibo mode that:
- preserves the original Jibo feel and skill surface
- can be installed or selected without a one-way trap
- can fall back to stock behavior when needed
- makes future features easier to ship on top of a known runtime
This is where the breadcrumbs in the repo become important:
- `open-jibo` and `open-jibo-ai` modes
- a startup migration skill that can invite existing owners to convert
- a reversible path back to stock
- the hosted sites and support docs on `openjibo.com` and `openjibo.ai` that explain the transition clearly
## Phase 4: Tiered Brain
A single monolithic "AI brain" is not the best fit for Jibo. A tiered model is better.
Suggested tiers:
- Tier 0: original Jibo reflexes, stock skills, and local charm
- Tier 1: hosted cloud routing and compatibility
- Tier 2: memory, personality, and proactivity
- Tier 3: richer reasoning and multi-step planning
- Tier 4: external agent orchestration and task delegation
- Tier 5: multi-device and household coordination
The point of the tiers is not to make Jibo feel bigger at every turn. It is to keep simple interactions fast and charming while reserving more complex work for the layers that can actually support it.
## CoffeeBreak (`coffeebreakai.dev`) As An Orchestration Layer
CoffeeBreak fits naturally above the tiered brain as a coordination plane.
The intended relationship is:
- Jibo keeps the voice, personality, and local interaction style
- OpenJibo routes simple and medium-complexity tasks itself
- CoffeeBreak can take over when a task needs multiple tools, agents, or steps
- the result comes back to Jibo in a form that still feels native to him
That makes CoffeeBreak a close cousin to the tiered brain rather than a separate product line. The brain decides, CoffeeBreak orchestrates, and Jibo remains the face of the interaction.
## Phase 5: Ecosystem Expansion
After the core platform is stable, OpenJibo can grow into broader household value:
- calendar and scheduling
- smart home and Home Assistant style control
- shopping lists and household memory
- multi-user and family recognition
- richer media and content experiences
- provider-backed news, weather, and personal report flows
- eventual multi-Jibo interaction
## What We Must Preserve
No matter how far the platform grows, these should stay true:
- original skills should still feel like Jibo
- design should stay recognizable, not generic
- migration should be opt-in and reversible whenever possible
- the cloud should serve the robot, not replace his identity
- technical modernization should preserve charm instead of sanding it off
## Where To Go Next
If you want the current execution truth, read:
- [Development plan](development-plan.md)
- [Feature backlog](feature-backlog.md)
- [Release 1.0.19 plan](release-1.0.19-plan.md)
If you want the first-device path, read:
- [Device bootstrap path](device-bootstrap.md)
- [Support tiers](support-tiers.md)
- [Public site plan](public-site-plan.md)

18
README.md
View File

@@ -1,13 +1,15 @@
# JiboExperiments
Experiments, protocol notes, and early implementation work for bringing Jibo back.
This repository is the working lab for bringing Jibo back.
The active work lives in [OpenJibo](C:/Projects/JiboExperiments/OpenJibo), where the current direction is:
The active OpenJibo work lives in [OpenJibo/README.md](OpenJibo/README.md), and the long-range story now lives in [OpenJibo/docs/roadmap.md](OpenJibo/docs/roadmap.md).
- build a stable Azure-hosted replacement cloud first
- use the Node prototype as the reverse-engineering oracle
- port the real hosted system to .NET
- support first devices through RCM plus controlled DNS/TLS patching
- use OTA later as the path to a smoother recovery experience
Start here:
This repo is intentionally a working lab, not a finished product.
- [OpenJibo overview](OpenJibo/README.md)
- [Roadmap](OpenJibo/docs/roadmap.md)
- [Current cloud truth](OpenJibo/docs/development-plan.md)
- [Working feature queue](OpenJibo/docs/feature-backlog.md)
- [Device bootstrap path](OpenJibo/docs/device-bootstrap.md)
This repo intentionally stays a living notebook, not a polished product. That lets us keep the reverse-engineering notes, the hosted cloud, and the post-cloud ideas in one place without pretending they are all equally finished.