viccuad

Though luck. Be more careful next time. That's how licences work (not only open source ones, or software ones).

Only Matrix is federated, like email. I really enjoy sending emails without opening an account for each recipient or being subservient to 1 stack provider for 50 years, with all the inbreeding that entails.

I wonder how a home assistant built with an Entity Component System architecture would look like.

At that point I would just call it a reimplementation instead of emulation.

Let's just build it in open source and out of walled gardens then.

Agree here. I long for an open source combat flight sim, and Bevy, with ECS, rust, wasm capabilities, thread safety, etc sounds quite apt.

Just gave a talk on Monday about it in containerdays.io, but the video is not in youtube yet!

In a nutshell, with Kubewarden we strive to build the universal policy engine by:

- Provide all personas (policy consumer, policy developer, policy distributor, engine admin, engine developer/integrator, etc) with current and future industry-standard workflows, not only a subset of personas, nor more than needed knowledge for those personas. It's a bold statement, and if it would be universal it should indeed cater to everyone.

- This is achieved with policies as code, which are Wasm modules: Wasm policies allows us to support Rego DSL (OPA/Gatekeeper), YAML, SDKs for Wasm-compiled languages, and now an experimental Kyverno DSL policy by compiling it to WASM with WASI. Great for using your language and tools of preference.

- Wasm modules have first class support In OCI registries, just like container images: Use same tools that you know as artifact distributor: SBOMs, signing and verifying with cosign, airgap, slsa.dev, etc.

- Policies can be evaluated out-of-cluster: great for CI/CD, dev loop, integration tests, etc.

- Modular architecture informed by using Wasm policies: OCI registry, policy-server, k8s controller, out-of-cluster cli (kwctl), etc. This also helps in adopting future industry-standard workflows.

- Usual features of a Policy engine (mutating, context-aware, recurring scanner of already in-cluster resources, etc). Plus ample room for new features thanks to the architecture. E.g: possibility to run the policy-server directly in the k8s apiserver (one colleague already presented that in Kubecon), possibility to evaluate out-of-cluster policies outside of clusters like OPA just by running the policy-server standalone, more DSLs compiled to Wasm, more languages, etc.

- Vendor neutral, CNCF project, open source, developed in the open.

It consolidates Go compiled to WASI as an alternative of doing containers. Linux containers don't "Run anywhere." as docker.io says. You need a specific architecture and kernel features, which is not obvious from afar.

There's also other benefits. Example: the team I work on compiled Kyverno, a CNCF K8s policy engine written in Go, to a WASI target. We are building Kubewarden, a CNCF policy engine where policies are Wasm binaries shipped in OCI registries. We strive to build "a Universal Policy Engine". Now, we have an experimental Kubewarden policy `kyverno-dsl-policy` that allows you to reuse Kyverno DSL with us. We also provide WaPC as a target, more performant and secure, hence normal SDKs for Go, Rust, C#, swift, typescript... In addition to supporting Rego, again compiled to Wasm.

IMHO you only benefit from the real sandboxing from WaPC, as WASI's posix-like interface allows you to attack the host.

The next step for the official Go compiler is to export the function symbols, to allow for WaPC.

A good architecture for fully parallel, deterministic, thread-safe, serializable and extensible games is the Entity-Component-System pattern. I'm sure that Godot has one or a way to integrate a library that implements it. I think Unity doesn't come with ECS anyways.

I wonder, how could one use SGX for remote attestation when they didn't publish the source code for more than a year just to get their insiders' knowledge cryptocoin deployed.

if they want it to work as you posit, they should not save all the date in Discords systems, but create a distributed chat system.

Signal is just XMPP implementing the Axolotl ratchet.

XMPP is just SMTP and some protocol addons on top. SMTP is just FTP with RFC 469 and others. Etc.