RFC: Hosted feeds for plugins and skills by giodl73-repo · Pull Request #19 · openclaw/rfcs

giodl73-repo · 2026-06-18T02:40:44Z

Summary

Draft RFC for hosted feeds as the OpenClaw plugin and skill registry primitive.

This is a rewrite of the older feeds direction based on the June 17 OpenClaw discussion. It is plugin-first, anchored on the existing external plugin catalog, and leaves room for skills after the hosted plugin feed path is stable.

What it covers

Hosted JSON feed plus bundled fallback
Existing OpenClaw external plugin catalog entry points
npm-backed package install metadata and integrity checks
ETag, Last-Modified, and locally computed feed payload checksum persistence
Signed feed envelopes and optional signing-key trust envelope
ClawHub as the default public feed source
Enterprise feed composition, including the Microsoft/MOS3 tenant model
Regional feeds and mirrors
Feed governance versus runtime policy boundaries
Rollout plan and unresolved questions

Requested review

ClawHub maintainers: please supplement or correct the ClawHub publishing, trust, review, private/team feed, and regional mirror details.

OpenClaw plugin/onboarding maintainers: please sanity-check the hosted-feed fallback and manifest refactor direction against the current plugin catalog and onboarding install path.

Validation

git diff --check origin/main...HEAD
checked for em dashes
manual review pass accepted one fix: made feed payload checksum semantics explicit so the checksum is not self-referential

clawsweeper · 2026-06-21T00:17:53Z

Codex review: needs real behavior proof before merge. Reviewed June 22, 2026, 4:19 PM ET / 20:19 UTC.

Summary
Adds a 607-line Markdown RFC proposing hosted JSON feeds for OpenClaw plugins and skills, including source profiles, signed feeds, bundled fallback, enterprise composition, regional variants, and a staged rollout.

Reproducibility: not applicable. this is a design RFC for a new hosted feed model, not a current behavior bug. The concrete checks are the proposed Markdown file, README lifecycle rules, and the open RFC numbering state.

Review metrics: 2 noteworthy metrics.

RFC surface: 1 added Markdown file, 607 added lines. The review surface is a design proposal, so merge readiness depends on RFC process and maintainer direction rather than runtime checks.
Open 0009 candidates: 5 open PRs add 0009 RFC files. Maintainers need a queue-number decision before more than one proposal lands in the same RFC slot.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🌊 off-meta tidepool
Patch quality: 🦐 gold shrimp
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Get a maintainer-assigned unique RFC number or explicit 0009 reservation.
[P2] If accepted, update status, issue, and discussion-thread metadata before merge.

Risk before merge

[P1] Merging as-is would reserve the 0009 slot while several other open RFC PRs also add 0009 files, creating ambiguous RFC numbering if more than one lands.
[P1] The RFC remains in draft status with a blank implementation issue, while the README says draft RFCs should not merge until accepted and linked to implementation work.
[P1] The proposal sets future catalog, source-profile, signing, enterprise, regional, and skill-install direction, so maintainers need to explicitly own the product and security direction before acceptance.

Maintainer options:

Complete RFC Acceptance Gate (recommended)
Before merge, maintainers should decide whether to accept the hosted-feed direction, then update status, implementation issue metadata, and discussion-thread evidence accordingly.
Assign Or Reserve The RFC Number
Maintainers can either reserve 0009 for this PR and renumber the other open 0009 candidates, or give this RFC a different unused number before merge.
Keep Draft While Direction Settles
If the product/security model is not ready, leave the PR open as the discussion artifact rather than merging a premature registry contract.

Next step before merge

[P1] Maintainers need to decide product/security acceptance and RFC queue numbering; there is no safe automated repair to queue.

Security
Cleared: The diff is Markdown RFC text only and introduces no executable code, dependency, workflow, credential handling, or supply-chain execution path.

Review findings

[P2] Assign a non-conflicting RFC number — rfcs/0009-hosted-feeds-for-plugins-and-skills.md:1
[P2] Move out of draft before merge — rfcs/0009-hosted-feeds-for-plugins-and-skills.md:9

Review details

Best possible solution:

Keep the RFC open as a draft, have maintainers decide whether hosted feeds should be sponsored, assign or reserve a non-conflicting RFC number, and update acceptance metadata only if the direction is accepted.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a design RFC for a new hosted feed model, not a current behavior bug. The concrete checks are the proposed Markdown file, README lifecycle rules, and the open RFC numbering state.

Is this the best way to solve the issue?

Unclear as-is: an RFC is the right vehicle and the latest revision addresses many review themes, but merge still needs maintainer acceptance, a unique RFC number, and accepted lifecycle metadata.

Full review comments:

[P2] Assign a non-conflicting RFC number — rfcs/0009-hosted-feeds-for-plugins-and-skills.md:1
This file reserves the 0009 slot while other open PRs also add 0009 RFC files, including RFC 0009: Gmail Pub/Sub pull delivery #8, docs: add Agent Profiles RFC #18, RFC: multi-slot memory role architecture #22, and RFC 0009: Iroh Gateway transport #23. More than one merge would create duplicate RFC IDs, so this needs an unused maintainer-assigned number or an explicit 0009 reservation before merge.
Confidence: 0.93
[P2] Move out of draft before merge — rfcs/0009-hosted-feeds-for-plugins-and-skills.md:9
The repository README says draft RFCs should not merge, and this RFC still has status: draft with no implementation issue. If maintainers accept the proposal, update the lifecycle metadata before landing it.
Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against bab3348050f7.

Label changes

Label justifications:

P3: This is a low-risk design RFC with no runtime code change, but it still needs normal RFC acceptance before merge.
merge-risk: 🚨 other: Merging before RFC acceptance and number coordination could create process drift and duplicate RFC IDs rather than a runtime regression.
rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This is an RFC-only documentation change in the RFC repository, so there is no after-fix runtime behavior to prove before merge.

Evidence reviewed

What I checked:

Target AGENTS.md check: No AGENTS.md exists inside the openclaw/rfcs git root, so no target repository policy file applied to this review. (bab3348050f7)
Draft RFC added: The proposed file is a new hosted-feeds RFC and its frontmatter still says status: draft with no implementation issue filled in. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:9, 56577f97b2ad)
RFC lifecycle policy: README.md says new RFCs should not merge while draft, need a maintainer-discussion thread, and should only move to accepted with an implementation issue before merge. (README.md:80, bab3348050f7)
Lifecycle provenance: Blame ties the current RFC lifecycle rules to commit e366ea9, which added the draft/accepted merge process now on main. (README.md:80, e366ea9825a4)
RFC number collision: GitHub currently shows five open PRs adding 0009 RFC files, including this PR and RFC 0009: Gmail Pub/Sub pull delivery #8, docs: add Agent Profiles RFC #18, RFC: multi-slot memory role architecture #22, and RFC 0009: Iroh Gateway transport #23.
Prior feeds history: The older feeds RFC was introduced and revised on main, then deleted in e7555fd immediately before this rewrite; current main has not accepted this hosted-feed design. (rfcs/0006-feeds.md, e7555fdda445)

Likely related people:

giodl73-repo: Main history shows Gio introduced, revised, and renumbered the earlier feeds RFC that this PR rewrites. (role: prior feeds RFC contributor; confidence: high; commits: 1cd9e911af24, 5c6170bdb35d, 2d0e47f03c1d; files: rfcs/0004-feeds.md, rfcs/0006-feeds.md, rfcs/0009-hosted-feeds-for-plugins-and-skills.md)
Patrick-Erichsen: Patrick deleted the previous feeds RFC on main and left the detailed review themes that shaped the latest RFC revision. (role: recent area contributor and reviewer; confidence: medium; commits: e7555fdda445; files: rfcs/0006-feeds.md, rfcs/0009-hosted-feeds-for-plugins-and-skills.md)
kevinlin-openai: Blame and log history tie the current RFC lifecycle and metadata rules to Kevin's README and template updates. (role: RFC process contributor; confidence: high; commits: e366ea9825a4, f4fdf38f4717, bbb4058da234; files: README.md, rfcs/0000-template.md)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Patrick-Erichsen

Left some comments.

Patrick-Erichsen · 2026-06-19T22:38:44Z

+## Summary
+
+Define a hosted feed model for OpenClaw plugins and skills. A feed is a JSON
+catalog document that describes available packages, named local package sources,


Could you clarify what a , named local package sources is?

Patrick-Erichsen · 2026-06-19T22:41:47Z

+uses. External plugins can continue to install from npm or ClawHub, with Git
+available for immutable source installs. The feed provides package selection,
+version, and checksum data; local configuration supplies the source endpoint,
+credentials, and trust policy. ClawHub can publish the default public feed.


Eventually this should be only official packages, but for now, everything.

Patrick-Erichsen · 2026-06-19T22:50:38Z

+marketplace experiences. A feed is fetched from an HTTP endpoint or loaded from a
+local file. The client validates the document shape, verifies a configured
+signature policy when present, and uses entry-level package metadata to drive
+search, recommendation, install, update notices, and feed-level allow/block


I'm not certain about the search piece. I think we want to preserve ClawHub's ability to own it's search algo.

Perhaps ClawHub (or any registry) supplies the results, but the client is responsible for filtering out results based on the feed?

For example, if I search "Microsoft", ClawHub determines the right set of packages to return as results, but then OpenClaw client verifies that all of the results are present in at least a single feed.

Patrick-Erichsen · 2026-06-19T22:54:54Z

+  "entries": [
+    {
+      "type": "plugin",
+      "id": "acpx",


Would this be the slug? Slugs are not necessarily stable, a user can alter them.

What happens in that case? All users are unable to install that plugin until a new feed document is generated? Is that acceptable if so?

Patrick-Erichsen · 2026-06-19T22:55:55Z

+
+A feed document should be a deterministic JSON document with a schema version,
+feed id, generated timestamp, monotonic sequence number, expiry, and entries.
+Entry ids must be stable. Entries select a configured local source by name rather


Entries select a configured local source by name rather than embedding a registry domain, credentials, or trust roots.

Could you explain this more?

Patrick-Erichsen · 2026-06-19T23:43:56Z

+  a combination?
+- What user-facing noun should OpenClaw use: feed, marketplace, registry, or
+  another term?
+- Should a signed public feed be required from the first release, or should


I think signed first? Not sure tbh.

Patrick-Erichsen · 2026-06-19T23:44:22Z

+  another term?
+- Should a signed public feed be required from the first release, or should
+  unsigned HTTPS feeds remain an explicit opt-in for self-hosted deployments?
+- When should the optional trust envelope be introduced, and do public feeds need


What is the "optional trust envelope"?

Also not sure what the "offline root key" is.

Patrick-Erichsen · 2026-06-19T23:45:02Z

+  unsigned HTTPS feeds remain an explicit opt-in for self-hosted deployments?
+- When should the optional trust envelope be introduced, and do public feeds need
+  separate offline root keys from online publisher keys from day one?
+- Which runtime policy metadata should feed entries be allowed to reference


Don't understand.

Patrick-Erichsen · 2026-06-19T23:45:19Z

+  separate offline root keys from online publisher keys from day one?
+- Which runtime policy metadata should feed entries be allowed to reference
+  without turning the feed into a policy engine?
+- How many stable OpenClaw releases should ship hosted feed fallback before


This feels like a question for @kevinslin , maybe once we have our first LTS?

Patrick-Erichsen · 2026-06-19T23:45:47Z

+  without turning the feed into a policy engine?
+- How many stable OpenClaw releases should ship hosted feed fallback before
+  Scout, Microsoft, and other clients depend on the contract?
+- How should ClawHub represent trusted, verified, official, and reviewed


This is just a binary "Official" or not. We don't have any other labels for publishers.

giodl73-repo · 2026-06-22T20:16:17Z

Updated the RFC to address the review themes from Patrick's comments:

clarified that sourceRef names a local package-source profile, not a feed-owned domain or credential
preserved ClawHub/registry ownership of search ranking, with clients filtering or annotating results against configured feeds
clarified stable entry ids versus mutable display slugs
defined recommended, disabled, and blocked more concretely, including deterministic composition precedence
moved regional behavior toward separate edge-cached feed variants instead of requiring clients to evaluate a per-entry regions policy
added skill caveats for GitHub-indexed skills that may not have versions or ClawHub-hosted artifacts
simplified signing language around directly configured keys first, with key rotation as a later signed document if needed
updated rollout to put RFC alignment first, signed public feeds before the hosted public feed, and small draft PRs as the implementation path

I also removed the regions field from the sample feed entry so the example matches the revised regional model.

giodl73-repo force-pushed the feeds-plugin-registry-rfc branch 3 times, most recently from b866392 to 3db25b9 Compare June 18, 2026 02:51

docs(rfc): draft hosted feeds for plugins and skills

5812835

giodl73-repo force-pushed the feeds-plugin-registry-rfc branch from 3db25b9 to 5812835 Compare June 18, 2026 03:19

docs(rfc): define catalog source trust

4399109

clawsweeper Bot mentioned this pull request Jun 20, 2026

RFC 0009: Iroh Gateway transport #23

Draft

docs(rfc): clarify feed payload checksums

da91683

Patrick-Erichsen reviewed Jun 22, 2026

View reviewed changes

docs(rfc): address hosted feed review comments

56577f9

giodl73-repo merged commit 89cf322 into openclaw:main Jun 23, 2026

clawsweeper Bot mentioned this pull request Jun 23, 2026

RFC 0009 addendum: Feed observability and usage telemetry #24

Open

vincentkoc mentioned this pull request Jun 23, 2026

feat(catalog): publish hosted OpenClaw plugin feed openclaw/clawhub#2805

Merged

This was referenced Jun 24, 2026

docs: add Agent Profiles RFC #18

Draft

RFC: multi-slot memory role architecture #22

Open

Uh oh!

Conversation

giodl73-repo commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What it covers

Requested review

Validation

Uh oh!

clawsweeper Bot commented Jun 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Patrick-Erichsen left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

giodl73-repo commented Jun 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

giodl73-repo commented Jun 18, 2026 •

edited

Loading

clawsweeper Bot commented Jun 21, 2026 •

edited

Loading

Patrick-Erichsen left a comment •

edited

Loading