SPIKE: WRPC Plugin

[lxfontes]

Getting this up for discussion / ergonomics.

WRPC NATS Only, using the data NATS settings.
The WRPC Plugin looks for host_interfaces with config key wrpc:name,forwarding imports/exports for that particular 'namespace + package' to wrpc layer. The wrpc:name is used as part of the wrpc subject.

There is no process supervision or interactions with wasmcloud provider sdk.

WRPC Routing

We pivot identifiers from workload_namespace & workload_name to host_group & wrpc_name, resembling wasmcloud's v1 Lattice approach.

{host_group}.{wrpc_name}.[wrpc-lib-subject]

This happens for a few reasons:

• Guarantee no crosstalk across hostgroups
• wrpc_name has to remain stable across restart, and can't use Workload names here as they are ephemeral (would be nice to use WorkloadDeployment names)

Crosstalk can still be achieved via NATS subject mappings, however it is an advanced use-case.

Example:

All exported interfaces from wrpc-examples/hello found on the component will be served over WRPC.

     hostInterfaces:
        - namespace: wrpc-examples
          package: hello
          interfaces:
            - handler
          config:
            "wrpc:name": wasmcloudrpchello

Client:

rpc ❯ ./target/debug/hello-nats-client default.wasmcloudrpchello
2026-02-23T20:37:01.480694Z  INFO async_nats::connector: connected successfully server=4222 max_payload=1048576
2026-02-23T20:37:01.480974Z  INFO async_nats: event: connected
default.wasmcloudrpchello: hello from Rust

Identity ( WRPC Headers )

(still to be coded)

Headers help external WRPC endpoints identify the caller & multiplex interfaces:

• From: {wrpc_name} from the source
• X-Wasmcloud-Workload: {workload_namespace}/{workload_name}
• X-Wasmcloud-Workload-Id: {workload_id}

Also considering passing any additional Interface config as header.

Questions

How to handle different wrpc:name for import/export on the same package?

This is a limitation of host_interfaces. Today all import/exports land on the same WitInterface with a single configuration.

HostPlugin or not?

Seems weird to pluck a specific HostPlugin within wash_runtime::engine.

I feel this warrants another "engine-plugin" like HTTP.

Target Switching (Links)

v1 linking at runtime

Besides similar challenges with host_interfaces, we also have:

• Scope: WRPC-only links or for components/HostPlugins too?
• Link Switch Mechanism: v1 has dedicated WIT Interface for Link change

IMO: WRPC-Only with similar WIT Interface for Link change

[lxfontes]

Using the existing cron-service & cron-component combo:

# This will become a WRPC Server (nats subscription)
apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: WorkloadDeployment
metadata:
  name: cron-component
spec:
  replicas: 1
  template:
    spec:
      hostInterfaces:
        - namespace: wasmcloud
          package: example
          interfaces:
            - cron
          config:
            "wrpc:name": crontest
      components:
        - name: hello
          image: ttl.sh/lxfontes/cron-component:test
---
# This will become a WRPC Invoker
apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: WorkloadDeployment
metadata:
  name: cron-service
spec:
  replicas: 1
  template:
    spec:
      hostInterfaces:
        - namespace: wasmcloud
          package: example
          interfaces:
            - cron
          config:
            "wrpc:name": crontest
      service:
        image: ttl.sh/lxfontes/cron-service:test

[lxfontes]

moving to wasmcloud/wasmcloud