wasmCloud waSCC Community, 25 Feb 2021

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: wasmcloud: wash 101, the interactive cli and REPL for wasmcloud

Description

This community meeting features a demonstration of wash (WAsmcloud SHell) is a CLI (Command Line Interface) and REPL (Read, Evaluate, Print, Loop) to help you with the wasmcloud application lifecycle. This meeting features a walk-through of the lifecycle of creating, signing, storing, and running a wasmcloud payload.

The essential script for the demonstration may be found here:
https://github.com/brooksmtownsend/wash101

And the key commands executed in order are:
######################################
## Building and signing table tennis actor
cd ./actor-table-tennis
wash claims sign --help
wash claims sign ./target/wasm32-unknown-unknown/release/table_tennis.wasm --name "Table Tennis" --http_server
wash claims inspect ./target/wasm32-unknown-unknown/release/table_tennis_s.wasm
wash keys gen --help
TABLE_TENNIS_SUBJECT=$(wash keys gen module -o json | jq '.seed' | tr -d "\"")
wash claims sign ./target/wasm32-unknown-unknown/release/table_tennis.wasm --name "Table Tennis" --http_server --subject $TABLE_TENNIS_SUBJECT
wash claims inspect ./target/wasm32-unknown-unknown/release/table_tennis_s.wasm
wash keys list
make release
cp ./target/wasm32-unknown-unknown/release/table_tennis_s.wasm ../

## Building and signing httpserver provider
cd ../provider-http-server
cargo build --release
wash par create --help
# Be sure to change this arch and binary flag to your architecture and shared object
wash par create --arch x86_64-macos --binary ./target/release/libwasmcloud_httpserver.dylib --capid wasmcloud:httpserver --name "HTTP Server" --vendor "wash101 developer" --compress
wash keys list
wash par inspect ./libwasmcloud_httpserver.par.gz
cp ./libwasmcloud_httpserver.par.gz ../

## Pushing resources to local registry
cd ..
docker-compose up -d
wash reg push --help
wash reg push localhost:5000/tabletennis:0.1.0 ./table_tennis_s.wasm --insecure
wash reg push localhost:5000/httpserver:0.1.0 ./libwasmcloud_httpserver.par --insecure
wash reg pull localhost:5000/httpserver:0.1.0 --insecure
diff httpserver.par.gz ./libwasmcloud_httpserver.par.gz

## REPL (Actor and provider ids will differ due to autogenerated keys)
wash up
ctl get hosts
ctl get inventory HOST_ID
ctl start actor localhost:5000/tabletennis:0.1.0
ctl call ACTOR_ID HandleRequest {"method": "POST", "path": "/", "body": "ping", "queryString":"", "header":{}}
ctl call ACTOR_ID HandleRequest {"method": "POST", "path": "/", "body": "bling", "queryString":"", "header":{}}
ctl start provider localhost:5000/httpserver:0.1.0
ctl get inventory HOST_ID
ctl link ACTOR_ID PROVIDER_ID wasmcloud:httpserver PORT=8080

## Separate terminal
# Bad Request
curl localhost:8080 -v
# pong
curl localhost:8080 -d "ping"

## Cleanup
rm *.par.gz *.wasm
docker-compose down

#wash #code #programming #wasm #webassembly #development #IT #newcode #community #github #oss #opensource #career #software #browser

A

Okay, everyone. Thank you so much for coming to the wasmcloud february, 24th 2021 uh community meeting uh today, we've got a great book, uh great demonstration of the wash clea from brooks, uh so I'm gonna go ahead and turn it over to you brooks and again. This is watson cloud from sketch to scale in seconds.

B

Thanks liam yeah, I'm going to be showing you all a demo today that I like to call the wash 101 demo so showing you through what wash is, which is a bundle of command line tools that simplifies, wasn't cloud development, I'm going to dive into all the utilities that wasm or that wash has to offer by showing you what it looks like to build and sign an actor, a capability provider and then using the wash integrated repple.

B

To start your wasn't cloud development journey actually launch these things and get them running in a host. So that's the stage as a couple of prerequisites.

B

I've packaged this demo, all of these demo resources into a repository which I'll have liam link in the chat and in the video so that you can follow along later. If you'd like to give this a try. But what this essentially consists of, I have a single actor and a single provider, and I'm going to talk about how you get from having this code initially to actually having these resources running in a wasm cloud host by using wash to make the rest of the development cycle easy.

B

So to get started, the first thing we need to do here is build and sign our actor, so this actor is going to be a web assembly module a single stateless unit of compute, and it's going to be fairly simple. It's going to accept http requests, it's going to act as an http server and whenever it receives that request, if it gets a message body of ping, it's going to respond with pong, so I've aptly named this actor the table tennis actor.

B

So this is a the rust actor for wasmcloud. Most of this was scaffolded out beforehand. So it's very simple: I'm keeping the code simple today to focus on the commands so here in order to sign this actor, we use the claims command and the claims command is used to manage the claims. The additional information that we use to sign webassembly modules- and we do this signing because we'd like to have a certain level of verifiability for our wasmcloud actors.

B

Whenever we run them, we want to know where they came from from who science actor, what version? It is um what kind of capabilities it like to use. For example, here, like a webassembly module, can't make network request or receive network requests natively they need to do use wasmcloud capability providers.

B

In order to do that, so we use the signing process to declare that this actor needs an http server capability so to get started here we can use the integrated help text to get a better idea of what we're going to be looking at so to sign a webassembly module. There's a couple pieces of information we need. We need the actual webassembly module which we're calling source.

B

We need a name which is just a human readable name so that we can identify it any capabilities that's going to make use of, so our actor is fairly simple. We're going to make use of the http server capability, the wasm cloud one, and the last thing that we need are to actually sign this actor with sign-in keys. To keep this brief, we're using ed25519 keys, you don't actually need to care about the specifics of those keys.

B

We have more information on our architecture decision, log of why we chose to use them, but the two that you need to sign. An actor are the issuer key, which shows what this actor, who signed this actor. What entity signed this actor and the subject key, which is a unique key to identify the actor itself.

B

So the great thing about wash and using wash claims is in order to sign a webassembly module. You can directly manage these keys or you can allow wash to generate these for you, and so I'll show you these that in a minute.

B

So to start, I've already gone ahead and built this actor beforehand to save us, the cargo, the rust build time, but we can use claims to sign this actor, which I've compiled for release mode. Just the webassembly module, I'm going to name this actor brooks.

C

I think uh you're down at the bottom, so at least on my screen, I can't see the the bottom line that you're typing. Oh, you can type.

D

Clear and return brooks.

B

Boom thanks for uh thanks for pointing that out um I'll, keep that in mind for the rest of the stuff too. Okay, so we can. We can sign this webassembly module.

B

uh I've already compiled this, as I said, for release mode, I'm just going to name it table tennis and then the next piece of information that we need is the capability contract that the actor needs to function, which is http server, and you notice here, as I was mentioning we actually get to generate the wash, will generate these keys for you if you don't supply them, so an account key for myself and a module key for this actor has been generated automatically.

B

Now. This is great for the initial developer experience, because you don't have to deal with a key format that you may not have worked with before.

B

If you'd like to manually generate your own keys, which will eventually happen when you're working in a different environment other than local, we also supply a command called wash keys, which is for generating and managing these signing keys.

B

So if we use wash keys list, we can look and see all of the keys that I have generated locally, which is in just a local wash directory that we base off your home folder and if I'd like to generate a key, I can do that manually too.

B

So wash keys gin and then the specific type of key that we need here is a module key for an actor, and we can see that that gives us the public key and the seed key for that we can use for this actor now. The seed key is private, um so make sure to keep the secret. Don't like. I don't know record a demo of you generating this and then holding on to it.

B

But uh here I can use this fine for just demo purposes, I'm going to scroll back to that same sign command, and if we manually give that subject argument with the signing key, we can essentially assign that actor again and use the wash claims inspect command. To take a look at this signed, webassembly module.

B

So I might be going off screen again here. So I'm just going to do this again and you can see here that the module key now has the same public key that we generated in a previous step.

A

B

A

You, I think, you kind of glossed over a little bit of the linking of capabilities there.

B

Yeah, I'd love to take love to talk about that, a little bit more. So when you sign an actor or when you sign a webassembly module, that's built for wasm cloud development. You take advantage of capabilities when you need to access functionality that you can't do from within webassembly the example here is receiving or sending http requests.

B

You can use a capability like an http server capability to be able to receive http requests. Same thing can happen for like connecting to a database or accessing files locally on disk.

B

This is a limitation of webassembly not being able to do these things natively, but we actually enjoy the limitation there and we take advantage of it by being able to sign actors or uh and and providers with these capabilities we get granular control over what every webassembly module is allowed to do so here you can tell immediately from this table tennis actor that it is going to act as an http server. It cannot access files on disks. It can't make its own http request.

B

You can see right at the top level what it's going to do, and this is great for verifiability, that you're at any actor say you run someone's actor that you don't know what their code looks like. You know, they're not going to be able to access something that they're not supposed to.

B

Does that kind of help explain there liam did you want me to go into something else.

A

No, I think that covers it. I really just wanted to make sure that everybody, following along um kind of understood the uh the detail there.

C

Yeah yeah, I think when we do a wash 102 a type of a demo, we can get into more detail on things like prominence chains and how you might set up that kind of verification.

B

Yeah and certainly all of that will be published over at wasmcloud.dev with our documentation.

B

Well, cool, so I'll keep going here. um This has been a decent amount of um I've been walking through the claims and the keys command.

B

I didn't mention that I actually generated this actor from the new actor template that we have available on github and what this actually comes with is a make file to keep all this even simpler. So this make file simply cargo builds and then signs the actor, essentially with the same command that I just ran. So we can run make release when we're in this actor directory and that'll build and sign the webassembly module for you.

B

So the first time you're doing this, you can easily use this make file now in order to keep things simple for later, I'm just going to copy the signed webassembly module up to the top level in this demo folder and the next step is going to be uh signing our provider and creating a provider archive.

B

So with providers uh there's two things that we two problems that we're solving by using the par command for wash. So the first one is that we want the same amount of verifiability for a provider or a capability provider that we do an actor so who signed it. Where is it coming from what provider is it, for example, and with native capability providers without going too far into it?

B

They are built specific for a host like an architecture and operating system pair. So when I build a provider or a capability provider on my machine, it will work on my machine, but it won't work on a different architecture, for example.

B

So what provider archives allow us to do is gain this verifiability by embedding claims same way with or embedding claims just like what we do with an actor, and we can have multiple different architecture versions of this capability provider. Today is going to be simple: we're just going to make one for the local machine, so the process here is going to be largely similar to signing an actor if we use wash par create.

B

This will be the command that we use to. Actually here I'll do this again, so you can make sure to see. This is the command that we use to create a provider archive same with the actor. I have this pre-compiled for release, but we just need to provide a few different flags here to denote what this provider is.

B

Can you all see the line I'm typing on right now?

B

Okay, great! So the first argument that I'm going to need is my architecture pair, which I'm running on x86 on mac os. This may change for you, depending on what like operating system you're on, I need to give it the actual release binary for the http server capability provider.

B

In my case, it's the shared object is a dui lib on mac.

B

The next thing I need the capability contract that it's going to be fulfilling, so this is an http server, so the capability contract is wasn't cloud http server, and this is how later on, when we use this actor and provider together, they know how to communicate with each other.

B

We can give it a name which I'm just going to call it http server to keep it simple and the vendor is who's going to be signing this. This is just for human readability, so I'll sign it from me now another thing that you see here, uh hopefully you can kind of see it at the bottom of the screen. Is we are signing this capability provider uh with another key, that's been auto generated for us with wash and we've reused, the account key or the issuer key that was already generated for us.

B

So if we take a look using wash keys at what keys we have now, we have a module key for our table, tennis actor, an account key for myself and a service key for the http server provider.

B

So another thing that I actually okay. So if we look in our local directory now, we now have this wasn't cloud http, server par similar to claims. We also have an inspect command for the provider archives, and with this you can see our generated public key. You can see that this provider archive or the providers in this archive are going to fulfill this contract id and we support the x86 64 mac os target.

B

So this is going to work on my machine may not work on a different uh architecture or operating system.

B

The great thing about provider archives, though, is that we can include additional operating systems uh and or additional targets within them, and that's actually exactly what we do for our first party providers, so wash par, inspect and wash claims inspect. Both support, promote inspecting of provider, archives and actors. So if we take a look at the official wasm cloud, http server artifact here, we can see similar claims that come out of it, but also a multitude of architecture targets.

B

So these provider archives, for example, when you use our first party ones, we'll work the same on many different architecture, targets.

B

Now that I have this built, I'm going to do a similar thing and copy this up to the top of the demo directory. I want to clear the screen again.

C

B

Yeah, absolutely I'm just all. I did was copy this up to the top of the demo directory and I actually did want to take a pause here. We've gone through the claims, the keys and the par or provider archive commands, and it's kind of a lot of information, especially with signing keys. So does anybody have any questions.

E

So I have kind of a general question uh that relates to the make file that you've got up right now, yeah, so, if appropriate for right now or do you want me to hold on to it?

E

Oh yeah, but so I've noticed the the with the new uh the new um project template the makefile almost entirely delegates to cargo. uh Are you guys do you guys have any opinion on cargo make and just moving more things to the cargo world and dropping makefiles all together.

B

We actually have con, or there was another comment to use a just file which is like similar to a make file but built with rust um and I'm not familiar with cargo make and and if that's automatically included with cargo. But it's it's not. Okay, then a great benefit of having a make file or using make is just like the sheer number of machines that come with make pre-packaged, which is great. um But I don't. I don't think we have any hard opinions on.

C

B

C

um The ultimate deciding factor is, whichever provides the best developer. Experience is probably where we'll go with it, um but yeah we basically just we we settled on makefile because we needed to pick something, and uh it was the most most ubiquitous thing. We had access to.

A

You know with um the ypc cli for building capability providers and the whole contract driven development. We also were relying on uh you know, sort of model made microservice, you know kind of workflow.

A

I can see some advantage where you know the. Ultimately, all this will be hidden behind wash you know or like some high-level, really slick experience um as we get there, but I think it's a great thing to consider. If there's a better experience.

E

What was that other uh um task? Runner just you said.

B

Yeah, it's called just, I think it's developed by somebody named casey on github, but it's essentially you make a just file, which is just like a make file.

B

Its goal is to remove some of the pain points of um of makefiles, but it's very similar in in function. The obvious downside is that to use adjust file, you need just installed yeah. If you look at the.

C

The repositories uh that the people that are making crosslit use- I think they they favor uh just for a lot of the work they're doing.

E

All right cool take a look at that. Yeah cargo makers has plenty of quirks.

D

Yeah they, the team, I mean you can ask radu offline or something the team has uh settled into what the pm here will describe as a profound just fetish, um so right now, they're very positive about it to probably have to ask them for details. Cool. Thank.

F

You I'm glad we have the power to edit that comment out. Ralph.

D

B

We need a wasm cloud after hours.

B

uh All right well I'll, go ahead and keep going if there are no other questions uh get through this demo. So we've gone through we've built our actor built our provider and signed both of them. We, the next step, is going to be getting these resources into a local oci registry so that we can actually run them with wazon cloud.

B

So to keep this simple, we're going to use a docker compose in this tutorial to launch a local registry. What this does is just launch. A registry image makes it available on port 5000 and launches nats, which is used for the wasn't cloud internal components to talk to each other. For now, this is great for getting a call and letting us run the required uh resources for uh the for for wash to be able to run a wasn't cloud host.

B

So I've included this docker compose in this demo repo and it's also available in the wash and wasm cloud repositories too. So this is pretty readily available, so using docker compose I'm just going to detach this so that I can keep using the same terminal.

B

Now we have a local oci registry and that's running so we can easily continue this demo in order to interact with oci compliant registries. We use the reg command with wash you have the ability to pull artifacts and push artifacts from and to registries here. The first thing we're going to need to do is push our actor up into this registry.

B

So if we take a look at the push help text, then there's a couple options for connecting authenticating to registries, since this is local, it's fairly simple, so we just need to push to a url and note the artifact that we want to push. So, as I said, this is at localhost 5000.

B

I'm going to push my table tennis actor to 0.1.0, which is just the tag of the artifact and then send my table. Tennis signed webassembly module now wash will actually verify that this is a signed module. If you don't sign it beforehand. You'll get an error here and this is to ensure that you're always pulling valid, signed actors and providers.

B

The last thing we're adding the insecure flag, which is just because the local registry talks over http, so we can push that to our local registry. We can also verify that that worked by inspecting the claims at this oci.

B

Artifact and you can see a similar output to when we inspected the module before uh including the capabilities and the signing keys, which again is really useful to know before you download or start running an actor in your local rawson cloud host.

B

Now we can do the exact same command for our provider archive I'll push that to http server same tag, to keep it simple.

B

And now that has been pushed to our local registry and ready to be pulled down by a wasm cloud host.

B

If we'd like to verify that these actually got pushed correctly, we can do a full round trip by pulling down one of these and comparing it.

B

So this is all fairly quick. It's going to pull out as http server, and we can compare these two provider archives here and see that they are the same archive. So we've successfully pushed to our local registry and we're ready to launch a wise cloud host now this is the most fun part of the demo, which is you know, actually getting to see. Code run and code work.

B

So now we're going to move on to my personal favorite command, which is up which launches a fully interactive wasmcloud rebel.

B

So this environment, you're, able to use all of the sub commands that I've gone through so far in the demo claims drain or claims keys par, for example. You can do that all within the repple, um but for now what we're going to need to interact with the embedded host that's running in this repel is cuddle, which is how it's pronounced and it's short for control interface. This is how we actually interact with the embedded wasm cloud host.

B

So to get an idea of what hosts are actually running. We can run cuddle git hosts to get this single host that is embedded in the repo, which is what we expect.

B

We can also take a look at the inventory of this host by copy pasting, this host id here as an argument, and we can see two default providers a couple of labels, but nothing really nothing really running on this host. Yet luckily running things is fairly simple: we can use the cuddle start command to start an actor or a provider, so starting with actor, we'll give it the oci reference of our table, tennis actor and we'll get an acknowledgement back pretty quickly that that actor is starting on the host.

B

Taking a look at the inventory again, you can see our actor id and our table tennis actor is successfully running on this host.

B

Now the awesome part about this is: we now have another phone call and we now have a actor running in this host. It's just a webassembly module. Normally, it cannot uh in order to run this handle ping function. We need to deliver an http request by starting a provider linking a provider all of that, but what we can actually do is we can directly invoke operations on a webassembly module by using the cuddle call command.

B

Now this is a fairly simple command to use. We give it the actor id of the actor that we want to call and the operation that we want to call on the actor, so the operation or what an operation is.

B

Is one of these functions that we've registered as a handler in the actor for our case, we've only done one which is handle request, and if we take a look at some of the docs here, just to give you an idea of where this comes from, we can call the handle request, function and pass it an http request and directly get a response back without actually going through the http server provider.

B

Now the hardest part about using the call command is that the argument that you need to give it is the exact payload that the function is looking for, in this case an http request. So we need to give it all the fields and matching types, or else the actor will reject it.

B

So I'm sending a post request with the body of ping and the call response that we get back has a couple of message: pack bytes that are going to show up as glyphs here. But the main thing that you can see is that we directly get a response back of ok and a body of pong, which is awesome, because we can see that our actor, our webassembly module, is handling these requests properly without ever even linking or starting a provider.

C

It may seem it may not seem as cool to everybody as it does to me, but I love the fact that we can specify the input to this function as jason, even though the uh actor itself is only communicating over message. Pack.

B

Yeah, it is, it's awesome, it's great for a rapid feedback loop because you don't need to spend the time starting a provider and linking it to.

A

I think there's a totally undersold um uh story here around the ability to compose and test your business logic independent of how you're implementing it you know like if we think about this is a type of testing here. You know whether it was unit testing or um you know. Whatever you know, this is like as focused of a test as you could write. um Even before we introduce complexities of providers, that's uh pretty powerful.

B

Yeah 100, because here you know, I have my actor that I'm using locally but in a normal case, you're- probably not going to go through this effort. If you just want an http server, you can use the wasm cloud http server and if you think that our code is super bad and you don't want to run it yet you know you want to test your pure business logic. That's in your actor! You can do that without actually starting our http server.

E

Yeah, actually this this might be a quick short road into unit testing, is just the ability to send jason to an actor and have wash cuddle or whatever, output, jason back and then just wrap a quick test. Runner around that. So you can have your test cases be jason.

C

It's an excellent idea. We should totally look into doing that. I was just thinking as we were running through this wash uh as we were walking through the rebel that there might be a way to leverage some of the stuff that we've already done inside here, to make it easy to run quick and dirty tests on actors that would make for easy, generative testing as well.

C

Yeah I mean really. All we need to do is define the payloads that it expects in response from the dependent providers so like in our. In our canonical example, we have the kd counter. That makes a a request of the kd store in response to http request in order to test that we could basically just supply a list of responses that it expects to fake from the key value store.

C

um We could you know essentially have um you know we could create a simulator for each of our regular uh capability providers and then just load the uh the test, runner version of the provider.

E

Yeah and you can, with uh with anything running in production like environment, you can have uh you can shortcut some of the responses and gather inputs and outputs and then run those on future versions as as regression testing, and I think.

C

Again to liam's point there there's some subtlety, that's going on here. That I think is easy to forget one of them. The subtle points here is that, while, while what brooks is doing is talking to a local host, if his nat server was a leaf node connected to a lattice with 300 other hosts, he would be able to do exactly the same thing, regardless of where those actors are running. So you can call an actor from your laptop. Even if it's running in uh some other uh cloud environment.

A

You know that uh that comment about you know, saving things from production um reminds me of you, know, sort of like uh marrying postman and um like something that uh like darklang, was trying to do where you know you would, as you submitted requests, you could like go back in time and uh and play them. I definitely think that there's um they.

C

Called it like trace-driven development.

A

C

I think we have the same ability to capture all of the payloads from a production run and then uh allow those to be read from uh you know: simulated providers so yeah. I think this is something we should spend some time looking into.

B

Yeah awesome um just to drive the rest of the demo home now that we know that our actor is working appropriately. We can do some. We can continue to utilize the control interface to start our http server provider uh and as a cool um example, we can actually start the http server provider from the wasm cloud. Azure container registry.

B

The actual azure container registry- and if we take a look at the uh host inventory here once this, has enough time to download, we can see that we have our table tennis actor and the official http server provider running in our local host.

B

The last command that we need is to link this actor and this provider together on a capability contract and that way, uh http requests can be forwarded from the provider to the actor appropriately.

B

So for cuddle link, we just need to input the actor id the provider id and then the the contract that we're going to be communicating over which in this case is wasn't cloud http server, and then we can also give it a port to listen on locally so that we can make these requests like just in another command line.

B

Now that we've done that, we can simply open up another terminal and if we curl localhost 8080, I'm going to make it verbose, because I know what it's going to do. We get a bad request, which is exactly what's supposed to happen with this actor when we don't give it a body of ping.

B

So if we do that again, but with the ping body we're going to get our pong back so now, we've fully connected this to an http server using cuddle link and we can interact with this actor as a regular, uh just as like a regular http server api.

B

Now, last but not least, to get the very last command done for wash when we download resources from remote repositories, we actually cache them locally, and this is great for continued commands. If we start the same provider over and over to ensure that you're always getting the latest version of a provider or an actor, we also have the wash drain command, which is great and punny, and using wash drain we can clear out any downloaded or cached binaries or oci references that we have.

B

So that is a pretty high level walkthrough over all of the commands that we use with wash to make wasm cloud development easy, there's a lot of functionality. That's made simpler, including signing keys and using the control interface and the repo to directly run these resources as a watson cloud program.

B

So I'm happy to answer any questions or any feedback on how we can continue to make this.

A

Easier all right brooks. Thank you so much that was incredible. um So does anyone else have any questions um along the way um or comments? um Did everyone follow along? Would a like um a laminated glossy cheat sheet for wash be handy? What is what's your kind of feedback here for people that are seeing it all together.

C

Personally, you know I've seen how all this sausage is made and it's still super impressive, and I love this demo so really excited for the the experience we have now and then to watch it get even even better and smoother yeah.

A

uh Steve you're uh relatively new to the sort of like the life cycle of of wash, and you know what the goal is. um Does it make sense to you? Is it intuitive yeah? um I think it's pretty. I think it's really cool okay, good, all right great! Well, I had. um Does anybody think that we would need um or want, like um you know, like a a flowchart or a cheat sheet or something like that like a little, you know handout or is that the superfluous? Does everybody in the call?

A

Would anybody in the call use something like that.

E

Jordan, okay and I've built one for myself. um I I use them a lot. uh I'd probably use one that you guys build because it would be better than mine.

A

Careful- uh let's not like, let's not jump, to conclusions here. Right, like I mean look, you know, he's probably gonna build it. uh Okay, a super I'll, take a pass it. Something like that. I was going with some ideas last night uh and um uh but I wasn't sure I thought we'd kind of see how the demo goes uh well. That was uh that was incredible. um uh Let me uh share my screen and we'll go back to the agenda if there's no more questions or discussions, uh but I really uh would just comment.

A

uh Sorry go ahead. Ready did you have something.

G

I just want to say it's a really well put together demo. It's gonna be interesting to see as people start using it more, maybe which of the steps could be hidden by the cli and which could be optimized. I mean just give the option for users to manually execute them if they wanted to, but hide them behind some flags or some auto-generated keys or the entire infrastructure. But it's a really really cool demo. uh You.

A

Know I don't know if you were on the call we were on a few months ago, where we did that. But if you think back to where we were in august, it was like. Okay now switch to n keys, and now you know uh now we're gonna switch, this command line utility to upload and download, and that's where we sat down and we really and even the whole keys workflow. I think that was up on our slack, where we were like well, why the hell do we have people generate keys?

A

You know like let's, let's look if they don't have it, let's just generate it for them and just make all this stuff as easy as possible. How many steps can we just cross out of this process uh processing the journey from sketch to scale yeah? I think we want.

C

To we want to make it so that the so that we default all the easy things uh to the best possible path, uh but then let those defaults be overridden with more opt-in complexity. If you need it, but, like you said the easy. The easy path should be for us to anticipate as much of what the developer needs as possible and go ahead and do it for them.

A

Awesome uh brooks and I'm sorry the uh recording uh messed up. I'm gonna have to do that again. If you don't mind.

B

Great, so the first step is to sign your act.

C

Actually, you have to do it backwards this time he.

A

Didn't even hesitate, he just just dropped right back he's a pro. He would talk to an empty room. He'd stand on stage on an empty room and be like the first step is to it's amazing. I love it all right.

A

This might not actually be.

C

The real brooks we might just be talking to uh bricks that he previously recorded.

A

ah Totally fair, I hadn't considered that possibility yet. Okay, all right. So some quick community news here um cfp for wasm day has closed. uh I think there were what 24 submissions kevin uh so uh we'll start working through that as quick as we can and uh get some feedback back out. uh Tickets are still on sale, though um so everybody look forward that that is. May the fourth uh webassembly summit is fast approaching april 22nd uh and uh wasn't time weekly meeting was last week um a lot of fun stuff happening there.

A

The notes are linked in our call. If anybody uh wants them just open call real, quick, any additional community news. Anybody have anything going on. They wanted to share or events meetups.

A

Okay, super uh I'll um yeah. One question I had from last week just to carry over was we had a great discussion last week about um uh the the current assumption that nasa's already running in the background um uh kevin brooks? Did we get this captured on our uh as issues? You know things to sort of talk through and think through or get these documented out? Well.

C

Yeah we started, um we captured it kind of under the broader issue of starting an actor from. Nothing is, um has too much friction in it right now. So one of the areas that we can remove friction is to not require gnats in order to start the actor using the the wash rebel.

C

So uh I think I think we have a pretty good idea of if we, if we make it so that the wash rebel allows you to start a no lattice uh host and then all of the room, the previously remote control functions can instead opt to using the host api to directly control. Then I think the combination of those will mean that the new offline default would would make it so that you can start all of your actors and providers directly from disk and uh control them from inside the rupple without having nas installed.

C

A

All right, uh I just wanted to uh you- know kind of resurface that one again, I know what we kind of discussed. Maybe should we be lazy loading? um uh You know this docker compose file in the background for people, if it's not already up, but I think some more user experience stuff to think through on um on that particular angle- and I see we do have a ticket for this, so I'm just gonna go ahead and just delete that from our notes. For this week, yeah.

C

A

C

The idea of lazy loading, which is sort of bringing it up on demand, we should just sort of have a default that that is offline and no lattice and no nats.

C

And then, if you want to use, um if you want your rebels, your your rebel started host to be part of a lattice, then you just specify the lattice connection string. If you want your ripple started host to be part of the lattice and control it remotely and so on and just sort of add those those features.

A

Okay, one time configurable, okay, yeah. I think that does make a configurable. I think that does make a lot of sense. um I think everybody has seen or had a chance to play with the new wilsoncloud.dev and all the features here. I'm really excited to welcome all feedback on this or pull request as you kind of get in you know this was a labor of love. To get this out, I would comment that um the t-shirt uh window is still open.

A

That's linked on slack I'll link it into our call notes that will be open until friday. Those are free. You can order, there's four different options. You can order all four. You can pick out your favorite uh but feel free to get those um ordered, and those will should uh we'll close that order uh into day friday and get those shipped, but I think from an agenda perspective without diving into issues and things like that. uh That was what we had.

A

I kind of opened the floor to see if anyone else said anything they wanted to bring up um this week. I.

C

Think one other thing we sort of talked about it um when jared brought it up, but I think um one of the things that I'm going to go uh then I'm going to take as a to do item is to take a look at uh potentially creating a universal test provider that we can use to slot into a test running host. And then you know essentially run our tests against fixed or pre-recorded payloads, and I think that might dramatically reduce the the complexity and the cost of testing actors.

A

Awesome, I think that was a magical moment. I love the. um I think, that's one of the things when we think about. If we want to build the best products we we need to have um the most diverse and inclusive community, like the principle of having the biggest tent possible, uh because uh the best feedback and ideas comes from the most um diverse perspectives, and that was awesome and it's stuff.

A

I know that we have at times kind of like talked around, but that moment just really, I think, crystallized a really solid idea that we should absolutely just get pinned out on our road map out there um back to open floor. Anyone have anything uh they wanted to bring up uh radio ralph, uh wicker, steve anybody.

D

I don't have anything specific to bring up. I love the demo. I do like how the experience is coming along. um So in this case, I'm just riding riding.

D

Can you hear me.

A

Can hear you now.

D

All right, so uh I was just saying I was writing the demo and and enjoying it. I liked seeing how the experience is coming along, and it's just you know it's really rich, but outside of that, I'm just I'm surfing the hour today. It's uh just a pleasure to be here and see. What's going on, okay,.

A

Awesome all right! Well, uh uh wicker, do you have anything you wanted to throw in an ad? I just wanted to.

G

uh Thank you for inviting me, and I think the demo is really awesome, um and you know one of the things that uh I just want to share. What we're working on at wesmer like what our next big thing is going to be um so.

A

As you know, we recently released our runtime uh that we'd love to make a part of wasmcloud, um so we'll figure out how to make that happen. I I know liam. I think we owe you a pull request um and then the second thing that we're working on uh is going to be the next release of our package manager.

A

So it's currently kind of like pre-alpha-ish quality on rn, um and we want to um you know as things like wasm cloud come along, uh we want to kind of give uh those packages like a proper home with proper functionality. So if anybody has ideas that they want to share or things that they wish uh package manager would have I'd love to hear them all right. That's awesome. Thank you for keeping us up to date on that. um Anyone else uh like uh across across the community.

A

All right, I'm going to go ahead and stop recording. As usual. We can turn this into wasm cloud after dark.