[elezar]

Summary

Propose RFC 0022: move the desktop compute drivers (Docker, Podman, and later the microVM driver) to the ai-openshell/desktop repository. The move first requires running Docker and Podman as external driver processes launched by the gateway, which is Part A of the RFC; Part B covers the move and the core, desktop, and packages release flow.

Related Issue

Refs #5200. That issue stays open as the tracking issue for the whole migration; this PR only adds the RFC.

Builds on the repository layout proposed in RFC 0019 (#4426, #4425).

Changes

• Add rfc/0022-desktop-driver-migration/README.md.
• Part A defines a generic driver launcher, a versioned startup document, probe and preflight commands, and a small driver SDK carved out of openshell-core.
• Part B defines the move to ai-openshell/desktop, the git-tag SDK dependency, conformance, and a packages bundle release.
• Leave maintainers, hotfix numbering, telemetry categories, binary trust, and the RFC 0019 cross-link as open questions.

Release Notes

Testing

• Checks appropriate to the affected code and behavior pass (markdown:lint including Mermaid validation, markdown:format, and license:check)
• Unit tests added/updated (if applicable)
• E2E tests added/updated (if applicable)

RFC-only change; Rust, SDK, and e2e suites are not applicable.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[johntmyers]

@matthewgrossman @elezar #4848 would be part of this too right?

[elezar]

@matthewgrossman @elezar #4848 would be part of this too right?

The move to a separate repo would demonstrate how a driver / project in another repo would consume the conformance tests. Since we have #5138 to add a single binary, this will be consumed by the desktop repo to validate the drivers.

[elezar]

Yes. I've updated the RFC (11198f9) to cover this. B3 now describes conformance as the openshell-conformance program from #5138, shipped as a release artifact that desktop runs unfiltered against its own gateway, pinned to the same core tag as the SDK. desktop is its first external consumer. #4848 tracks making it usable by any external driver, so this RFC depends on it but doesn't own it. I also added a risk noting that publishing the program is still outstanding. Phase 6 treats that as a prerequisite.

[drew]

We've already proposed moving desktop driver to their own repo as part of RFC 0019. Can we roll this into RFC 0019 or a ticket?

Feel free to push a new desktop specific plan to the RFC if you'd like though I would just put this into a ticket or series of tickets since we don't need much of a decision here. If I understand correctly the only net new thing we are asking for is a small service launcher pattern.

[elezar]

We've already proposed moving desktop driver to their own repo as part of RFC 0019. Can we roll this into RFC 0019 or a ticket?

Feel free to push a new desktop specific plan to the RFC if you'd like though I would just put this into a ticket or series of tickets since we don't need much of a decision here. If I understand correctly the only net new thing we are asking for is a small service launcher pattern.

I may have been erring on the side of getting feedback for this, and was concerned that an RFC was too heavyweight for this. In terms of "net new things", I don't quite agree that it's only a small service launcher pattern. The decisions that need review may not be called out clearly enough in the RFC and I will fix that. These are:

• Dependency rule: core never depends on desktop. desktop takes a git-tagged driver SDK from core, which needs a deny.toml exception because we forbid git dependencies today.
• Driver SDK: modules move out of openshell-core into a new crate, with core re-exporting them.
• Contract: two new capability fields who's logic currently exists in-process factory, a versioned startup document, and refusing a driver on protocol or schema mismatch.
• Release model: one bundle version in packages that pairs a core release with a desktop release, gated by the install canary, and who owns breakage when one side changes.

I can start on the more mechanical changes as issues and get working on them -- blocking on the decisions that are required -- and update the existing RFC with a desktop-specific plan instead of a new RFC.

Update: I have updated #5200 with a set of issues for the more mechanical steps. These should cover "Secion A" from this RFC. I will migrate the other content to the existing RFC.