#E-Claw — Android AI Live-Wallpaper Channel Plugin

1 messages · Page 1 of 1 (latest)

iron houndBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

topaz flaxBOT
#

This looks like it fits OpenClaw’s channel plugin model really well (webhook-driven, similar shape to LINE / Nextcloud Talk), and the fact you’ve already shipped ~18 versions in the wild is a strong signal.

A few things maintainers usually care about before moving something from “community plugin + catalog entry” → “in-repo extension under extensions/”:

1) Support / ownership expectation

Being in the monorepo effectively means “this should keep working across core refactors + releases.”

  • Are you willing to be the long-term maintainer for breakages/regressions?
  • What’s the fallback if you get busy (bus factor)?

2) Security + hardening (most important for webhook channels)

Concrete checklist that tends to unblock reviews:

  • Request auth: signature/HMAC verification (and clear docs for users on how to set it up)
  • Replay protection / idempotency (event IDs, dedupe window)
  • Rate limiting / in-flight limiting (DoS safety)
  • Strict input validation (zod) + “reject unknown fields” style parsing
  • No reliance on postinstall/native deps (plugin installs use npm install --ignore-scripts)
#

3) “Looks like a first-party extension” ergonomics

If you do go for extensions/eclaw, match existing extensions (ex: extensions/line):

  • openclaw.plugin.json in the extension root
  • package.json with:
  • openclaw.extensions: ["./index.ts"]
  • openclaw.channel metadata (label, blurb, docsPath, aliases, etc.)
  • openclaw.install hints
  • A real docs page under docs/channels/eclaw.md (and linked from docs/channels/index.md)
  • Tests: at least for signature verification + message mapping (Vitest)

(Reference: the “Channel catalog metadata” section in the plugin docs: https://docs.openclaw.ai/tools/plugin)

4) Multi-entity / multi-agent mapping (E‑Claw-specific)

The “4–8 independent agent slots per device” part is awesome, but reviewers will want a clear mapping to OpenClaw concepts:

  • Does each slot map to an OpenClaw accountId under channels.eclaw.accounts.<id>?
  • How do you represent “device A slot 3” as a stable peer/group id for sending?
  • How do cross-device messages route (directory/resolver expectations)?