Update 2025-03-19-community-meeting.mdx

Signed-off-by: Eric Gregory <eric@cosmonic.com>

Author: ericgregory

community/2025-03-19-community-meeting.mdx

@@ -18,41 +18,39 @@ title: 'Meeting Agenda - 2025-03-19'
 
 {/* Add summary of topics during the meeting. Each Topic should have an H3 heading. A list is usually sufficient for the recap */}
 
-### Topic 1
+### DEMO: WebAssembly composition in wash build
 
-- Note 1
-- Note 2
+* Brooks provided some background on **composing WebAssembly components**. Refer to the wasmCloud docs for [Linking at build-time]() for more information. 
+* Today you can use the open source WAC ClI tool to compose components. 
+* You can use the `wac plug` subcommand to quickly and easily compose two components with matching imports and exports.
+* Brooks demonstrated composing two components with WAC.
+* Brooks then showed some new `wash` functionality (currently in a PR) enabling users to specify a composition in a project's `wasmcloud.toml` to facilitate composition with `wash build`. This uses WAC's Rust library and means that a user doesn't need to have the WAC CLI tool installed at all.
+* WAC does use some unique terminology like "plugs" and "sockets," so there's a discussion to be had on what terms we want to use for this functionality, since we don't want to increase the conceptual overhead new users. 
+* Joonas suggests keeping the language as simple as possible and avoiding new terminology wherever possible.
+* Colin suggests keeping usage as closely aligned with WAC as possible, since he thinks it works well.
 
-### Topic 2
+### DISCUSSION: Virtual components initiative
 
-- Note 1
-- Note 2
+* wasmCloud power user and contributor [LUK3ARK](https://github.com/LUK3ARK) explained his proposal and prototype for [virtual components](https://github.com/wasmCloud/wasmCloud/pull/4228).
+* From his prototype:
 
-## Weekly highlights
+> virtual components...are components that do not verifiably exist within a lattice. In other words, the wasmcloud runtime has no knowledge of the existence of a service because:
+>
+> * it is managed by another runtime
+> * because of very unique, complex cases where users do not want to build providers for their use cases
+> * users can link easier with existing, disparate systems
 
-### Issue of the Week
+This proposal would allow wasmCloud to interact with other services (which could be external and outside the wasmCloud linking context) in an ad-hoc fashion, abstracted as components and using a `component-id`.
 
-- [title](https://github.com/wasmcloud/wasmcloud/issues/)
-  - summary
+* LUK3ARK notes that this raises questions like, "How much work do we want a user to do to make an external service compatible with wasmCloud? What are the underlying requirements for compatibility? How much validation and verification do we need in communication? You could have circumstances where the developer doesn't have feedback such as 'this external service doesn't exist.'"
+* Colin notes that for a while we've envisioned that providers will eventually be WebAssembly as well, and if that's the case, we'll need to solve something like this case. 
+* Massoud notes that if service providers start natively supporting wRPC, the role of providers may change considerably. 
+* Colin notes you still need something in wasmCloud saying, "this component can talk to Redis, this one can't." Brooks notes that we do have a policy service which could fulfill this role.
+* Further discussion will take place in the [virtual components PR](https://github.com/wasmCloud/wasmCloud/pull/4228). 
 
-### Documentation of the Week
+### DISCUSSION: wasmCloud organization stalebot
 
-- [title](/docs/intro)
-  - summary
-
-## Community Updates
-
-### Tune in…
-
-{/* Add any upcoming events/streams/etc */}
-
--
-
-### Catch up…
-
-{/* Add any blog posts/articles that the community might find interesting */}
-
--
+* We're considering changing the way the stalebot works, so it doesn't close issues automatically. Let us know if you have thoughts!
 
 ## Recording