a36535330b feat: add typed event bus for cross-module decoupling (#374)
* Add event bus integration to channels module

- Introduced an `event_bus` module to facilitate event-driven communication within the channels.
- Updated `ChannelRuntimeContext` to include an `event_bus` field for managing events.
- Enhanced the `start_channels` function to initialize the global event bus and register a tracing subscriber for logging domain events.
- Modified the cron scheduler to publish delivery requests as events, decoupling the delivery logic from specific channel implementations.
- Updated tests to ensure proper initialization and usage of the event bus across various contexts.

This change improves the modularity and scalability of the channels system by leveraging an event-driven architecture.

* refactor: move CronDeliverySubscriber to cron/bus.rs

Each domain owns its event bus handlers — move the delivery subscriber
from channels/cron_delivery.rs into cron/bus.rs so the cron module
contains both its publisher and subscriber logic.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* chore: update Dockerfile to install system dependencies and refactor event bus logging

- Added installation of system dependencies (cmake, ALSA, X11) in the Dockerfile to support build requirements.
- Refactored event bus logging in various files for improved readability by consolidating multi-line log statements into single lines.

* chore: update Dockerfile to include webkit2gtk-driver installation

- Added installation of webkit2gtk-driver in the Dockerfile to support additional system dependencies.
- Removed redundant apt-get update command to streamline the installation process.

* docs: add event bus usage guide to CLAUDE.md

Documents the event bus pattern, core types, global access, and the
convention for adding domain events and subscribers so future modules
follow the established design.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* chore: update Dockerfile to streamline Node.js installation

- Removed redundant cleanup command after installing yarn in the Dockerfile, simplifying the installation process.

* chore: update Dockerfile to fix yarn installation command

- Removed unnecessary trailing whitespace in the yarn installation command in the Dockerfile, ensuring cleaner code and consistency.

* chore: consolidate system dependencies installation in Dockerfile

- Merged the installation of webkit2gtk-driver with other system dependencies in the Dockerfile to streamline the setup process and reduce the number of RUN commands.

* refactor: enforce EventBus as a singleton

- Make EventBus::create() pub(crate) — only tests can construct isolated
  instances; production code must use the global singleton
- Add subscribe_global() convenience for subscribing from any module
- Remove event_bus field from ChannelRuntimeContext — all modules use
  init_global/publish_global/subscribe_global instead of passing instances
- Update CLAUDE.md to document the singleton API as the only way to use
  the event bus

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* fix: address PR review — panic safety, init_global, Dockerfiles, tests

- Wrap handler.handle() in catch_unwind so a panicking subscriber does
  not silently kill its task — logs the panic and continues the loop
- Call init_global() in cron scheduler::run() so delivery events are not
  silently dropped when the scheduler starts before start_channels()
- Export DEFAULT_CAPACITY and use it everywhere instead of hard-coded 256
- Add ALSA/X11/input dev libraries to e2e/Dockerfile to mirror CI runner
- Remove duplicate cmake install from .github/Dockerfile
- Add 4 unit tests for CronDeliverySubscriber (ignore non-delivery,
  dispatch to channel, missing channel, send failure)
- Replace scheduler announce-mode test with one that verifies event
  payload is actually received by a subscriber

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-06 14:16:27 -07:00
2026-03-26 17:04:46 -07:00
2026-02-20 13:03:15 +04:00
2026-02-20 13:03:15 +04:00

OpenHuman

The age of super intelligence is here. OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.

DiscordRedditX/TwitterDocs

Early Beta Platforms: desktop only Latest Release

The Tet

"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

OpenHuman contributors
S
Description
No description provided
Readme GPL-3.0
220 MiB
Languages
Rust 59.1%
TypeScript 37.9%
JavaScript 1.6%
Shell 1.2%
CSS 0.1%