Get bindly

[autodidaddict]

Experiment with the notion of potentially replacing our proprietary parJEEzy files with bindles.

Before we drop everything and convert to an entirely new standard, we should devote some spike time to seeing if we can represent what we need as a bindle. A bindle for a capability provider would have to:

• Hold a binary for each OS family and CPU architecture combination we support
• Hold a signed JWT containing the capability provider's credentials
• Provide some form of signature+hash on the bindle itself that we could use to validate that the bindle had not yet been tampered with.
  • If we could sign bindles with ed25519 keys, that would be magnificent since we currently use ed25519 keys for all signing throughout the wasmCloud ecosystem.

We should also potentially look into supporting bindle creation/examination/extraction for combining actors and a set of capability providers they rely upon as an application bundle (bindle).

cc/ @thomastaylor312 @brooksmtownsend

[autodidaddict]

Also worth mentioning here @thomastaylor312 @technosophos is that wasmCloud hosts use a system called annotations but it might as well be called features. When you use lattice to hold an auction to determine a host suitable to run your workload, you declare the list of mandatory features(annotations) that said host must have in order to launch the workload. If each parcel in a bindle comes with a set of enumerable features, there might be an opportunity to integrate/automate/generalize some of the workload scheduling we do.

We might convert our target-specific annotations to features by creating a target feature section:

[feature.target]
os = "linux"
arch = "x86_64"

I don't know if the root invoice of a bindle supports features, or if we could just use one of the arbitrary key-value pairs to set the signed JWT value .. or, to be determined, is to what extent could we extract the metadata from our JWT and store it separately in the bindle fields... what are the pros/cons there?

[thomastaylor312]

Invoices only have an arbitrary annotations field that we don't use for filtering. But the annotations could definitely be used to store the data you'd like. For a first go, that might be a good place to put the signed JWT value, but it might be worth extracting and storing in specific fields within annotations. Due to the varying types of things that may use this, I am not sure a JWT would be a standard field, but we can use annotations in all sorts of ways.

As for this

If each parcel in a bindle comes with a set of enumerable features, there might be an opportunity to integrate/automate/generalize some of the workload scheduling we do.

This is currently mostly supported in the way I think you want it to be. Each parcel can be member of a group and each parcel has a set of features that can be accessed

[brooksmtownsend]

This issue is getting out-of-date, and a more recent one was filed on the OTP repo https://github.com/wasmCloud/wasmcloud-otp/issues/242