[sambigeara]

Well, that’s a good question. I think the best answer for now is “we’ll see”?

I use it in place of Tailscale for some homelab applications. I’ve started to deploy other experiments on a “prod” cluster. The demo I showed shows how Pollen responds to a multi-step pipeline type application; two WASM seeds and a single egress communicating over the provided RPC mechanism (`pln://seed…` etc) whilst handling routing, back pressure and the like.

Right now, the workloads need to be stateless. I’m coming up with a story for state at the moment, which’ll likely start as some WAL-like convergent structure with thin (KV store etc) abstractions layered over it. Probably not dissimilar from the pattern underpinning the current CRDT gossip state.

[kaoD]

Let's see if I got this right: so it's something like a private Yggdrasil Network (minus the IPv6 overlay?) meets self-distributing WASM-powered serverless functions? Plus some built-in functions for proxying/serving.

[sambigeara]

Ha, at a hand-wavey level, yes? Like you say, there's no IPv6 overlay, each node just exposes it's own primary UDP port which talks Pollen's mesh protocol. It uses a single QUIC transport, one QUIC connection per peer, and a combination of streams and datagrams for different bits serving both the control/data layers.

I'd say "WASM-powered serverless functions" is a reasonable analogy, if your serverless functions maintained a minimal number of live replicas at any one point Also, of course, you're tied to the physical ceiling of the explicit hosts that are underpinning your cluster (N machines which are not dynamic like, say, lambdas are when they auto-provision to match demand).

And yeah, you can also `pln serve` arbitrary services which are then exposed to the cluster, but it's worth mentioning that these will of course not benefit from the inherent, organic autoscaling and locality mechanisms that come with the WASM blobs. I only added it in as a feature so I could retire my (basic) Tailscale usage.

Also, you can `pln seed` arbitrary blobs which can be `pln fetch`ed from other nodes. You can also `pln seed ./public my-site` a static webpage which you can reach from any node with `curl -H "Host: my-site" http://<node-addr>:8080/` (8080 being a configurable port).

[kaoD]

And what's the public API/stdlib/bindings inside the WASM workers?

I've been thinking a lot about this today and I think you might have a hidden gem here. Where can I reach you to talk more about this?

Feel free to drop an email (address in my profile)

[sambigeara]

Ha, thanks! I'll ping you an email.

> And what's the public API/stdlib/bindings inside the WASM workers?

Wazero (via Extism) carries the load here. As it stands, the runtime lifts three basic host functions into guest code which enable the RPC-like behaviour, injection of caller-context and basic logging[1], which are in turn referenced in the guest code like in the example[2].

In the reverse direction, guest code exposes it's public APIs via build directives[3], which are handled by the runtime code[4].

Figured that concrete examples might be more helpful here (I hope the formatting works).

[1] https://github.com/Sambigeara/pollen/blob/567e85d5f1407932dd... [2] https://github.com/Sambigeara/pollen/blob/567e85d5f1407932dd... [3] https://github.com/Sambigeara/pollen/blob/567e85d5f1407932dd... [4] https://github.com/Sambigeara/pollen/blob/567e85d5f1407932dd...