Discussion: integration layer for traditional business systems

[WZhongyun]

Hi maintainers,

I’m evaluating a possible contribution direction: enabling traditional business systems to integrate with Bub in a more structured way.

Before writing code, I’d like to confirm whether this direction fits the project and what boundaries or placement would make the most sense.

Background and motivation

Bub already has solid human-facing and channel-facing workflows such as CLI, Telegram, and Discord, while emphasizing explicit command boundaries, traceable tape history, and anchor / handoff semantics for collaborative delivery.

If traditional business systems are to integrate with Bub, my assumption is that the right approach is not to expose Bub as a black-box chat endpoint, but to provide a machine-facing interface with clear boundaries that still preserves inspectability.

This could make it easier to support things like:

• submitting structured tasks or context into Bub
• retrieving task status, results, and failure evidence
• supporting asynchronous execution for longer workflows
• integrating AI capabilities into existing systems without bypassing the current routing / tape / handoff model

Initial idea

My current thought is to add a system-facing integration layer, for example:

• using gRPC as a typed system-to-system interface
• using WebSocket for real-time status, event delivery, or streaming output
• keeping idle as the runtime mode for background execution, scheduling, retries, or async progression

My current assumptions are:

• chat / message / grpc / websocket should all be treated as Bub input/output channels, not bypass paths around the existing model
• external requests should still flow through the current router / tape / handoff semantics
• long-running work should not block synchronous request handling
• any new interface should preserve Bub’s inspectable / handoff-friendly / repeatable properties

Questions I’d like to confirm first

1. Does this direction fit Bub’s current scope and evolution?
2. If this is in scope, would maintainers prefer it to live under channels/ or integrations/?
3. From the project’s perspective, would you prefer:
   • gRPC only
   • WebSocket only
   • both, with different responsibilities
4. For async execution and long-running progression, is it appropriate to reuse the existing idle mode?
5. Before I draft a design or open a PR, are there architectural constraints, non-goals, or maintenance concerns I should understand first?

Non-goals

To avoid misunderstanding, I am not aiming to make this:

• a generic remote command-execution entrypoint that bypasses Bub’s current interaction model
• a black-box API detached from tape / handoff / evidence semantics
• a large all-in-one integration layer trying to cover every traditional business system use case at once

If maintainers think this direction is a good fit, I’m happy to refine the design based on feedback and try to contribute a small, reviewable PR.

Thanks for reading. I’d first like to hear whether maintainers think this direction makes sense.

[frostming]

Thanks for the feedback. Overall, I think this perfectly fits the concept of a channel. All you need to do is create a subclass of Channel and install it into bub

A big refactor(0.3.0) has been landed to minimize the extension interface so you can easily create and ship your own Bub plugin!

Refer to https://bub.build/extension-guide/ for how to and also examples here: https://github.com/bubbuild/bub-contrib.

Therefore, we will not integrate this into the main project to keep it small.