Steven EnamakelandGitHub
afb95e72a5
* feat(event-bus): introduce typed request/response API for enhanced inter-module communication - Added a typed request/response surface to the existing event bus, allowing modules to execute requests through a shared controller registry. - Implemented `request_global` and `request_controller_global` functions for executing typed requests, enhancing the API's usability. - Updated documentation to reflect the new capabilities and usage patterns for the event bus, including when to use the request API versus traditional event publishing. - Added tests to validate the functionality of the new request/response features, ensuring robust integration with existing event bus operations. * refactor(event-bus): restructure event bus module and update references - Moved the event bus implementation from `src/openhuman/event_bus/` to `src/core/event_bus/`, establishing a clearer module hierarchy. - Updated all references throughout the codebase to reflect the new location of the event bus, ensuring consistency and reducing confusion. - Enhanced documentation to clarify the usage of the event bus and its core types, improving developer experience. - Introduced new files for event handling, requests, and subscribers, streamlining the event bus functionality and making it more modular. - Added tests to validate the new structure and ensure that the event bus operates correctly after the refactor. * refactor(event-bus): enhance event bus with native request/response surface - Updated the event bus to include a native, in-process typed request/response surface, allowing for zero serialization of Rust types and direct communication between modules. - Replaced the previous request API with a more streamlined approach using `register_native_global` and `request_native_global` functions. - Improved documentation to clarify the usage of the event bus, detailing when to use broadcast events versus native requests. - Removed the old request/response implementation to simplify the event bus structure and enhance maintainability. - Added examples and guidelines for registering and using native request handlers, improving developer experience and usability. * feat(agent): introduce native request handlers for agentic turns - Added a new `bus` module to encapsulate native event-bus handlers for the agent domain, including the `agent.run_turn` handler for executing agentic turns. - Updated the event bus registration process to include the new agent handlers, allowing for direct in-process request/response communication without serialization. - Refactored the channel message processing to dispatch agentic turns through the native bus, enhancing modularity and testability. - Improved documentation to clarify the usage of the new agent handlers and their integration with the event bus. - Added tests to validate the functionality of the new request handlers and ensure proper routing through the event bus. * refactor(tests): implement global bus handler lock for channel dispatch tests - Introduced a `use_real_agent_handler` function to manage the global bus handler lock during channel dispatch tests, ensuring exclusive access to the `agent.run_turn` handler. - Updated multiple test files to utilize the new handler function, improving test reliability by preventing race conditions during concurrent test execution. - Enhanced documentation to clarify the usage of the bus handler lock in tests that interact with the global native request registry. * feat(tests): add integration tests for Discord channel dispatch - Introduced a new test file `discord_integration.rs` to validate the end-to-end functionality of the Discord dispatch path within the channels module. - Implemented tests to ensure proper handling of inbound messages, reaction capabilities, and conversation history management specific to Discord. - Updated `mod.rs` to include the new Discord integration tests, enhancing overall test coverage for the channels module. * feat(tests): add Telegram integration tests for channel dispatch - Introduced new tests in `telegram_integration.rs` to validate the end-to-end functionality of the Telegram dispatch path within the channels module. - Implemented tests to ensure proper handling of threaded inbound messages, automatic acknowledgment reactions, and response routing through the agent bus handler. - Enhanced test coverage for Telegram, ensuring that the `supports_reactions()` capability is honored and that the dispatch pipeline operates correctly for both Telegram and Discord channels. * feat(tests): add testing utilities for event bus stubbing - Introduced a new `testing` module in the event bus to provide shared utilities for stubbing the global native bus registry. - Implemented `mock_bus_stub` and `MockBusGuard` to facilitate safe installation and restoration of stub handlers in tests, preventing race conditions. - Updated existing tests to utilize the new mocking utilities, enhancing test reliability and clarity in handling agent bus interactions. - Improved documentation to guide users on using the new testing features effectively. * style(event-bus): clean up formatting and remove unnecessary line breaks - Removed trailing whitespace and unnecessary line breaks in the event bus module files to improve code readability and maintainability. - Consolidated import statements and function definitions for a cleaner code structure across the event bus and agent modules. * fix(memory): point conversations/bus.rs at crate::core::event_bus Incoming `memory/conversations/bus.rs` from upstream/main still imports from the old `openhuman::event_bus` path. This branch relocated the bus to `core::event_bus`, so the merge left the import unresolved and the crate failed to compile. Rewire both references (`use` + fully-qualified `subscribe_global` call) to the canonical `crate::core::event_bus` path.
OpenHuman
The age of super intelligence is here. OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.
Discord • Reddit • X/Twitter • Docs
"The Tet. What a brilliant machine" — Morgan Freeman as he reminisces about alien superintelligence in the movie Oblivion
Early Beta — Under active development. Expect rough edges.
To install or get started, either download from the website over at tinyhumans.ai/openhuman or run
# For MacOS/Linux
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash
# For Windows
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex
What is OpenHuman?
OpenHuman is an open-source agentic assistant that is designed to integrate with you in your daily life. Here's what makes OpenHuman special:
-
Simple, UI-first — A clean desktop experience and short onboarding paths so you can go from install to a working agent in a few clicks, without a config-first setup. You don't need a terminal to run OpenHuman.
-
One subscription, many providers — You only need one account to get access to many agentic APIs (AI Models, Search, Webhooks/Tunnels and other 3rd party APIs etc..), simplifying the experience to get a powerful agent going.
-
Rich Skills — Plug into Gmail, Slack, Notion, and the rest of your stack via rich, feature-backed skills. Connections are typically one click through setup wizards instead of wiring APIs by hand. Workflow data is kept on device, encrypted locally, and treated as yours: encryption and sensitive context stay on your machine. Webhooks give instant feedback into the agent when external systems or skills emit events, so the loop stays tight without constant polling.
-
Local knowledge base — Built from your data and your activity. How you work across tools, sessions, and connected services—so the agent gets rich, workflow-aware context, not a one-off chat transcript. Everything is stored on your machine and compounding over time without becoming a cloud dossier. Channels, skills and ongoing conversations feed the same loop so day-to-day context does not reset every session.
-
Local AI model — The Rust core exposes local AI paths (and the desktop bundle can ship local/bundled runners where applicable) for the workloads above—vision snippets, speech helpers, summarization, tooling—so sensitive steps can stay off the cloud when you choose.
-
Deep desktop integrations — OpenHuman is a native desktop assistant, not a web-only chat: memory-aware keyboard autocomplete, voice (STT listening and TTS replies), screen intelligence that understands what is on screen and feeds your local context, plus windowing and OS-level permissions—so the agent meets you on the machine, not trapped in a browser tab.
Architecture: docs/ARCHITECTURE.md. Contributor orientation: CONTRIBUTING.md.
OpenHuman vs other agents
High-level comparison (products evolve—verify against each vendor). OpenHuman is built to minimize vendor sprawl, keep workflow knowledge on-device, and ship deep desktop features—not only chat.
| Claude Code/Cowork | OpenClaw | Hermes Agent | OpenHuman | |
|---|---|---|---|---|
| Open-source: Is the codebase open to review? | 🚫 Proprietary client | ✅ MIT License | ✅ MIT License | ✅ GNU License |
| Simple: Is it simple to get started? | ✅ Simple Desktop App + CLI | ⚠️ Terminal first and often complex | ⚠️ Terminal first and often complex | ✅ Simple, Clean UI/UX. Get started within minutes |
| Cost: How expensive is to run? | ⚠️ Subscription + add-on tool/API costs | ⚠️ Tied to models & hosting you choose | ⚠️ Tied to models & hosting you choose | ✅ Cost optimized with the option to run many things locally for free |
| Memory & Knowledge Base (KB): Does the agent know you and your world? | ✅ Built-in memory; mostly chat/session scoped | ⚠️ Has a local memory but often needs plugins for richer behavior | ✅ Self-learning / task loops (typical) | 🚀 Local KB + Self-learning from your activity & data (GMail, Notion etc... via skills) & prompts |
| API spagetti: How complex is it to hook mulitple features together? | 🚫 Claude bill + often extra keys for MCP/tools | 🚫 BYOK / multi-vendor common | 🚫 Multiple providers common | ✅ One account get access to many bundled platform APIs |
| Extensibility: Can you add rich features into it? | ✅ MCP (different model than sandboxed skills) | ✅ Plugin Architecture (SKILL.md) | ✅ Plugin Architecture (SKILL.md) | 🚀 Rich Skills with ability to have realtime updates, local DB & more |
| Desktop integrations: Can it integrate into your desktop completely? | ⚠️ Desktop app & access to folders | ⚠️ Often lighter native surface | ⚠️ Often lighter native surface | ✅ STT, TTS, screen intelligence, memory-aware autocomplete and a whole lot more |
Contributors Hall of Fame
Show some love and end up in the hall of fame