Skip to main content

WASM Extension System — Next Steps

ARCHIVE — This document is historical reference only. It may contain outdated information. See docs/status.md for current project state.

Date: 2026-02-16 Phase: 3l — Extensibility & Partnerships Status: Research Complete, Implementation Pending

Decision Summary​

After comprehensive research (see full research doc) and mobile constraint analysis (updated 2026-02-20):

✅ Python Backend: wasmtime-py v41+ (superior security, 88% native, WASI 0.3 async) ✅ Tauri Rust (all platforms): wasmer 5.0+ with platform-adaptive backends:

  • Desktop/Android: Cranelift JIT (80-88% native)
  • iOS: Wasmi interpreter (50-60% native) — wasmtime JIT is prohibited by Apple on iOS ✅ Interface Standard: WebAssembly Component Model + WASI 0.3 (async, rich types) ✅ Distribution: OCI registry (GitHub Container Registry, versioned, signed) ✅ Security Model: Capability-based permissions + resource limits + code signing ✅ BaseMorphRuntime: WasmRuntime (wasmer), JSRuntime (webview JS), PythonRuntime (future)

Why wasmer for Tauri (not wasmtime)? iOS App Store Review Guidelines §2.5.2 prohibits JIT compilation. Wasmtime's JIT mode is rejected by Apple. Wasmer 5.0 provides pluggable backends — Cranelift JIT where available, Wasmi interpreter on iOS — via a single unified API with no platform branching.

Why WASM? Portability (same binary runs on Python + Rust), security (true sandboxing), performance (80-88% native on desktop), industry-proven (VS Code, Figma, Shopify, Cloudflare).

Implementation Roadmap (12 Weeks)​

Phase 1: Foundation (2 weeks)​

Goal: Core runtime infrastructure, WIT interface definition, basic host functions.

Tasks:

  1. Add dependencies

    • Python: pip install wasmtime==41.0.0
    • Rust: wasmer = { version = "5", features = ["cranelift", "wasmi"] } (single crate, all platforms)

  2. Create backend/extensions/ module

    • manager.py — ExtensionManager class (load, compile, cache, execute)
    • models.py — ExtensionConfig, ExtensionPermission, ResourceLimits
    • permissions.py — Permission checking logic
    • resource_limiter.py — ResourceLimiter implementation for Wasmtime
    • signing.py — Code signing/verification (RSA-PSS + SHA-256)
    • registry.py — OCI registry client (pull extensions)

  3. Create frontend/src-tauri/src/extensions/ module

    • wasm_runtime.rs — WasmRuntime (wasmer 5.0, platform-adaptive backend selection)
    • js_runtime.rs — JSRuntime for frontend canvas/UI integrations
    • permissions.rs — Permission checking
    • limiter.rs — Resource limiter

  4. Design WIT interface (wit/morphee-extension.wit)

    • Define http, vault, events, data interfaces
    • Define morphee-extension world (imports + exports)
    • Generate bindings: python -m wasmtime.bindgen (Python), wit-bindgen rust (Rust)

  5. Implement host functions

    • http::fetch — HTTP requests with permission checks (read vs write)
    • vault::get_secret / vault::set_secret — Vault access
    • events::emit — Event bus integration
    • data::create_task / data::get_task — Data access

  6. Create Rust SDK crate (sdk/morphee-sdk-rust/)

    • Auto-generated WIT bindings
    • Helper macros (export_extension!)
    • Examples (echo, hello-world)

Deliverables:

  • ExtensionManager can load + execute WASM modules
  • Basic host functions (http, vault, events) working
  • Example extension (echo.wasm) runs successfully
  • Rust SDK crate published (crates.io or GitHub registry)

Acceptance Criteria:

  • Load echo.wasm, call execute("echo", [("message", "hello")]), get "hello" back
  • HTTP permission check: extension without http:write cannot POST
  • Resource limit: extension exceeding memory limit traps gracefully
  • iOS: wasmer with Wasmi interpreter loads and executes echo.wasm without JIT (Apple-compliant)
  • Desktop/Android: wasmer with Cranelift JIT executes at 80-88% native speed

Phase 2: Security & Permissions (2 weeks)​

Goal: Production-grade security, permission enforcement, audit logging.

Tasks:

  1. Implement permission model

    • ExtensionPermission enum (10 permissions)
    • Permission checks in all host functions
    • User approval flow (backend endpoint + frontend dialog)

  2. Add resource limiters

    • Memory limit (enforce in ResourceLimiter)
    • CPU limit (fuel-based, Wasmtime consume_fuel)
    • Rate limiting (HTTP requests, event emissions)
    • Timeout (max execution time)

  3. Code signing infrastructure

    • Generate developer keypairs (openssl genrsa)
    • Sign extensions (RSA-PSS, SHA-256 hash)
    • Verify signatures before loading (reject unsigned extensions)
    • Revocation list (future: check against revoked keys)

  4. Audit logging

    • Log all extension actions (INFO level)
    • Include: extension_id, action, user_id, group_id, result, execution_time
    • Separate log file: logs/extensions.log
    • Query endpoint: /api/extensions/audit-log (admin only)

  5. Error handling

    • Trap handling (extension panics/exceeds limits)
    • Graceful degradation (extension failure doesn't crash app)
    • User-facing error messages (no stack traces)

Deliverables:

  • Permission system fully enforced
  • Resource limits prevent abuse (memory bombs, infinite loops)
  • All extensions must be signed with valid key
  • Audit log captures all extension activity

Acceptance Criteria:

  • Extension without http:write permission → PermissionDenied error
  • Extension allocating 500MB → trapped at 256MB limit
  • Unsigned extension → rejected with clear error message
  • All extension calls logged with timestamp, user, action, result

Phase 3: Distribution (1 week)​

Goal: OCI registry setup, manifest schema, CLI tooling.

Tasks:

  1. Set up GitHub Container Registry (GHCR)

    • Create ghcr.io/morphee/extensions namespace
    • Configure GitHub Actions for publishing
    • Document registry structure (versioning, tags)

  2. Define extension manifest schema

    • YAML format (see example in research doc)
    • Required fields: extension_id, version, schema_version, permissions, actions
    • Optional fields: metadata, resource_limits, config_schema
    • JSON Schema for validation

  3. Build CLI tool (morphee-cli)

    • morphee-cli package — Bundle extension + manifest into OCI image
    • morphee-cli sign — Sign extension with developer key
    • morphee-cli verify — Verify signature
    • morphee-cli publish — Push to OCI registry
    • morphee-cli pull — Download extension from registry

  4. Backend integration

    • /api/extensions/install — Pull from registry, verify signature, load
    • /api/extensions/list-available — Query registry for available extensions
    • /api/extensions/update — Check for updates, auto-update PATCH versions

Deliverables:

  • GHCR registry configured and accessible
  • morphee-cli tool builds, signs, and publishes extensions
  • Backend can pull extensions from registry
  • Manifest validation prevents malformed extensions

Acceptance Criteria:

  • Developer runs morphee-cli publish jira-extension.wasm → pushed to GHCR
  • User clicks "Install" in UI → backend pulls, verifies, loads extension
  • Invalid manifest → rejected with clear validation error
  • Update check finds new PATCH version, installs automatically

Phase 4: Developer Experience (2 weeks)​

Goal: Make it trivial for developers to build Morphee extensions.

Tasks:

  1. Rust SDK documentation

    • API reference (rustdoc)
    • Getting started guide
    • Best practices (error handling, performance, security)
    • Deployment guide (build, optimize, publish)

  2. Extension examples

    • echo — Minimal example (no external calls)
    • http-client — Demonstrates HTTP requests
    • vault-secrets — Demonstrates vault access
    • task-sync — Demonstrates data access (read/write tasks)
    • jira — Full-featured reference implementation

  3. TypeScript SDK (AssemblyScript support)

    • @morphee/sdk-ts npm package
    • Auto-generated bindings from WIT
    • TypeScript examples (mirror Rust examples)
    • Build tooling (asc wrapper)

  4. GitHub template repos

    • morphee-extension-template-rust
    • morphee-extension-template-ts
    • Includes: boilerplate, CI/CD, README, manifest

  5. Local testing tools

    • morphee-cli dev — Run extension locally against dev backend
    • Hot reload (watch for changes, rebuild, reload)
    • Debug logging (extension stdout/stderr → terminal)
    • Mock host functions (test without real backend)

  6. Developer portal (morphee.app/developers)

    • Extension registry browser
    • Documentation hub (API reference, guides, examples)
    • Developer onboarding (get API key, generate keypair, publish first extension)
    • Community showcase (featured extensions)

Deliverables:

  • Comprehensive Rust SDK docs
  • 5 example extensions (echo, http, vault, tasks, jira)
  • TypeScript SDK (AssemblyScript) with examples
  • Template repos for quick start
  • Local dev tools (morphee-cli dev)
  • Developer portal live

Acceptance Criteria:

  • New developer: clone template, edit lib.rs, run morphee-cli dev, see extension working in <30 min
  • TypeScript developer: same experience with AssemblyScript
  • All examples build, run, and demonstrate best practices
  • Developer portal: browse extensions, read docs, publish extension

Phase 5: Built-in Extensions (3 weeks)​

Goal: Migrate existing integrations to WASM, build new ones as reference implementations.

Tasks:

  1. JIRA integration (Week 1)

    • Migrate from Python JiraIntegration to WASM
    • Actions: create_issue, get_issue, update_issue, list_issues, search_issues
    • Config: JIRA URL, API token (vault)
    • Permissions: http:read, http:write, vault:read, data:write
    • Publish to GHCR as ghcr.io/morphee/extensions/jira:1.0.0

  2. GitHub integration (Week 2)

    • Actions: create_issue, create_pr, list_repos, get_pr, merge_pr
    • OAuth flow (GitHub App)
    • Permissions: http:read, http:write, vault:read, data:write, event:emit
    • Publish to GHCR as ghcr.io/morphee/extensions/github:1.0.0

  3. Notion integration (Week 2)

    • Actions: create_page, update_page, query_database, create_database
    • OAuth flow (Notion integration)
    • Permissions: http:read, http:write, vault:read
    • Publish to GHCR as ghcr.io/morphee/extensions/notion:1.0.0

  4. Linear integration (Week 3)

    • Actions: create_issue, update_issue, list_teams, create_project
    • API key auth
    • Permissions: http:read, http:write, vault:read, data:write
    • Publish to GHCR as ghcr.io/morphee/extensions/linear:1.0.0

  5. Slack (migrate from Python) (Week 3)

    • Migrate existing SlackIntegration to WASM
    • Actions: send_message, list_channels, read_messages
    • OAuth flow (Slack App)
    • Permissions: http:read, http:write, vault:read, event:listen, event:emit
    • Publish to GHCR as ghcr.io/morphee/extensions/slack:1.0.0

Deliverables:

  • 5 production-ready extensions (JIRA, GitHub, Notion, Linear, Slack)
  • All published to GHCR with signed binaries
  • Documentation for each (setup guide, action reference)
  • Migration guide (Python Integration → WASM Extension)

Acceptance Criteria:

  • User installs JIRA extension → creates issue from chat → issue appears in JIRA
  • GitHub extension: LLM creates PR → PR created on GitHub
  • Notion extension: create page → page appears in Notion workspace
  • Linear extension: sync tasks → Morphee task → Linear issue
  • Slack extension: send message → message appears in Slack channel

Phase 6: Marketplace (2 weeks)​

Goal: User-facing marketplace for discovering, installing, and managing extensions.

Tasks:

  1. Extension catalog UI

    • New settings tab: "Extensions"
    • List installed extensions (card grid)
    • Browse available extensions (query GHCR)
    • Search + filter (by category, permissions)
    • Extension detail page (description, permissions, actions, reviews)

  2. Installation flow

    • Click "Install" → backend pulls from GHCR
    • Permission approval dialog (list all requested permissions)
    • User must approve before installation completes
    • Post-install: configure extension (API keys, settings)
    • Confirmation: "JIRA extension installed successfully"

  3. Extension management

    • Uninstall extension (with confirmation)
    • Enable/disable extension (keep config, stop execution)
    • Update extension (manual or auto for PATCH versions)
    • View extension logs (audit log filtered by extension_id)
    • Revoke permissions (post-install, granular control)

  4. Extension settings UI

    • Per-extension config form (generated from config_schema)
    • Store config in database (encrypted)
    • Vault integration (API tokens stored securely)
    • Test connection button ("Test JIRA connection")

  5. Usage analytics

    • Track extension calls (count, execution time, errors)
    • Dashboard: "Most used extensions", "Extension performance"
    • Cost tracking (future: credit usage per extension)
    • Alerts: "JIRA extension failing (3 errors in last hour)"

  6. Auto-updates

    • Background check for updates (daily)
    • PATCH versions: auto-install (user notification after)
    • MINOR/MAJOR versions: prompt user to review changes
    • Rollback option (keep previous version, restore on failure)

Deliverables:

  • Full marketplace UI (browse, install, manage)
  • Permission approval flow
  • Extension settings (config + vault)
  • Usage analytics dashboard
  • Auto-update system

Acceptance Criteria:

  • User browses marketplace → finds JIRA extension → clicks "Install"
  • Permission dialog shows all requested permissions → user approves
  • Config form appears → user enters JIRA URL + API token → "Test connection" succeeds
  • Extension appears in "Installed Extensions" → can be disabled/uninstalled
  • Analytics: "JIRA extension called 47 times this week, avg 234ms"
  • Update notification: "JIRA 1.2.1 available (bug fixes)" → auto-install after 24h

Immediate Next Steps (This Week)​

  1. Create GitHub issue for Phase 3l (this research + roadmap)

    • Title: "Phase 3l: WebAssembly Extension System"
    • Body: Link to research docs, implementation roadmap
    • Labels: enhancement, phase-3l, wasm, extensibility
    • Assign to milestone: "Phase 3l — Extensibility"

  2. Set up project structure

    • Create backend/extensions/ directory
    • Create frontend/src-tauri/src/extensions/ directory
    • Create sdk/morphee-sdk-rust/ directory
    • Create wit/ directory for WIT definitions

  3. Spike: Minimal WASM execution (proof of concept)

    • Install wasmtime-py
    • Compile minimal Rust extension (print "hello")
    • Load and execute in Python
    • Verify: extension runs, prints output
    • Estimated time: 2-4 hours

  4. Design WIT interface (first draft)

    • Sketch out http, vault, events interfaces
    • Define morphee-extension world
    • Generate Python bindings
    • Review with team
    • Estimated time: 4-6 hours

  5. Create GHCR namespace

    • Create ghcr.io/morphee/extensions repository
    • Configure GitHub Actions for publishing
    • Test push/pull with dummy image
    • Document registry structure
    • Estimated time: 2-3 hours

Total Estimate for Immediate Next Steps: ~1 day

Success Metrics​

After Phase 1 (Foundation):

  • Load and execute WASM module (echo.wasm)
  • Host functions callable from WASM (http, vault, events)
  • Rust SDK compiles example extensions

After Phase 2 (Security):

  • Permission checks enforce access control
  • Resource limits prevent abuse (memory, CPU)
  • All extensions must be signed (verification working)

After Phase 3 (Distribution):

  • Extensions published to GHCR
  • morphee-cli can package, sign, publish extensions
  • Backend pulls and loads extensions from registry

After Phase 4 (Developer Experience):

  • New developer builds extension in <30 min
  • 5+ example extensions available
  • Developer portal live (docs + registry)

After Phase 5 (Built-in Extensions):

  • 5 production extensions (JIRA, GitHub, Notion, Linear, Slack)
  • All signed and published to GHCR
  • User can install and use extensions from chat

After Phase 6 (Marketplace):

  • Marketplace UI complete (browse, install, manage)
  • Auto-updates working (PATCH versions)
  • 10+ users have installed extensions
  • 0 security incidents related to extensions

Risks & Mitigations​

RiskImpactMitigation
WASM binary size too largeSlow downloads, high storagewasm-opt -Oz (60% reduction), gzip transport (80KB typical)
Performance overheadSlow extension executionCache compiled modules (<1ms instantiation), AOT compilation
Security vulnerabilitiesExtension escapes sandboxRigorous permission checks, resource limits, code signing, audit logs
Poor developer experienceLow adoptionComprehensive docs, templates, examples, local dev tools
OCI registry downtimeCannot install extensionsCache extensions locally, fallback registry
Breaking changes in WasmtimeExtensions break on updatePin Wasmtime version, test upgrades in staging

Questions to Answer​

  • Should we support multiple versions of an extension installed simultaneously? (e.g., JIRA 1.x and 2.x)
  • How do we handle extension compatibility with Morphee versions? (min_host_version in manifest?)
  • Should extensions be able to call other extensions? (inter-extension communication)
  • How do we handle extension updates that require re-approval of permissions?
  • What's the policy for revoking/banning malicious extensions?
  • Should we build a review process for public extensions? (like Chrome Web Store)
  • How do we handle paid extensions? (licensing, DRM, revenue sharing)

References​