Solidground tech radar: Back-end / Rust

Solidground
,
#1

This list topic serves to inform on Rust projects that may have relevance to Solidground in some way or other. Either as a candidate for techstack integration, to interface with, or just learn from the code.

Entries should have:

  • A H2 heading with the project name
  • Link to the project and other relevant links
  • Summary of what the project does
  • Explanation of the relevancy for Solidground
  • Mention opportunities for ecosystem collab

Use markdown formatting for readability, and avoid long discussions in this thread. It’s a list… :hugs:

:spiral_notepad:  Best-practice Technology radar support is a Solidground candidate Process recipe.

Solidground 2024: Maintainers Log (wiki)
#2

Rauthy: OIDC SSO Identity & Access Management

Rauthy is an OpenID Connect (OIDC) Provider and Single Sign-On solution written in Rust. It tries to be as secure as possible by default while still providing all the options needed to be compatible with older systems. The main goal was to provide an SSO solution like Keycloak and others while using a way lower footprint and being more efficient with resources. For instance, Rauthy can easily run a fully blown SSO provider on just a Raspberry Pi. A Rauthy deployment with the embedded SQLite, filled caches and a small set of clients and users configured typically only uses between 17 and 22 MB of memory!

CAUTION: Active development, pre-1.0 release. No third party security audits yet done for this project.

Relevance to Solidground

Just like GoToSocial we may support OIDC at some point. This lib follows an approach that aligns with small-tech principles.

Ecosystem opportunities

Rauthy author sebadob is building stuff with Wasm support, e.g. for Leptos, and looked into NATS project (used also by Wasmcloud).

Other projects are spow - PoW with Wasm support - and leptos-captcha, which are interesting to @realaravinth wrt mcaptcha.org.

It looks that Erlend (fedi, socialhub, commune-os) intends to use Rauthy lib, and sponsors it.

#3

Claw-lang: Compiler for the Claw programming language

Claw is a programming language that compiles to Wasm Components. Values in Claw have the exact same types as Component model values and the imports/exports of a Claw source file represent a Component “World”. This means that there’s no bindings generators or indirection required. You can receive component values as arguments, operate on them, create them, and return them.

Use cases & goals: Component testing, Adapters & polyfills, Virtualisations & mocks, Extensions, Simple services.

There are several projects for representing different aspects of the Component Model

  • WIT - The official IDL for the Component Model
  • WAC - An extension of WIT that adds the ability to define how to wire components together
  • WAVE - A format for encoding Component-Model values in an idiomatic json-like way

Claw will use WIT syntax for defining types, WAC syntax for defining composition, and WAVE syntax for literal expressions combining them all together so that it’s intuitive to use these different tools.

Relevance to Solidground

Interesting for the use cases that are listed, and ability to create tiny components with relative ease.

Wasmcloud project has taken an interest as well (found the project via their slack). Wasmcloud alpha release demo showed the use of WAC for service composition, which isn’t the most intuitive. Claw may cover that better, may become adopted by Wasmcloud.

Claw author Robin Brown (@esoterra@hachyderm.io) has a blog article on a draft Template-to-Component Compiler (that may be the reason for starting Claw) to compile e.g. HTML templates (handlebars) or other language-specific DSL’s.

All this is relevant wrt Service component packaging, alongside with wasi_virt virtual filesystem for Wasm Components.

Ecosystem opportunities

Win-win collab: Contribute to claw-lang vs. receive maintainer support for our impl.

Get more involved in Wasm standards evolution (think also Bailey Hayes of Cosmonic and Bytecode Alliance) and early adoption of said standards.

#4

Warg registry: WebAssembly Registry (Warg) reference impl.

A Bytecode Alliance project. The reference implementation of the Warg protocol, client, and server for distributing WebAssembly components and interfaces as well as core modules.

This repository contains the reference implementation of the Warg protocol, a client, server, and CLI. A Warg client and server can be used to distribute WebAssembly components to various component tooling.

See WASM/IO 2024 talk on Warg:

Oops… currently not available via Invidious.

(Youtube link to the video.)

Relevance to Solidground

The registry is well-documented and provides direct input for functional design of Solidground aspects.

:point_right:  Prime candidate for integration with Design Hubs. The Minimum Viable Product definition lists user stories, requirements and stakeholders, and can directly inform our domain modeling.

The MVP doc is also candidate to be turned into a Process recipe, first used by Solidground themself to summarize delivery of the MLP.

Ecosystem opportunities

Get more involved in Wasm standards evolution (think also Bailey Hayes of Cosmonic and Bytecode Alliance) and early adoption of said standards.

Provide a “minimum viable hub” to be self-hosted by selected FOSS projects using Wasm, and collab with them towards federated registries.

#5

Kellnr: Private Crate Registry

Kellnr allows you to host private Rust crates on your own hardware. Keep full control of your code at any time. Automatically generate and display rustdocs for your crates. Transparently proxy and cache crates.io to keep your deployments fast and independent. List and search your private crates.

Kellnr most easily deployed using Docker, and uses Sqlite as its default database backend (with Postgres another supported db).

Relevance to Solidground

To be determined. It may be useful for storing our own dependencies. OTOH we intend to go all-in with Nix, so it may not be needed.

There might be a use case for Kellnr (or reuse of specific crates) wrt Design Hubs.

#6

Atomic Server: Headless CMS / Realtime database

AtomicServer is a real-time headless CMS, graph database server for storing and sharing typed linked data.

Atomic Server is created by the founders of ontola.io and is part of a broad range of open source Atomic Data tools and libraries for working with Linked Data (“The easiest way to create, share and model linked data.”). The project received NLnet funding for NGI Assure in 2021.

Relevance to Solidground

Besides graph database, Atomic Server considers itself a headless CMS.

:point_right:  For Living documentation it would be great if the Design Blueprint content that accrues would have an underlying Linked Data format, in order to model domains of the FSDL (which is a graph, cannot be accurately captured as a tree) and re-use existing vocabularies, such as OASIS OSLC.

Using Linked Data as extensibility mechanism for ActivityPub is a bad choice and a PITA to support. We recommend using a JSON-first approach to the standard, with JSON-LD support an extension profile. With Atomic Data that implements the JSON-AD specification, we are coming closer to a “best of both worlds” combination: a marriage of semantic knowledge and social graphs (think e.g. Semmy idea).

Interesting project aspects to check out:

Ecosystem opportunities

There’s a possible great win-win in 2-way collaborations Solidground vs. AtomicDev on many complementary parts. Like, using Atomic specs, reusing ref. impl libs, then offer as wrapped services in our ecosystem. Creating UX components that support Linked Data. Etcetera.

Offering of a Linked Data profile for ActivityPub bring collab opportunities to some of the more innovative projects on the Fediverse, that also aim at broad applicability well beyond Microblogging alone. Like ActivityPods, Vocata, SkoHub, rdfPub, and SemApps.

Like Ontola software services provider, the use of Linked Data makes Solidground more attractive for use by governmental institutions, where LD has a much broader adoption rate.

#7

Garage: Self-hostable S3-compliant distributd object store

Garage is a lightweight geo-distributed data store that implements the Amazon S3 object storage protocol. It enables applications to store large blobs such as pictures, video, images, documents, etc., in a redundant multi-node setting. S3 is versatile enough to also be used to publish a static website.

Garage project, NLnet-funded under NGI0 Pointer and Entrust, ticks a lot of boxes: self-contained, standard-compliant, easy to install/deploy/integrate, resilient, and secure, and requiring few resources to operate.

Landing page mentions a number of fedi apps that’d benefit from using it (unclear whether they do use it): Mastodon, Peertube, and Nextcloud.

Relevance to Solidground

Storage of social networking and living documentation / design blueprint related objects for Groundwork.

Ecosystem opportunities

Collab with Garage project, e.g. offering of an official capability provider, as well as vendor-neutral Wasm Component (WASI-compliant, see: wasi-blobstore.proposal).

Advocacy of adoption + collab with other federated apps, if they integrate Garage in their solution.

#8

WASI Virt: Virtual implementations of WASI APIs

When wanting to run WebAssembly Components depending on WASI APIs in other environments it can provide a point of friction having to port WASI interop to every target platform. In addition having full unrestricted access to core operating system APIs is a security concern. WASI Virt allows taking a component that depends on WASI APIs and using a virtualized adapter to convert it into a component that no longer depends on those WASI APIs, or conditionally only depends on them in a configurable way.

An example, most relevant to Solidground:

Example: Virtualize Filesystem API

For example, consider converting an application to a WebAssembly Component that assumes it can load read some files from the filesystem, but never needs to write.

Using WASI Virt, those specific file paths can be mounted and virtualized into the component itself as a post-compile operation, while banning the final component from being able to access the host’s filesystem at all. The inner program still imports a wasi filesystem, but the filesystem implementation is provided by another component, rather than in the host environment. The composition of these two components no longer has a filesystem import, so it can be run in hosts (or other components) which do not provide a filesystem API.

This video by Taylor Thomas (of Wasmcloud / Cosmonic) demonstrates wasi-virt:

(Youtube link: https://www.youtube.com/watch?v=OTFQiMrG9lo )

Relevance to Solidground

Packaging/bundling of Blueprint design artifacts into Service components. Using wasi-virt for this purpose means that services are exclusively packaged as Wasm Components (*.wasm files), and not e.g. as .tar.gz that must be unpacked into a plugin directory.

Ecosystem opportunities

Get more involved in Wasm standards evolution (think also Bailey Hayes of Cosmonic and Bytecode Alliance) and early adoption of said standards. (Bailey Hayes pointed to this solution on Wasmcloud slack in response to my question on bundling resources.)